Trust model

Blink is operator-run. Custody of float, quoting, and execution all sit with a single first-party operator. This is a deliberate trade: it is what removes the message-passing wait and the guardian set, and it means the guarantees are narrower than a trust-minimized bridge’s. Be accurate about this with your users. The protocol does not claim to be trustless.

What the operator controls

Float on every chain, held in the solver vault it owns on EVM chains and in the treasury account on Solana and Sui, and in-flight deposits held in the escrow until they settle.
Pricing: the spread, the accepted size band, and which chains and tokens are quotable.
Execution: when fulfillments, refunds, and relayed gasless deposits are submitted, and at what gas price.
The owner keys that can pause deposits, withdraw float, change the executor, aggregator, voucher-signer, and BlinkBridger caller and target allowlists, and upgrade the router. On EVM chains the router is UUPS-upgradeable and the escrow, solver, and fee manager vaults are not; the Solana program and the Sui package are upgradeable by their upgrade authority, and an upgrade can change how the escrow pays out.

What the contract enforces

These hold regardless of operator intent, but they do not limit what an executor can pay out, so they do not stop a compromised executor from emptying the vaults. On EVM chains any executor can refund any amount the escrow holds to any address and pay any amount of float from the solver to any address, and the executor allowlist includes the router and BlinkBridger (the rebalancing contract, which lets any caller on its own allowlist send any amount of solver float into an allowlisted bridge or swap contract with calldata that caller chooses, including the recipient) as well as the operator wallets. On Solana and Sui the operator float sits in the treasury account itself, so the treasury key can send it anywhere without the program, and the same key can refund any amount of the escrow’s deposits to any address. On Sui, refund refuses only a quote hash that is already filled or voided and a deposit digest and ordinal it has already refunded; the treasury supplies both values itself, so neither check limits the amount, the recipient, or the number of refunds. The AdminCap holder can change the Sui treasury address at any time.

Enforced	Detail
Only allowlisted callers move float	Payouts are restricted to registered executors and to the callers that `BlinkBridger` allowlists; withdrawals to the owner.
Escrow funds have three exits	On EVM chains the escrow releases only to the solver contract, refunds only through a registered executor, and withdraws only through the owner. A refund can send any amount to any address, so an executor can redirect escrow funds.
Swap outputs meet their floor	A swap returning less than the minimum passed in the call reverts. On a fulfillment the operator supplies that minimum; the contract does not check it against the quote.
Surplus stays in the vault	Swap output above the output amount passed in the call is retained by the solver, never redirected. On a fulfillment the operator supplies that amount too.
Vouchers are signed and single-use	A referrer voucher requires a valid voucher-key signature and can be redeemed exactly once, to the referrer address embedded in it.
No standing operator allowances	Both vaults pay from their own balance, so no operator wallet holds a standing allowance on user funds. A Sui swap-first deposit grants the swap executor an allowance for exactly the quote’s `expected_amount_in` that expires within five minutes and can be spent only through the package’s source swap. On EVM chains a gasless deposit is authorized by a permit2 signature bound to one quote hash, not an open allowance to the operator; the approval it relies on is the user’s approval of the Permit2 contract, which the SDK and the router’s permit path set to the maximum.

Settlement before release is not on this list. The operator releases a deposit from the escrow, or refunds it, only after it settles past the per-chain deep-settlement depth, and the signer cluster refuses to sign a release or a refund for a deposit that has not; that is what keeps a deep reorg from un-funding float already committed elsewhere. The contracts do not check settlement: pullFromEscrow releases whatever amount an executor asks for.

Invariants for integrators

The quote hash binds the deposit. A deposit that does not match the stored parameters is refunded, never fulfilled at a different price.
One active order per quote. Enforced by a unique index. A duplicate deposit against the same hash does not produce two payouts.
Terminal states are final. fulfilled, refunded, refund_skipped, and support do not change afterwards. review is the one parked state; an operator can only return it to the normal flow or hand it to support, never pay it out directly.
Executors are interchangeable. Any executor can serve any order; removing one degrades nothing but coverage of its own in-flight transactions.

Failure modes worth designing for

Scenario	What your integration sees
Operator pauses a chain	`GetChains` reports `quote_enabled` false; new quotes on that chain fail. Existing orders continue.
Inventory exhausted on the destination	`GetQuote` fails with `insufficient inventory`. Nothing is deposited.
Price feed stale	`GetQuote` fails with `price unavailable`. Nothing is deposited.
Operator halts entirely	Deposits already made are refundable by the operator; new quotes stop. There is no user-callable escape hatch on the router.

The last row is the one to weigh. Funds in flight depend on the operator continuing to run. Size your exposure accordingly and prefer smaller, faster settlement over batching value into single large orders. See Security for the contract surface and audit status.

Overview

Concepts

What the operator controls

What the contract enforces

Invariants for integrators

Failure modes worth designing for

​What the operator controls

​What the contract enforces

​Invariants for integrators

​Failure modes worth designing for

What the operator controls

What the contract enforces

Invariants for integrators

Failure modes worth designing for