Security
Signo'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.
- Routes use provider interfaces. Ordinary same-chain X Layer swaps and supported Shield Execute swap legs on X Layer and Arbitrum use OKX DEX. Other ordinary wallet-signed EVM swaps, including Chat swaps on Arbitrum, and cross-chain bridges use LiFi. Solana uses Jupiter's official aggregator, alongside Signo's protocol adapters.
- External text cannot authorize a destination. A send recipient, withdrawal destination or approval spender must be grounded in the user's instruction or user-authored conversation history, an owned wallet, or a known protocol destination. An address found only in a webpage, tool result or assistant reply is not consent. An unconfirmed destination is refused before encoding; paste the intended address yourself and review it.
- 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. Signo 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 Signo is NOT
- Signo is not a custodian. Your keys stay in your wallet. Signo never holds funds.
- Signo is not a router. It composes intent into calldata that goes to LiFi, OKX DEX, Jupiter, and protocol-native interfaces. Those are the routers.
- Signo is not a prompt-enforced sandbox. Safety is real functional gating (tested 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
In the ordinary review-and-sign flow, transactions interact directly with the providers' contracts below, and your wallet shows the real destination.
The Terms of Service also define an optional delegated-execution rail built around a Signo smart contract called the Shield. A user registers a Permission from their own wallet with one action and the exact contracts it may call, one asset, per-action and lifetime limits, a condition, and an expiry. The Shield enforces the limits, and the part of the condition that the chain can read, on chain. The user can revoke the Permission on chain. The user can also pause it in the app. Pause stops Signo's signing service from submitting, and the Permission stays active on chain until the user revokes it. A Signo-operated signing service holds a restricted key that can call only the Shield and submits transactions that fit the Permission; it cannot widen the action, asset, limits, condition, or expiry. Signo never receives the user's keys or custody of their funds. This rail is live on X Layer and Arbitrum today and rolling out; outside a Permission, every transaction keeps the review-and-sign boundary described on this page.
| Provider | What Signo uses it for | Official deployments |
|---|---|---|
| LiFi | Swap + bridge routing and execution on EVM chains and cross-chain | Contract addresses |
| OKX DEX | Ordinary same-chain X Layer swaps; supported Shield Execute swap legs on X Layer and Arbitrum | Smart contracts |
| 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 and YT entry and exit, PT redemption and rollovers, LP entry and exit, and claims via the Pendle Router | Deployments |
| Saffron | Fixed-income vault entry, exit, and claim through Saffron UniV3Vault contracts | Vault app |
| Aero | Verified classic and Slipstream swap routes, classic liquidity, gauge stake / unstake and claims, Slipstream position-manager actions, and timed veAERO locks on Base; pools, gauges and managers are checked against Aero's factories and voter on-chain | Contracts |
| Lido | stETH staking, wstETH wrapping, withdrawal queue | Deployed contracts |
| Uniswap | Standard hookless v4 position entry; supported v3 and v4 position exits and fee claims; 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 |
The OKX contracts used by these routes are:
| Chain and route | OKX approval spender | OKX swap router |
|---|---|---|
| X Layer (196), ordinary swaps and Execute | 0x8b773d83bc66be128c60e07e17c8901f7a64f000 | 0x7c5bee2a8091c3ef39072f64f18fac913060aeaf |
| Arbitrum One (42161), Execute only | 0x70cbb871e8f30fc8ce23609e9e0ea87b6b222f58 | 0x09f94b5fc68e227c323a6fbae3bd98c97fd8c849 |
The approval spender and swap router are different addresses by design. In an ordinary wallet-signed OKX route, an approval goes to the token contract and names the OKX spender; a swap calls the router. An Execute permission instead approves the Shield, and its reviewed venues pin the OKX contracts used by the execution route. Do not substitute an OKX spender for the Shield approval. See Execute permissions and OKX's contract list.
If a required OKX route is unavailable, Signo refuses the swap rather than silently choosing LiFi. Ordinary Arbitrum Chat swaps and cross-chain bridges still use LiFi.
Transactions also use token approvals and, on supported routes, Uniswap's canonical Permit2 (0x000000000022D473030F116dDEE9F6B43aC78BA3). If a protocol or action is not listed here as a direct integration, Signo either reaches it through a supported aggregator, 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 Signo named in the Action Plan, or a token contract you hold. Signo's plan preview and sign-time checks name the protocol and action before the popup appears, so a mismatch between what Signo said and what your wallet shows is a signal to reject and report.
Public MCP and delegated execution
The keyless MCP tools can read public wallet data or create inactive drafts; they cannot claim a draft, sign a permission, call the execution service, or move funds. Keep review links private. A Notify/Prepare claim requires the owner wallet's message signature and Telegram link. A Shield proposal requires the named owner's on-chain permission authorization, which Signo verifies against the proposed terms before activating Execute.
Once authorized, an Execute agent can act without a fresh signature. Its cap is a maximum, not necessarily the amount spent; see firing sizes and fallback behavior. If the sizing model fails, nothing fires. The owner gets a message with a link to prepare the same action and sign it by hand. Permission checks apply to every firing that is sent. Rollout availability and the wallet's spending authorization are separate: possession of a draft link alone grants neither account-management access nor spending authority.
What runs the permission. The signing service's key is held in Google Cloud KMS, in a hardware security module, and only Signo's production service can use it. Armed permissions are checked hourly. Each execution is an on-chain transaction: the Shield emits a MandateFired event and the adapter emits its own (Transferred, Supplied, Repaid, RepaidWithCollateral or Transformed), so every firing is verifiable on the chain's explorer. Triggers the contract can read are re-checked on chain at execution time: the Aave oracle (Chainlink-backed) for price, the wallet's Aave account for health factor, the token contract for balance. Any other trigger an Execute agent watches is decided by Signo's hourly check; what keeps funds safe is the pinned action, its outcome check and the caps. Swap routes come from OKX DEX. The contract checks the output's value on chain against the oracle price, or against a fixed minimum. A swap of a token with no Chainlink price feed has no on-chain price check. Its caps are its only bound, and Signo refuses a route with over 15% price impact. Venues Signo routes through are re-checked daily; a firing through a venue whose code or owner changed is blocked until a person acknowledges it. Every hour Signo re-reads each permission from chain and corrects its own copy. Revoking on chain needs no Signo approval. It takes effect when the revocation is included in a block.
Review status
The Shield contracts went through 15 review passes. They have not been formally audited. The code, the tests and the review history are public in the signo-shield repository. The other safety claims on this page rest on the implementation: tested encoders for EVM and Solana calldata, fail-closed token resolution, sign-time re-encoding for perishable routes, and simulation before you sign where the chain and route support it.