autoyield handles a real-money path on Solana mainnet. This doc explains what we defend against, what's out of scope, and how to report issues.

This is a living document — last revised 2026-06-10.

Is:

• A read + tx-construction service. An AI agent calls our tools to compare yields, quote tokenized US equities, build unsigned Solana transactions, and look up tx confirmation status.
• A sign-page (autoyield.org/sign.html) where the user reviews the unsigned tx and signs it in their own Phantom wallet.

Isn't:

• A custodian. We never hold user funds.
• A signer. We never have access to private keys or seed phrases.
• A broker-dealer. We don't match orders or take possession of securities.
• An MTL/MSB. We don't transmit money; users transmit money via their own signed transactions to public protocols (Jupiter, Backed, Ondo).
• Investment advice. Yield rankings are data, not recommendations. See Disclaimer.

The boundary: every action that moves value requires the user's own signature in their own wallet. Our backend cannot move user funds on its own — there is no key in our infrastructure that has authority over any user wallet.

For autoyield to deliver its stated guarantees, we assume:

The assumptions about Jupiter / Backed / Ondo / Phantom are dependency-of-dependencies. autoyield does not re-verify what those parties claim; we compose their guarantees.

• User's wallet security. Phantom seed-phrase exposure, OS-level malware, browser extension supply chain, hardware wallet authenticity. We can't fix these and we don't claim to.
• Underlying protocol correctness. If Jupiter's router returns a bad quote, if Backed's xStock contract has a flaw, if Ondo USDY's mint / redemption is mispriced — we surface their data, we don't re-verify it.
• Issuer-side compliance / KYC. Backed (xStocks) and Ondo (USDY) enforce non-US-person restrictions at the contract / mint level. We do not onboard users and do not perform KYC; users connect their own wallet.
• MEV inside Jupiter. Slippage cap (1%) bounds the loss; we do not run private mempool / Jito bundles. A determined searcher with deep liquidity routes can still extract within the cap.
• Tax / reporting. Trade history is on-chain; tax reporting is the user's responsibility.
• Long-term issuer solvency. Backed dissolves / Ondo redeems / Solana halts: we don't insure any of these. Users hold the underlying redemption claim, not autoyield.

• Frontrunning a build → sign → broadcast cycle: a network observer who sees the unsigned tx between build and broadcast can frontrun via Jupiter's own pools. Defense would require private mempool routing, which we don't currently do.
• Long-lived sign-id leak in user's browser history / share buffer: if a sign URL leaks (and the underlying tx hasn't expired), the holder can read tx details (wallet, amount, expectedOut). They cannot broadcast — that requires the user's signature. Rebuild is capped but not blocked.
• WYSIWYS (What You See Is What You Sign) — NOW DEFENDED server-side (2026-05-24): /sign/broadcast simulates every signed tx before broadcasting and verifies the wallet's token balance deltas match the reviewed deal — it must receive the expected output mint (≥50% of the stashed minOut) and spend ≤1.5× the agreed input, else it BLOCKS (PREFLIGHT_ENFORCE=true). Validated on real mainnet txs in both directions (SPL↔SPL and Token-2022 xStock) with exact delta math. So there are now TWO independent WYSIWYS backstops: (1) Phantom's own signing prompt (simulates + shows true token deltas), and (2) autoyield's server-side preflight. The preflight blocks gross delta divergence (output redirected, wrong mint, massive over-spend); refuses to broadcast when the stash lacks a verification recipe (fail-closed); blocks txs that fail simulation outright (they'd fail on-chain anyway); and bounds native-SOL spend at 0.05 SOL. It fails OPEN only on genuine infra ambiguity (derive/ decode failure — never blocks a legit tx on our own infra error) and uses loose bounds so normal slippage passes. It still does not do byte-exact instruction equivalence; the delta-bounds approach is the pragmatic equivalent.
• Backend operator compromise: an attacker with control of the autoyield-api.fly.dev backend can return a different unsigned tx than the AI requested, and make the sign-page card display innocent amounts. They still cannot sign (no private key in the backend) and cannot defeat Phantom's prompt — Phantom simulates the real tx, so the user would see the real (malicious) token movements in Phantom regardless of what the card claims. Detection therefore relies on the user reading the Phantom prompt. Mitigations: open-source build, no signing key in the backend, and the enforcing pre-broadcast simulation check above.

No external paid audit has been performed. This is a deliberate trade-off: we operate no custom Solana programs, no smart contracts, no on-chain state machine — every chain-level action goes through Jupiter (audited) and protocols' own audited contracts (Backed, Ondo). Our attack surface is a stateless tx-construction service + a sign-page.

If you represent an institution that needs an external audit before integrating: contact us (below). We are open to commissioning one if a real customer needs it.

All on-chain proof is public:

• 55Agf6... — first mainnet swap
• 3EJ7Dy... — first Claude-MCP-driven mainnet swap
• Repo log: github.com/kaditang/agent-wallet-mcp

If you find a security issue, please don't open a public GitHub issue.

Preferred: Open a private Security Advisory on the repo. This is what GitHub's "security" tab is for, and it lets us collaborate privately.

Alternative: email windrunnertb@gmail.com with subject prefix [autoyield security]. PGP not required; if you'd prefer, include your own public key for the reply.

• Affected endpoint / file / commit hash
• Reproduction steps (curl / code snippet ideal)
• Impact: what an attacker could do
• Whether you've tested on mainnet (not required, but useful)

• Acknowledgment within 72 hours (we are a small team, but we triage seriously).
• A timeline to fix, ideally within 7 days for high-severity issues, 30 days for medium.
• Public credit in the changelog / SECURITY.md once the fix ships, if you want it (some researchers prefer anonymity).

We don't currently run a paid bug bounty program. autoyield is pre-revenue and bootstrapped; we can't responsibly commit to payouts we might not be able to honor. As we accumulate real users and revenue, this will change.

Please give us a reasonable window to fix before public disclosure (typically 30 days for medium-severity, 7 days for actively-exploitable). We commit to:

• Not threatening legal action against good-faith researchers
• Not requiring NDAs for normal vuln reports
• Crediting researchers who follow responsible disclosure

This is a precise technical claim, not marketing. To verify it yourself:

1. No private key in our infrastructure. Search the repo for any Keypair.fromSecretKey, any *.sign(...) call where * is anything we control, any reference to a base58-encoded private key. You won't find one for any user-funds-bearing pubkey. There used to be a stale SOL_AGENT_SECRET from the old V1.5 Squads design — it's been deleted from .env (commit dda1fc4, 2026-05-10).
2. Every action goes through signTransaction. Every build_*_tx tool returns base64-encoded unsigned bytes. The user signs in Phantom; we broadcast the bytes they signed. Our backend cannot mutate the already-signed tx (it would invalidate the signature).
3. Fly secrets list (audit yourself): the only sensitive vars in our deploy are SOL_RPC (Helius URL with API key), SENTRY_DSN, DEMO_TOKENS (legacy auth fallback, empty in prod), ALLOWED_ORIGINS, WEB_BASE_URL, PUBLIC_ORIGIN. None of these confer authority over any user wallet.
4. If our backend disappears tomorrow: your funds stay in your wallet. The xStocks and USDY you bought are SPL tokens on your address — you can swap them back via Jupiter directly, no autoyield required. You are never depending on us to give your money back.

If you want to verify what's running matches what's in the repo: the CI workflow builds the Docker image and flyctl deploy --remote-only ships it. The commit SHA is reflected in Sentry's release (when set) and in the GitHub Actions run. We don't yet provide reproducible Docker builds or attestations; this is a known gap.

We do not custody assets, do not match orders, do not transmit money, and do not provide investment advice. We aren't a broker-dealer, MTL, or MSB on our facts. We rely on the issuers (Backed, Ondo) for their respective securities compliance — including non-US-person restrictions enforced at the contract / mint level.

Terms cap our liability at the greater of fees you've paid us (currently $0) or $100. Use is at your own risk; see the Disclaimer for the full risk list.

• 2026-06-10 — Preflight hardened: simulation errors now fail CLOSED (a tx that fails simulation is blocked — it would fail on-chain anyway); native-SOL spend bounded at 0.05 SOL per tx; missing verification recipe in the stash refuses broadcast (fail-closed). Timing signal baseline is now same-market- regime aware (open/closed, America/New_York DST-correct). npm package ships a real stdio entry so npx -y @kaditang/agent-wallet-mcp works. Base58 wallet validation on all tools.
• 2026-06-02 — compare_yields field split: now returns topExecutable (best actionable today) + topByRiskAdjustedOverall (global best, may be read-only), with topByRiskAdjusted kept as a deprecated alias.
• 2026-05-28 — /healthz made liveness-only (blocking on live RPC caused Fly's 5s health-check timeout to restart the machine and drop MCP bridges); per-RPC-call timeout (RPC_CALL_TIMEOUT_MS, default 8000ms); 10-fix hardening batch including preflight fail-closed when the stash lacks a verification recipe.
• 2026-05-11 — Initial version. Reflects state at commit cefecb2.

If you've reviewed this doc and have suggestions, open a Security Advisory (preferred) or PR.