Ballast
Somnia testnetDocsLanding pageDashboardRepo

Custody

Collateral stays in your name, consent is a contract state with a cap and an expiry, and revoking is one transaction that nobody can block or delay.

On this page
  1. Whose money it is
  2. Consent has a shape
  3. Revocation
  4. What the owner cannot do
  5. The permission we chose not to take

Whose money it is#

Deposits sit in BallastVault recorded against your address. Unreserved balance is withdrawable unconditionally — not subject to the engine running, to a notice period, or to anyone’s approval.

The only balance you cannot withdraw is what is reserved against cover that is currently open, and that reservation is released when the position settles. Settling is permissionless, so it is not gated on us either.

A policy is explicit consent with three limits, all checked on every purchase:

  • A make-whole point — how deep a fall you want covered in full.
  • A premium ceiling — the most you will pay per window, as a share of your exposure. Checked per window rather than set as a constant, because the right price varies with the book.
  • An expiry — after which the engine can do nothing at all until you set a new one.

With no active policy the engine has no authority over the account. That is a contract state, not a flag in a database of ours.

Revocation#

One transaction, immediate, unblockablerevoke() is called by you and takes effect at once. There is no operator path that can set it, block it, delay it, or require anything of you first. Withdrawal of unreserved collateral is equally unconditional. Both are reachable in one action from Policy and Funds.

Revoking does not remove you from the cursor set. It clears the policy, which is what stops the buying — the engine finds no consent and skips the account. Leaving the set is a second transaction, withdrawEnrolment(), and it is also permissionless and also one action. Neither is a prerequisite for the other. This is stated because the two are easy to conflate: a reader who revokes has stopped the cover, but is still in the set the engine iterates until they leave it.

What the owner cannot do#

The owner can approve engines and configure assets. The owner cannot move user funds, and that is asserted rather than asserted-about: the vault’s test suite contains test_OwnerCannotWithdrawUserFunds, and every engine-only entry point reverts with NotEngine when called by anyone else.

There is one latent gap and it is written down rather than glossed: a reservation has no user-side escape if an engine were to reserve and then stop. It is currently unreachable — the only caller pairs reserve with spend atomically in one transaction, and a revert rolls both back — and the fix is a reservation expiry in the vault, which would mean redeploying a vault that holds a live deposit. It is recorded in Limitations so it is a decision rather than an oversight.

The permission we chose not to take#

dreamDEX has an OperatorPermissionsRegistry. Ballast deliberately does not use it.

Taking operator permission would let Ballast act on your dreamDEX account. Instead it is the trader of record: it holds positions in its own name, funded by collateral you deposited for that purpose. That means the worst case is bounded by what you deposited, and it means a vault that cannot touch your account is a smaller thing to trust than one that can and promises not to.