Velor

Pre-launch. Velor is in development. These docs describe the protocol as it will operate at mainnet launch: contract addresses, audit reports, execution-quality data, and live track records will be published here the moment they exist.

Part IV · Protocol

The policy engine

Mandates are enforced at three points:

  1. Intent admission: weights schema-valid (sum to exactly 10,000 bps including an explicit USDG weight ≥ cash floor), universe-only, position caps, cooldown elapsed, implied turnover within budget. Strategy turnover and flow-driven turnover are separate budgets: a heavy deposit day can't block a rebalance, and vice versa.
  2. Adapter invariants: output token must be a universe asset or USDG; recipient must be the vault; per-fill price within the mandate's deviation bound of the Chainlink mid.
  3. Post-trade settlement checks: realized portfolio within tolerance of targets; NAV continuity versus oracle-implied change. Rebalances are atomic: all fills settle or the whole intent reverts.

The leakage bound is the protocol's signature guardrail, and it exists at two levels. Per fill, the adapter rejects any trade whose proceeds fall below a floor derived from the Chainlink mid — a check the venue cannot influence. Per window, the vault re-reads NAV after the trades and reverts the entire settlement if NAV came in below what the oracle says it should have (maxBatchNavDeviationBps). Both are on-chain today.

Even a fully compromised strategist, agent, and executor colluding cannot extract more than those bounds allow per window. Bad strategy can lose money; that's disclosed market risk. Bad execution is mechanically bounded. The cumulative daily budget across windows (30–50 bps of NAV) is enforced off-chain in v1, by a monitor and a human checklist that gates every execution; on-chain cumulative enforcement ships when the executor role opens beyond first-party.