Is there an existing, security-audited Cardano smart contract that allows anyone to send either ADA or native tokens to it, locks those assets for a predefined duration (e.g., 1 year), and then automatically returns them to the sender’s address (minus transaction fees) once the time has elapsed?
If such a contract doesn’t already exist, is this functionality feasible to implement reliably using the Marlowe interface — without requiring a costly third-party security audit?
That is not possible on Cardano in principle (not even sure if it is possible on any chain). Contracts are not active. They do not do anything on their own. They only formulate requirements that transactions have to fulfil to be allowed. Someone still has to build, sign, and submit that transaction.
But other than that that, you do not even need Plutus (or Marlowe *shudder*) for that.
Simple scripts are totally enough for locking until a specified slot and only allowing certain keys to spend:
https://developers.cardano.org/docs/get-started/cardano-cli/simple-scripts/
That would be a new specific address for each combination of payment key hash (Who is allowed to spend?) and "after" slot (When are they allowed to spend?), though. With Plutus, you could write that in the datum of the transaction sending into the contract.
Don’t know why you would want to use Marlowe for that. Personally, I think Marlowe is pretty much dead and rightfully so: While such visual toy languages might have use cases, contracts managing assets should only be done by people who know what they are doing. And those people can use Aiken, Plutus, …
Not exactly your requirements, but one of the very first examples of Aiken comes quite close to what you describe:
https://aiken-lang.org/example–vesting/mesh
The most important part of the contract is:
or {
key_signed(tx.extra_signatories, datum.owner),
and {
key_signed(tx.extra_signatories, datum.beneficiary),
valid_after(tx.validity_range, datum.lock_until),
},
}
Which says that a transaction signed by the owner can always spend the locked assets, while a transaction signed by the beneficiary can do so only after the specified point in time.
Depends on why you want that “security audit” and what you want to have audited.
If an audit is required by some management and/or legal guys, then they want something with a company logo on it (no matter the real meaning).
If it is about being sure that the contract does what it advertises, you can just let three people knowing a medium amount of Aiken look at those seven lines above for two minutes to conclude that that cannot possibly have any problems. (And the example also contains tests to ensure that.)
If it is about the user being safe, the interface is at least as important as the contract itself. That the contract itself is totally okay, does not mean much if the interface has a loophole that allows to exchange the owner or beneficiary before the transaction is built. An average user would not recognise that when signing the transaction.