Security
Flip's defensible primitive is the deterministic, non-subvertible execution boundary between the AI and the wallet.
The trust model
- The model proposes intent. It cannot widen what actually gets signed.
- Calldata is built by audited encoders. EVM via LiFi (battle-tested across millions of swaps and bridges); Solana via Jupiter's official aggregator and Flip-owned protocol adapters.
- Asset resolution is fail-closed. A bare unverified token symbol is REFUSED rather than guessed (Solana symbol collisions = fund-loss footgun). Pasted mints are looked up directly and accepted only if the aggregator returns valid decimals.
- Transactions are checked before signature. Flip re-encodes perishable routes at sign time, applies deterministic gates for known unsafe or unsupported cases, and simulates transactions where the chain and route support it. Simulation can inform gas, route checks, and internal failure handling, but your wallet remains the final signing boundary.
- Idempotent platform-fee account creation when fees are configured. On Solana, if a platform fee is active, the fee account for the output token is created in the same transaction it's used, so Jupiter's fee-account-must-exist requirement is satisfied without losing trades to it.
What Flip is NOT
- Flip is not a custodian. Your keys stay in your wallet. Flip never holds funds.
- Flip is not a router. It composes intent into calldata that goes to LiFi, Jupiter, and protocol-native interfaces. Those are the routers.
- Flip is not a prompt-enforced sandbox. Safety is real functional gating (audited encoders, fail-closed resolution, sign-time re-encoding, simulation where supported), not "the system prompt told the AI to be safe." Prompt enforcement is a sieve; functional guards are a wall.
Smart contracts
Flip does not deploy smart contracts of its own. Every transaction you sign interacts directly with the providers' contracts below, and your wallet always shows the real destination.
| Provider | What Flip uses it for | Official deployments |
|---|---|---|
| LiFi | Swap + bridge routing and execution on EVM chains and cross-chain | Contract addresses |
| Jupiter | Solana swaps and staking routes (SOL, mSOL, JitoSOL) | Developer docs |
| Aave v3 | Lending deposits and withdrawals (Pool + WETH gateway) | Address book |
| Compound III | Lending (Comet) | Networks |
| Spark | SparkLend lending | Deployments |
| Sky (MakerDAO) | Savings vaults (sDAI, sUSDS, sUSDC) | Developer docs |
| Morpho | MetaMorpho vaults and direct Morpho Blue isolated-market collateral / borrow / repay actions | Addresses |
| Yearn | v3 vaults | v3 contracts |
| Pendle | PT entry, PT exit or redemption, PT rollovers, and YT entry via the Pendle Router | Deployments |
| Lido | stETH staking, wstETH wrapping, withdrawal queue | Deployed contracts |
| Uniswap | v3 and v4 liquidity positions, plus Permit2 approvals | v3 deployments / v4 deployments |
| Kamino | Solana lending and yield | Docs |
| Loopscale | Solana yield | Docs |
| Save (Solend) | Solana lending deposits and withdrawals | Program docs |
Beyond these, transactions touch only the standard pieces every wallet knows: approve() on the token contracts themselves, and Uniswap's canonical Permit2 (0x000000000022D473030F116dDEE9F6B43aC78BA3, same address on every chain). If a protocol or action is not listed here as a direct integration, Flip either reaches it through LiFi or Jupiter routing, treats it as read-only/discoverable, or refuses the action instead of guessing.
Verify before you sign. Your wallet's confirmation popup shows the destination contract address. It should always match one of the deployments published in the registries above, a router Flip named in the Action Plan, or a token contract you hold. Flip's plan preview and sign-time checks name the protocol and action before the popup appears, so a mismatch between what Flip said and what your wallet shows is a signal to reject and report.
Audits
External audits will be scheduled before any broad v1 distribution push. Until then the security claims here are backed by the implementation: audited encoders for EVM and Solana calldata, fail-closed token resolution, sign-time re-encoding for perishable routes, and simulation where the chain and route support it before the user is asked to sign.