How they work

Containers are designed around one simple rule:

If a shared dWallet cap is inside a container, it’s not usable for signing.

That’s intentional. Signing is what changes reality on the source chain — moving NFTs, swapping tokens, changing approvals, rotating roles, etc. If a cap could sign while deposited, the wallet’s holdings could change at any moment and indexing would always be racing the truth. Containers solve that by separating “indexable custody” from “active usage.”

Deposited vs Withdrawn

Deposited = indexable + verifiable When a cap is deposited:

• the container is custodian of the signing authority

• DApps can reliably index the external wallet

• assets can be marked Verified after confirmation on the source chain

Withdrawn = usable for signing When a cap is withdrawn:

• the user regains signing ability for that external wallet

• they can move assets, transfer NFTs, interact with protocols, change roles, etc.

• anything previously verified should be treated as Unverified until it’s re-deposited and rechecked

In practice, this creates a lifecycle DApps can trust:

• deposit → verify

• withdraw → unverify

• re-deposit → re-verify

Claims (lightweight asset pointers)

Containers can also hold Claims — minimal pointers to cross-chain assets tied to a specific deposited cap. Claims are not wrapped NFTs and they don’t replace the source chain. They exist so DApps can render inventory instantly and consistently while verification happens in the background.

A claim can include:

• which cap controls it (cap_id)

• chain + standard (ETH ERC-721/1155, Solana NFTs, etc.)

• collection identifier (contract/mint)

• token identifier

• optional metadata hint (to speed up rendering/caching)

Claims let users express intent (“this belongs in my container”) and let DApps build stable identifiers for bundles, listings, and portfolio views.

Indexing (events are the interface)

Containers are event-first. Every important change emits an event so backends can keep state in sync without heavy polling. Typical events cover:

• container creation

• cap deposited / withdrawn

• claim added / removed

• (optional) frozen state toggled

DApps listen to these events to know exactly when to start indexing (deposit), stop treating a wallet as stable (withdraw), update verification state, and refresh metadata.

Verification and the Umi API

Umi provides verification through our indexing layer and API: we resolve container state, derive the external wallet address from the deposited cap, scan the source chain, and mark assets Verified/Unverified based on the container lifecycle.

DApps can always verify independently using their own chain RPCs/indexers (Ethereum, Solana, etc.). Umi exists to make this standardized and easy — but we still recommend DApps verify for themselves when it matters (settlement, high-value actions, custom trust requirements).