Escrow Agreement

std.asset.EscrowAgreement[Asset] models conditional custody: one party deposits funds into an escrow account, and release or refund happens only through the contract's lifecycle rules.

Use it when the product needs a neutral holding state between payment intent and final settlement:

depositor -> escrow_account -> beneficiary
                         \-> depositor, if the arbiter resolves a dispute

Parties

| Role | Meaning | |------|---------| | depositor | Caller that initializes and funds the escrow | | beneficiary | Recipient when the escrow is released | | arbiter | Party allowed to resolve disputes | | escrow_account | Ledger address that actually custodies the token |

Lifecycle

init(beneficiary, arbiter, token_id, escrow_account, deadline) records the parties and custody account. deposit(amount) transfers tokens from the depositor into custody and credits the tracked Balance[Asset] position.

The happy path is release(). It can be called by the depositor or arbiter while the escrow is undisputed. Once a dispute exists, only the arbiter can release.

The refund path is:

dispute()         -> called by depositor or beneficiary
resolve_refund()  -> called by arbiter

resolve_refund() debits the escrow balance, transfers the held amount back to the depositor, and marks the escrow as released so it cannot be paid twice.

Accounting Safety

The escrow uses both ledger movement and internal Balance[Asset] state:

• ctx.transfer(token_id, depositor, escrow_account, amount) on deposit;
• credit(held, amount) to record custody;
• debit(held, amount) before release/refund;
• ctx.transfer(...) to the final recipient.

The no_double_release invariant requires that a released escrow has no remaining held balance.

Product Fit

This is intentionally simpler than a full trade-finance workflow. It is a good building block for marketplace payments, bilateral delivery-versus-payment flows, and operational holds where a separate contract or backend decides when the business condition is satisfied.