Limits and errors
Product bounds and the Move abort families surfaced by Trust Stack.
Trust Stack validates user-facing bounds before the wallet opens. The Move modules repeat critical checks because the chain—not the browser—is the security boundary.
Common limits
| Input | Bound |
|---|---|
| Token name | 32 UTF-8 bytes |
| Token symbol | 10 letters/numbers |
| Token decimals | 0–18 |
| Token icon/project URI | 512 bytes; HTTPS or IPFS |
| Multi-send recipients | 1–100 unique addresses |
| Merkle root/node | exactly 32 bytes |
| Merkle proof depth | at most 64 nodes |
| Digital Asset media | at most 20 MiB; approved image/GLB/glTF types |
| On-chain token amounts | positive integer base units that fit u64 |
| Addresses | canonicalizable, non-zero where ownership is assigned |
Abort families
Abort codes are module-local. Always interpret the code together with the package and module name.
| Module | Codes | Meaning |
|---|---|---|
token_factory | 1–7 | zero supply, invalid cap/fixed supply, wrong creator, disabled mint/burn, zero recipient |
fixed_lock | 1–7 | zero amount, invalid time/beneficiary, wrong signer, locked/already claimed, dispatchable asset |
vesting | 1–8 | zero input, invalid curve/schedule/steps, wrong beneficiary, nothing claimable, dispatchable asset |
batch_distribution | 1–8 | empty/mismatched/oversized batch, invalid recipient/amount, duplicate, overflow, dispatchable asset |
merkle_airdrop | 1–15 | invalid funding/root/seed/times/proof, inactive or repeated claim/reclaim, allocation overflow |
digital_asset_factory | 1–5 | invalid recipient/name/collection/URI or final owner mismatch |
digital_asset_lock | 1–8 | invalid time/beneficiary/ownership, locked/already claimed, transfer/custody failure |
payment_stream | 1–10 | invalid funding/schedule, wrong authority, no claim, cancellation/completion state, dispatchable asset |
staking_pool | 1–4, 6–12 | invalid amount/schedule/asset/address, lifecycle/authority/claim/recovery failure |
dexlyn_lp_lock | 1–7 | invalid amount/beneficiary/time/pool, wrong beneficiary, locked/already claimed |
Handling a failure
- Preserve the transaction hash if one exists.
- Read the VM status and exact module/code in SupraScan.
- Re-read the current object and vault state.
- Correct the input or lifecycle condition only after determining whether the prior transaction finalized.
- Do not retry a claim solely because the UI lost its response.
The TypeScript client converts known validation failures into field-level guidance before signing. Unexpected execution failures retain the transaction hash for investigation.