Stake, Capacity, and Risk

OrchestratorV3's canonical RiskManager replaces named buyer tiers with continuous USDC-backed risk accounting. StakeVault owns token custody and reservations; RiskManager owns admission policy, position snapshots, penalties, chargeback accounting, and maturity.

The protocol does not impose tier thresholds, tier amount caps, tier concurrency limits, tier fee discounts, or tier cooldowns. Escrow can still enforce structural bounds needed for deposit ranges, intent lifecycle, iteration, and gas safety.

Protocol references:

• Stake-risk policy and formulas — follow the status stated in the specification
• RiskManager.sol
• StakeVault.sol
• Environment contract addresses

The deployed contracts are authoritative for active behavior. Mutable platform settings must be read from RiskManager.getPlatformRiskConfig(paymentMethod). Examples in the policy specification are illustrative, not production configuration.

Components

Component	Responsibility
OrchestratorV3	Snapshots the selected deposit risk hook and reports signal and terminal lifecycle transitions
RiskManager	Applies platform policy, chooses a risk mode, snapshots terms, calculates reservations and penalties, verifies chargeback evidence, and releases matured coverage
StakeVault	Custodies USDC stake and deferred payouts, enforces reservations, delays exits, credits seller compensation, and records delegation
DeferredPayoutHook	Atomically routes fulfilled net proceeds from an authorized Orchestrator into StakeVault

Two continuous curves

For an intent amount A, the manager snapshots the normal Escrow intent period T, griefing cliff C, griefing slope s in basis points per hour, chargeback reserve ratio r, and chargeback window.

Curve 1: maximum griefing bond

maxGriefingBond(A) =
  ceil(A * s * max(T - C, 0) / (10,000 * 1 hour))

While the intent is pending, the actual cancellation penalty is zero through the cliff and grows linearly afterward. Elapsed time is capped at the snapshotted normal intent period, so a guardian extension cannot increase maximum liability.

Fulfilment never charges this penalty. Cancellation, expiry, or cleanup after the cliff pays the accrued amount to the liquidity provider and releases the unused reservation.

Curve 2: chargeback reserve

For a chargebackable method:

chargebackReserve(A) = ceil(A * r / 10,000)

This is coverage, not an upfront fee. On fulfilment, the reservation is recalculated from the exact released amount and remains slashable during the snapshotted, half-open chargeback window. Coverage can be partial; a liquidity provider bears losses above the reserve and after the deadline.

Admission and capacity

The two outcomes are mutually exclusive while an order is pending: cancellation can create a griefing penalty, while fulfilment can create chargeback exposure. Admission therefore reserves:

requiredReservation(A) = max(maxGriefingBond(A), chargebackReserve(A))

Each curve can be inverted against current free stake to calculate a taking capacity. The smaller enabled curve is the platform's bonded taking capacity. Disabled curves do not constrain capacity.

All pending reservations and settled chargeback reservations draw from one shared stake-owner portfolio:

sum(pending reservations) + sum(settled coverage) <= eligible stake

Platform capacities are alternative views of that shared balance and must not be added together.

Free takes

A platform can configure a small number of lifetime, whole free intents per stake owner and payment method. They are possible only for non-chargebackable methods and reserve no stake.

• The entire intent must fit within the configured amount.
• There is no partial free tranche and no combining allowances.
• An allowance is consumed on successful signal and is never restored by cancellation, expiry, or failed fulfilment.
• A reverted signal consumes nothing.
• Free takes are an onboarding subsidy, not an identity or anti-Sybil boundary.

Delegated stake

The taker normally uses its own StakeVault balance. A stake owner can authorize another address to use the owner's portfolio for future intents. This supports a Safe or operator authorizing a relayer without transferring stake ownership.

Security properties include:

• only one delegated stake owner is active for a taker;
• a taker can clear an assignment and disable new delegation;
• a taker can allow only one specified future stake owner;
• revocation changes future intents only; existing positions retain their snapshotted owner; and
• a requested partial withdrawal immediately stops contributing to eligible capacity.

Stake owners must treat authorization as economic permission: an authorized taker can reserve shared stake and expose it to the snapshotted cancellation and chargeback rules.

Position lifecycle

Free

No stake is reserved or slashed. The consumed allowance remains consumed at every terminal outcome.

Stake-backed, non-chargebackable

Admission reserves the maximum griefing bond. Fulfilment releases it; cancellation or expiry slashes the time-based penalty and releases the rest.

Stake-backed, chargebackable

Admission reserves the larger curve. Cancellation follows griefing rules. Fulfilment resizes coverage to the exact released amount and retains it through the chargeback window. An authenticated chargeback compensates the seller up to the remaining covered amount; unused coverage is permissionlessly released at maturity.

Deferred payout

When enabled, this path is available only if free stake covers the griefing bond but not the normal chargeback reservation, and the intent selects the canonical deferred hook. Pending risk uses the griefing bond. On fulfilment, net proceeds are held in StakeVault for the chargeback window and become the slashable coverage. The beneficiary withdraws the unslashed remainder after maturity.

Chargeback evidence

submitChargeback verifies typed evidence bound to chain ID, RiskManager, Orchestrator, intent, payment method, requested amount, evidence identifier, nonce, and validity interval. Compensation is capped by both remaining released value and remaining coverage. A partial claim leaves the rest available until maturity.

The verifier is governance-configurable. Consumers should monitor verifier, platform-policy, pause, and deferred-hook update events.

Quote and capacity behavior

Curator's quote endpoints return valid liquidity candidates without applying wallet stake policy. Capacity is exposed separately because it changes with reservations, withdrawals, delegation, pauses, and platform configuration. A quote is informational; OrchestratorV3 plus RiskManager admission is authoritative and atomic.

Clients should:

1. display quote price, output, fees, route, and seller liquidity;
2. fetch stake and platform capacity for the intended taker;
3. distinguish each separate free take from bonded capacity;
4. warn that capacities share one stake-owner portfolio;
5. disclose partial coverage and the uncovered tail after the window;
6. disclose deferred payout and maturity before signing; and
7. never instruct fiat payment until signalIntent succeeds on-chain.

Operator safety

• Platform policy changes affect future admissions only; positions snapshot their terms.
• Disabling a platform or pausing admission does not rewrite existing liabilities.
• Terminal callbacks use bounded gas and fail open for Escrow liveness, with durable timestamps and permissionless reconciliation.
• StakeVault controller changes use a delayed two-step handover; existing reservations retain their recorded controller.
• Deposit/reservation pauses leave eligible withdrawal, compensation, deferred-payout withdrawal, reconciliation, and maturity paths available.
• A full exit blocks new reservations and cannot complete until its delay passes and all reservations are zero.
• Sellers opt into the risk hook and remain responsible for uncovered, post-window, and aggregate exposure.

V2 coexistence

OrchestratorV2 remains authorized for legacy deposits and active positions during migration. V3 risk accounting applies only to intents signalled through OrchestratorV3 for deposits using the selected risk hook. Indexers and clients must key records by chain, Orchestrator, RiskManager, and intent hash rather than assuming every intent uses one risk model.