Skip to main content

Settlement

Senticore executes trades off-chain and periodically anchors settlement state on-chain.

Settlement lifecycle​

Active vs committed state​

StateMeaning
Active stateLatest sequencer-confirmed trading state
Committed market stateMarket/order-book state covered by the checkpoint newStateRoot
Committed financial stateAccount liabilities and exit entitlements covered by the checkpoint solvencyRoot and exitRoot
Withdrawable stateClaims that can be proven against a published withdraw root

The web application should clearly distinguish active trading balances from committed withdrawal availability. Under the current private-beta validator policy, an asset deposit may change the financial roots without changing the market-state root. Clients must not infer deposit failure from latestStateRoot alone.

Deposits​

Deposits go through the MultiCollateralVault on Arbitrum One, 0xd1f0fffb736d75fd402121eb14bdc46bfe80ca02 (see Contract addresses):

  • Call deposit(assetId, amount) after an ERC-20 approval, or depositWithPermit(...). Both credit msg.sender only; there is no deposit-for-another-account, so send the transaction from the wallet that owns the engine account you want funded.
  • assetId = keccak256(abi.encode(token, decimals, chainId)). Read the registered assets with their token addresses, decimals and assetId from GET /api/v1/public/assets (ARB, CKT, FYT, TCO, USDC, USDT, WBTC and ETH, listed as WETH) instead of deriving them by hand.
  • USDC is the native Arbitrum USDC 0xaf88d065e77c8cC2239327C5EDb3A432268e5831, not bridged USDC.e.
  • The engine credit arrives about 15–20 minutes after the on-chain deposit; the listener waits for confirmations before it credits. A freshly listed asset can take longer on its very first deposit while the listener catches up to the current block. Confirm the credit on GET /api/v1/accounts/{account} (usdcFree, assetBalances), not from the transaction receipt.

Withdrawal proof path​

Withdrawal proofs are available to authenticated wallet clients and the protected settlement/operator integration through:

GET /api/v1/protocol/withdraw-proof

This is not an anonymous public endpoint. Wallet applications use an existing approved Read credential bound to the requested wallet for both the proof route and GET /api/v1/protocol/withdrawals/{account}:{nonce}?asset=.... For a browser this is Authorization: Bearer <read-token>; refresh the existing delegated Read token before fetching the proof. A credential for a different wallet is not sufficient. Both responses are private, no-store.

Vault claims belong to the connected owner wallet, not a selected trading subaccount. Keep an existing withdrawal request and nonce when retrying a failed status/proof read; a read-authentication failure does not cancel the request or prove that a withdrawal transaction executed. The normal signed/on-chain withdrawal lifecycle is unchanged.

The existing operator proof credential remains supported for execution and recovery tooling, but must never be embedded in frontend code or given to users.

Integrations should treat withdrawal proofs as verification material and must distinguish proof availability from final on-chain execution.

Operational guarantees​

For outcome markets, committing a resolution starts the persistent resolved-position settlement flow; it does not itself prove every account has been credited. Oracle V2 finalization waits past the market's committed recovery deadline, and payout follows asynchronously. Valid YES/NO pays 1/0 USDC per share; V2 INVALID pays 0.50/0.50 with deterministic rounding. See Oracle and payout rules.

Settlement depends on:

  • durable sequencer logs,
  • projection consistency,
  • checkpoint construction,
  • publisher quorum signing,
  • on-chain contract execution,
  • incident runbooks for lag or drift.

For the custody contract, see MultiCollateralVault. For checkpoint anchoring, see StateCommitment.

Last updated on