Trust Model

Senticore is not fully trustless. It is a hybrid venue: execution is off-chain, custody and settlement verification are on-chain.

Read before depositing

Understanding the trust model is critical before placing real funds at risk. The system is designed to reduce custody risk, not to eliminate every operator assumption.

What is trustless

Custody

User funds are held in MultiCollateralVault. Sentico Labs should not be able to arbitrarily move user funds. Withdrawals are intended to execute through proof-backed claims against published roots.

Withdrawal verification

A user can independently verify a withdrawal claim by:

1. Fetching the relevant withdrawal root from StateCommitment.
2. Constructing the withdrawal leaf from their claim.
3. Verifying the Merkle proof against the published root.
4. Executing the withdrawal through the vault contract.

Contract behavior

After deployment and verification, contract behavior is externally inspectable on-chain. Contract risk remains until the audited deployment is live.

You can always exit

This is the core of the non-custodial guarantee, and it is implemented on-chain today — not a roadmap item. Even if the operator disappears or tries to censor you, your committed balance is recoverable:

• Liveness exit (operator down). If no checkpoint is committed for 72 hours, anyone can call activateExitMode() on the vault. That freezes the last committed exitRoot, after which every user calls emergencyExit with a Merkle proof of their balance and withdraws directly from the contract — no operator involvement required. Post-checkpoint normal withdrawals are netted out so nobody can double-withdraw.
• Censorship escape (operator up but ignoring you). requestForcedWithdrawal is backed by a Merkle proof of your committed balance (you can't file for funds you don't hold, so it can't be used to grief the venue). After a 7-day grace period it escalates to global exit mode — unless the operator simply serves the withdrawal, which is the intended resolution.
• Self-execution survives pauses. A user executing their own committed withdrawal claim (msg.sender == claim.user) bypasses guardian withdrawal pauses. A censored user can always pull a committed claim. (The one exception is the abnormal-outflow circuit breaker, which is deliberately not bypassable to stop a forged-root drainer — genuinely censored users keep the exit-mode path.)

The escape hatches are proof-backed, not operator-discretionary — the contract checks your balance against the committed root, so the exit cannot pay out more than you actually hold, and the operator cannot suppress it.

What users must trust

Sequencer operator

The sequencer determines action ordering and matching. Users must trust the operator for:

• Fair ordering within the documented execution window.
• Liveness and operational uptime.
• Non-censorship of valid user actions.
• Correct replay and recovery procedures after incidents.

Publisher quorum

State commitments are signed by a publisher set. Users must trust that a quorum does not collude to publish invalid roots and that signing keys remain secure.

Off-chain matching

Trades happen off-chain first. Until a checkpoint is published, fills are sequencer-attested rather than chain-final. This creates a risk window between execution and settlement commitment.

The mitigant is determinism: matching runs on a single deterministic primary and every accepted action is written to a durable event log. Any published checkpoint is therefore independently re-executable - a third party can replay the log and confirm the committed state root was produced by the documented rules. This converts "trust the operator's matching" into "verify the operator's matching against a reproducible root."

Roadmap

Mechanism	Purpose	Status
Emergency / forced-withdrawal exit	Reduce sequencer liveness & censorship dependency	Implemented on-chain (see "You can always exit")
Additional publisher controls	Improve key-compromise response	Implemented (48h governance timelock; emergency rotation with cooldown)
Decentralized sequencing research	Explore reducing single-operator trust	Research only

Operational track record

The trust model above has been validated end-to-end during internal beta on real collateral. We have observed the full lifecycle from deposit through proof-backed withdrawal in operational conditions before opening the system to external users.

External validation through a tier-1 audit is scheduled for Q4 2026 to Q1 2027 before public mainnet.

Independent verification

Claim	How to verify
Vault holds supported collateral	Inspect MultiCollateralVault balances on-chain
A checkpoint was published	Query StateCommitment events and state
A withdrawal is valid	Verify Merkle proof against the withdraw root
Publisher set membership	Inspect publisher registry state
The engine produced the committed root	Replay the published event log and recompute the state root - a deterministic engine yields the exact root committed on-chain
You can exit without the operator	Inspect EXIT_MODE_TIMEOUT_SEC (72h) and the activateExitMode / emergencyExit functions on the vault

Compared to alternatives

Trust dimension	Centralized exchange	Senticore	Fully on-chain DEX
Custody trust	Required	Minimized	Minimized
Order fairness trust	Required	Required within model	Usually not required
Sequencer trust	Required	Required with verifiability	Not applicable
Latency	Sub-ms	Single-digit-ms target	Block-time
Advanced order types	Strong	Strong target	Limited