AI agent documentation index: llms.txt. Raw markdown for any page is available by appending .md to the URL. Full content snapshot: llms-full.txt.
llms.txt — complete Cartesi documentation index. Append .md to any page URL for raw Markdown (e.g. /cartesi-rollups/2.0/development/building-an-application.md).
Skip to main content

Overview

These contracts power emergency withdrawal: the ability for users to recover their in-app balances straight from the base layer after an application is foreclosed, without a running node. For the concept and the operator procedure, see Foreclosure & Emergency Withdrawal.

How the pieces fit together

The withdrawal machinery lives partly on the Application contract and partly in a small set of supporting contracts:

PieceWhereRole
Foreclosure + withdrawal logicApplication (IApplicationForeclosure, IApplicationWithdrawal)foreclose, proveAccountsDriveMerkleRoot, withdraw, and the account/getter views
WithdrawalConfigpassed to the Application constructorGuardian, accounts-drive geometry, and the output builder to use
IWithdrawalOutputBuilderreferenced by the configTurns an account into a withdrawal output (static-called during withdraw)
UsdWithdrawalOutputBuilder (+ factory)one per ERC-20 tokenThe single-ERC-20 builder; emits a DelegateCallVoucher to a shared SafeERC20Transfer

The withdrawal flow, on-chain

  1. The guardian calls foreclose() → the application is frozen at its last-finalized state.
  2. Anyone calls proveAccountsDriveMerkleRoot() once, anchoring the accounts-drive root against the finalized machine state.
  3. Each user calls withdraw(account, proof). The Application validates the account against the anchored root, static-calls the configured output builder to build the transfer output, executes it, and marks the account withdrawn (single-use).

The four-way agreement

Emergency withdrawal only works if four descriptions of the accounts drive agree:

  1. the guest application actually writes account records with the layout it claims;
  2. the WithdrawalConfig (log2LeavesPerAccount, log2MaxNumOfAccounts, accountsDriveStartIndex) matches that layout;
  3. the proofs generated off-chain (via the machine tool) use those same parameters; and
  4. the output builder decodes the account encoding the guest produced.

If any of the four disagree, proofs fail to validate or funds cannot be built, so these values must be chosen together at deploy time. See drive geometry.

We use cookies to ensure that we give you the best experience on our website. By using the website, you agree to the use of cookies.