Execution & risk

On-chain execution adapters

Native Solana and EVM execution behind the VenueAdapter interface — aggregator-first, with a hard sell-before-buy rule and explicit MEV and wallet controls.

CCXT covers supported exchanges; it does not cover new pools, launchpads and bonding curves. Native Solana and EVM adapters provide chain-level execution behind the same VenueAdapter interface the resolver uses.

Why a separate engine is required

CCXT covers supported exchanges; it does not cover new pools, launchpads and bonding curves. Many new tokens exist only on-chain, where execution needs chain-native logic that has no CEX equivalent:

pools not yet indexed by CCXT
launchpads & bonding curves
transaction construction
wallet signing
approvals & allowances
token-account creation
gas & priority fees
transaction simulation
private submission / MEV protection
contract & token-program validation
reorgs & dropped transactions
confirmation commitment

Both adapters sit behind the same VenueAdapter interface the resolver uses, so a strategy treats an on-chain swap and a CEX order identically — the chain-specific complexity is fully contained in the adapter.

Solana adapter

Jupiter handles routing, with selected native integrations where a launchpad or pool needs them. The adapter owns the full transaction lifecycle:

RPC selection and fallback
versioned transactions
recent-blockhash expiry
associated token accounts (ATAs)
Token Program vs Token-2022
compute-unit limits
priority fees
Jito / transaction-delivery options
transaction simulation
confirmation commitment
failed / expired transactions
balance reconciliation

Token-2022 matters specifically: its transfer-hook and transfer-fee extensions can change what an account actually receives, so the adapter resolves the token program before sizing. Versioned transactions and a fresh blockhash are mandatory — a stale blockhash silently expires the transaction, which the reliability layer treats as a failure, not a fill.

EVM adapter

An aggregator (0x or 1inch) plus direct protocol integrations, a fallback RPC and a private transaction path where available. Every zeroExFee, affiliate fee, gas estimate and route-level cost the provider returns is logged, so quoted and realized results can be compared per provider:

Concern	Default	Escalates to
Routing	Aggregator (0x / 1inch)	Direct DEX when an aggregator lacks the pool
RPC	Free / modest allocation	Paid capacity once landing rate / latency hurts PnL
Submission	Public path	Private / protected path where MEV risk is material

0x, 1inch and direct DEX integrations are compared on total route quality — fees, gas, reliability and realized output — not on the headline quote. Adapters are interchangeable behind the interface, so adding 1inch beside 0x is a configuration change.

Aggregator-first by default

Direct DEX integrations are reserved for proven strategic needs — a new pool the aggregator misses, excessive aggregator fees, a custom launchpad curve, latency-critical execution or better native execution. Each direct integration increases:

code volume and test surface;
audit surface and protocol-specific risk;
maintenance burden and dependency risk.

So the default stays aggregator-first, and a direct integration must earn its place.

MEV and execution risk

The adapter accounts for the full set of on-chain execution hazards, feeding each into the venue resolver’s cost comparison rather than discovering them after the fact:

front-running
sandwich attacks
back-running
malicious RPCs
public-mempool exposure
priority-fee competition
stale quotes
blockhash expiry
failed tx that still burns gas
partial fills

Do not buy unless you can sell

A buy quote is never sufficient. Before any on-chain buy, the adapter requires a realistic sell quote and simulation — honeypot behaviour, dynamic sell tax, blacklist or sell-restriction, exit liquidity and exit slippage are checked first. A failed check is a hard blocker.

Wallet separation

Keys are tiered so a single compromised hot wallet cannot drain the treasury:

Cold
Treasury walletlimited transfers out
Funding
Operational funding walletlimited balance
Hot
Per-strategy / per-chain walletstrict caps & permissions
Exec
Execution processsigns only within the hot-wallet caps

Private keys are encrypted at rest and never logged or stored in Convex; a maximum hot-wallet balance is enforced; withdrawals and bridge operations require human approval in early phases.