Settlement
Senticore executes trades off-chain and periodically anchors settlement state on-chain.
Settlement lifecycle
Active vs committed state
| State | Meaning |
|---|---|
| Active state | Latest sequencer-confirmed trading state |
| Committed market state | Market/order-book state covered by the checkpoint newStateRoot |
| Committed financial state | Account liabilities and exit entitlements covered by the checkpoint solvencyRoot and exitRoot |
| Withdrawable state | Claims 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.
Withdrawal proof path
Withdrawal proofs are available to the protected settlement/operator integration through:
GET /api/v1/protocol/withdraw-proof
This is not an anonymous public client endpoint in the current production
profile. It requires the operator proof credential. Wallet applications use the
normal signed withdrawal lifecycle and read
GET /api/v1/protocol/withdrawals/{account}:{nonce}?asset=... with a
read-scoped token bound to that account. Operators may use the proof route for
execution and recovery.
Integrations should treat withdrawal proofs as verification material and must distinguish proof availability from final on-chain execution.
Operational guarantees
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.