The (as-contract) built-in should be extended to take a list of post-conditions on assets moved by the contract, in order to guard against things the contract might do (or might get tricked into doing). In particular, the fact that a trait implementation can be passed into (as-contract) means that a contract can be coerced to run arbitrary Clarity code (by design), which means that the caller of (as-contract) should be able to defend the contract against attempts to do things like move tokens and assets.
Alternative: expose a way to query the asset map from Clarity. Then a contract that wanted to guard could do a lot more with this, and the cost assessment is a lot easier to tabulate.
Copied from https://github.com/stacks-network/stacks-blockchain/issues/3094 (see there for additional discussion):
The (as-contract) built-in should be extended to take a list of post-conditions on assets moved by the contract, in order to guard against things the contract might do (or might get tricked into doing). In particular, the fact that a trait implementation can be passed into (as-contract) means that a contract can be coerced to run arbitrary Clarity code (by design), which means that the caller of (as-contract) should be able to defend the contract against attempts to do things like move tokens and assets.
Alternative: expose a way to query the asset map from Clarity. Then a contract that wanted to guard could do a lot more with this, and the cost assessment is a lot easier to tabulate.