Wallet permissions per chain

When you initiate a redemption or swap, Nuvanté calls lockFunds on the chain adapter for your source asset. The engine records two addresses: yours as the sender, and ours as the operator.

The lock has a time limit. During normal settlement, the operator claims the funds. If the timeout passes and settlement hasn't claimed them, you can claim them back.

From the adapter contract (apps/engine/src/adapters/chain/adapter.ts):

• senderAccount is your wallet address. It can claim the funds back after timeoutAt.
• operatorAccount is Nuvanté's custody address. It can claim the funds at any point during settlement.
• timeoutAt is the deadline after which only the sender can claim the funds back.

Sandbox uses Stellar Testnet. The live adapter wraps Stellar's own Horizon API.

• You need a trustline. Your account has to have a trustline to the issued asset (for example GBPC from the issuer account) before it can hold or send the token. A missing trustline is the most common first-integration problem.
• You need a minimum XLM reserve. Stellar needs a base reserve of XLM to keep an account active, plus extra reserve for each trustline. A freshly funded account with no XLM will fail to receive, and the error can look like an API or asset problem. Fund it with enough XLM to cover the base reserve plus one trustline for each asset you hold.
• The lock is a claimable balance. On Stellar, the lock is a claimable balance. Nuvanté's operator account can claim it at any time, and your sender account can claim it back once the time limit passes. The adapter creates the claimable balance when lockFunds is called, so you don't need to grant an allowance.
• Who signs. The sender account signs the lock transaction. With self-custody that's you. With MPC or CaaS, your custody provider signs for you.

Sandbox uses the Polygon Amoy testnet (chain ID 80002). The generic EVM adapter is configured with an RPC endpoint and a chain ID, and Avalanche follows the same patterns.

• ERC-20 approve. Before the lock, your wallet calls approve(custodyContract, amount) on the ERC-20 token contract. This gives the custody contract an allowance to move your tokens.
• Gas token. Your account needs a native balance (MATIC on Polygon, AVAX on Avalanche) to pay gas for the approve and lock transactions. Keep this on top of the asset you're transacting.
• Who signs. You, or your MPC or CaaS provider, sign both the approve and the lock call. The custody contract acts as the escrow counterparty.
• Custody contract address. To be confirmed by the Nuvanté integration team before production use. The contract hasn't been deployed to Amoy yet.

Sandbox uses Solana Devnet. That's a different cluster from the validator testnet and from mainnet-beta.

• Associated Token Account (ATA). Your wallet needs an ATA for the SPL token you're transacting, created and funded to be rent-exempt before any hold or receive. It's a similar idea to a Stellar trustline, with different mechanics.
• Rent-exemption lamports. Creating an ATA needs a rent-exempt SOL balance in it. An underfunded ATA fails holds and receives, and the API won't show an error when it does.
• Who signs. Your wallet keypair, or your MPC or CaaS provider, signs both the ATA creation and the lock authorisation. On Devnet, finality is based on signatures and doesn't use confirmation depth.
• Program ID. To be confirmed by the Nuvanté integration team before production use.

• Custody models: self-custody, MPC and CaaS.
• Supported chains: setup guides for each chain.
• Sandbox assets: which issuer IDs and asset codes work for your participant.