Deposit

Two ways to lose the money, and the shape that prevents each. Both are real failure modes of the underlying primitives, not hypotheticals.

Trap 1, a bare transfer into an ERC-4626 vault

Send tokens directly to a vault address and totalAssets rises while no shares are minted. The deposit is donated to the existing holders.

⛔ The transaction succeeds. There is no revert, no error, and nothing in a wallet's history that looks wrong.

The shape that prevents it: the deposit builder returns a two-step kind: "connect" request and never a scannable URI. A QR code that a wallet can pay directly is exactly how this mistake gets made, so one is never rendered.

Trap 2, a transfer to an undeployed Safe

A Safe has a deterministic address, so it is tempting to show it before it is deployed. But ERC-20 tokens sent to a counterfactual address are locked for ever if the deployment bricks.

This was originally documented the other way round. "the address is deterministic, so it can be shown before deployment", and it was a fund-loss path. It was caught by an existing repository-wide check that went red the moment the interface was written, not by a reviewer reading the sentence.

The shape that prevents it: recipientDeployed is required. Anything other than a confirmed deployment returns kind: "wait", and no address is rendered at all.

⚠️ An omitted recipientDeployed is treated as not deployed. The unsafe value is the convenient one, so it is never the default.

What the page must state

Testnet denomination, faucet-funded yield, and degraded oracle mode render unconditionally, a failed query cannot remove them.