Vaults & Non-Custodial

The security model

A XERION vault is a Shared Object on Sui with a hard rule baked into the Move code:

• Withdrawals are only possible with the OwnerCap — an object placed in your wallet when the vault is created.
• The operator (our bot) gets no withdrawal rights whatsoever. It can only act within a session.

Sessions: how the bot trades without being able to steal

Every bot action runs as one atomic transaction, following the hot-potato pattern:

begin(session) -> borrow(amount) -> [DEX action] -> put(back) -> settle()

• borrow lends capital out of the vault within the same transaction.
• settle checks on-chain: the returned value must be at least stake - slippage limit (your policy parameter). If not, the entire transaction fails — the capital never actually left the vault.
• A session can't stay open: the session object has no store ability ("hot potato") and must be consumed within the same transaction.

LP positions (e.g. Cetus NFTs) are held non-custodially inside the vault itself — not in a bot wallet.

Additional protection layers

Mechanism	Effect
Adapter registry	The vault only accepts explicitly allow-listed strategy modules (witness allowlist).
Operator rotation	The operator key can be rotated without touching any vault.
Kill switch	The operator hub can be paused centrally — sessions become impossible, withdrawing via OwnerCap always stays possible.
Per-vault policy	Slippage limits and strategy parameters live in your vault, not in the bot.

What happens if XERION goes offline?

Nothing bad: your capital sits in the vault on-chain. The app is just a window onto it. Withdrawing via OwnerCap also works directly against the contract — independent of our infrastructure. See FAQ for the step-by-step.