Wallet-Specific Signing
Desktop keys remain in the local encrypted vault. On web, Phantom or Solflare confirms transactions and the server never creates a production signer.
Whitepaper / v0.2.0
A Robinhood Chain-first path from intent to settlement.
An early-stage workspace centered on Robinhood Chain swaps and two-way Solana connectivity, with venue-specific preparation, wallet confirmation, and settlement tracking.
[00]
Important Notice
Silfable is an autonomous trading interface designed to help users research markets, evaluate opportunities, and execute on-chain actions with greater efficiency.
AI-generated analysis and decisions may be incomplete, delayed, or inaccurate. All transactions remain subject to the safeguards, limits, and wallet permissions configured by the user.
Digital assets are highly volatile and involve significant financial risk. Users remain responsible for reviewing their settings, understanding the risks involved, and deciding how Silfable is used.
[01]
Executive Summary
The decentralized finance (DeFi) ecosystem is becoming increasingly agentic. AI agents are beginning to search for information, analyze tokens, draft limit orders, and perform economic tasks for humans and businesses.
The difficult part is connecting flexible market research to predictable transaction handling without turning a model response into an unchecked wallet instruction.
Silfable is built around five core ideas:
- Intent-based research, deterministic transactions: AI may analyze markets and prepare actions, but supported transactions must pass venue-specific checks before execution.
- Wallet-specific signing: Desktop keys remain in the local encrypted vault; web signing remains in the connected browser wallet.
- Readable transaction records: Quotes, simulations, confirmations, rejections, and final outcomes remain distinguishable. Desktop records are stored locally.
- Reviewed web execution: Every supported web transaction requires browser-wallet confirmation. Full Access is desktop-only; web never stores a private key or signs in the cloud.
- Wallet-scoped authentication: Web access requires an expiring, one-time wallet challenge signature. It authenticates the workspace but never authorizes a transaction.
[02]
Current Status
| Status | Capability | Scope |
|---|---|---|
| Verified restricted | Robinhood Chain Swap | Controlled ETH-to-USDG and USDG-to-ETH swaps have completed. The active desktop EVM scope is Robinhood Chain only, using a verified Robinhood RPC and a pinned Uniswap-compatible route. |
| Verified restricted | Solana-Robinhood Bridge | Controlled Solana USDC-to-Robinhood USDG and Robinhood USDG-to-Solana USDC bridges have completed in web and desktop. Each transfer remains route-, liquidity-, RPC-, wallet-, and receipt-dependent. |
| Verified restricted | Jupiter Solana Swap | Controlled SOL-to-USDC and USDC-to-SOL Mainnet swaps have completed. Every new swap still requires a fresh quote, deterministic checks, explicit wallet approval, one-attempt broadcast, and receipt reconciliation. |
| Verified restricted | Pump.fun Token Launch | Controlled Mainnet token launches have completed through metadata publication, create_v2 preflight, exact final review, wallet approval, broadcast, and receipt verification. |
| Verified restricted | Auto DCA | Controlled DCA cycles have detected a due schedule, obtained a fresh quote, completed only after explicit wallet approval, and been reconciled on Mainnet. The schedule never signs on the user's behalf. |
| Verified restricted | TP/SL & Exits | Controlled TP/SL conditions have triggered a bounded Mainnet exit proposal and completed only after explicit wallet approval and receipt reconciliation. Triggering a condition never grants unattended signing authority. |
| Planned · desktop-only | Full Access / autonomous signing | Not production-available yet. Any future unattended signing must use a paired desktop agent and an encrypted local vault; Silfable web never receives a private key or runs a cloud signer. |
[03]
The Problem
Ambiguous Requests
Natural-language requests often omit the exact asset, network, amount, deadline, slippage, or destination needed to build a safe transaction.
Fragmented Workflows
Research, quoting, token metadata, wallet confirmation, and transaction tracking often live in separate tools with no shared context.
Long-Running Strategies
DCA and TP/SL conditions need durable schedules and state, while the resulting transaction must still use the signing model of the active web or desktop surface.
[04]
Product Direction
Silfable aims to become an open environment where humans and software agents can express an intended outcome, research the market, and securely execute that outcome without compromising custody.
A request may be expressed as:
> “Draft the immutable metadata and bounded fee plan for a Pump.fun Token Launch.”
> “Prepare a USDC-to-SOL swap proposal with slippage capped at 1%.”
Silfable coordinates the user request, AI provider, venue checks, local or browser-wallet signer, network-specific protocol, and final transaction record as one visible workflow.
[05]
Design Principles
Reviewed Web Transactions
The connected browser wallet must confirm every production web transaction. Full Access is desktop-only; the web service never stores a private key or signs in the cloud.
Persistent Strategies
DCA and TP/SL strategies retain their amounts, schedules, pause controls, and revoke controls. The active web or desktop app can prepare a fresh transaction for review, while signing remains with the selected wallet surface.
Deterministic Route Checks
Fee, slippage, allowlist, balance, and freshness requirements must pass before a supported transaction can reach wallet confirmation.
[06]
System Architecture
Encrypted Cloud State Layer
A cloud database for user preferences, chat state, and proposal metadata within defined limits. Production transaction keys are never stored by the web service.
High-Throughput Task Queue
A task queue foundation for scheduled monitoring and transaction preparation. Cloud execution jobs remain disabled.
[07]
Venue Model
Robinhood Chain is the active primary EVM environment through a pinned Uniswap-compatible route for ETH↔USDG. Two-way bridge support is explicitly limited to Robinhood USDG and Solana USDC. Solana remains available for Jupiter swaps and Pump.fun Token Launch.
Token Launch
AI may help draft public metadata, but the user confirms exact immutable content, creator wallet, fee caps, and the final launch approval.
Swap
Robinhood Chain ETH↔USDG swaps use a pinned Uniswap-compatible route. Connected Jupiter swaps retain separate typed contracts, provider evidence, policy, signer boundaries, and transaction recovery.
Bridge
Robinhood USDG to Solana USDC and the reverse direction have completed controlled web and desktop flows. No universal any-chain bridge claim is made.
Auto DCA & Exits
The active web or desktop runtime can monitor conditions, fetch a fresh quote, and open a bounded action for review. Each resulting transaction still requires explicit wallet approval.
[08]
Web And Desktop
Desktop
The reference surface for Robinhood Chain swaps, two-way Robinhood–Solana bridges, encrypted local-vault signing, and connected Jupiter Swap and Pump.fun Token Launch workflows. Other EVM chains are outside the active desktop product scope.
Web
Uses the single connected browser wallet for approval. It does not collect a secret key and does not yet provide execution parity with every desktop venue.