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.
Start here / v0.1.0
Build on Robinhood.
Stay connected to Solana.
Silfable is a Robinhood Chain-first trading workspace for supported ETH↔USDG swaps and two-way Robinhood USDG↔Solana USDC bridges. Solana remains available for Jupiter swaps, Pump.fun launches, and connected settlement workflows.
Robinhood Chain · 4663
Solana connected
Result tracked
01
Quick start
Choose web or desktop, configure the providers required by your network, then open a workspace with the wallet you intend to use.
- 01ChooseUse desktop for encrypted local-vault signing, or web with a connected browser wallet.
- 02ConfigureVerify Robinhood Chain ID 4663 and its RPC first, then add the providers and transaction limits required by your workflow.
- 03DescribeSelect a Robinhood wallet for the primary workspace, or choose Solana for a connected workflow. Opening a workspace does not authorize a transaction.
- 04ReviewInspect the assets, amount, route, simulation, fees, and quote freshness. Confirm the action, then follow its final status.
02
Core concepts
Three concepts explain how a request moves from an idea to a supported market action.
Workspace
Keeps market research, wallet context, transaction previews, and final status together.
Workflow
Turns a request into venue-specific steps with the exact inputs required for that action.
Route check
Validates identity, amount, fee, route, freshness, and venue requirements before confirmation.
03
Transaction settings
Global limits define the amounts, fees, slippage, and venues Silfable may present for confirmation. A new request cannot silently raise them.
If required route data is missing, stale, or outside your configured limits, Silfable stops the action before wallet confirmation.
04
Transaction lifecycle
Each action moves through explicit stages, allowing the interface to distinguish preparation from an onchain result.
01PreparedSilfable gathers the required parameters and creates a venue-specific transaction preview.
02ValidatedRoute checks validate the wallet, assets, amount, limits, provider response, and quote freshness.
03SimulatedAn unsigned transaction is inspected and simulated where the venue supports it.
04ConfirmedFresh validation passes and the user authorizes one signing attempt in the active wallet surface.
05TrackedSuccess, failure, or an unresolved broadcast is checked independently and saved to the transaction record.
05
Security model
Silfable keeps wallet signing, route validation, provider responses, and transaction outcomes in clearly defined parts of the system.
Wallet-specific signing
Desktop keys remain in the encrypted local vault; web confirmations remain inside the connected browser wallet.
Bounded workflows
Each workspace uses the markets, sizes, and actions allowed by the active transaction settings.
Checks before confirmation
Silfable evaluates route and limit requirements before asking the active wallet to sign.
Stops on uncertainty
Unavailable price data, invalid routes, or incomplete provider evidence stop the action instead of being ignored.
06
Transaction records
A transaction record captures what was prepared, validated, simulated, confirmed, broadcast, and checked afterward. A quote or simulation is never presented as settlement.
| Event | Recorded data | Retention |
|---|---|---|
| Observation | Source, timestamp, market snapshot | Local |
| Policy check | Rule inputs, result, reason | Local |
| Execution | Route, signature, settlement state | Local + chain |
07
Capability status
Implemented code is not the same as production clearance. Each mutable lane retains an independent release gate.
| Lane | Current state | Release boundary |
|---|---|---|
| Solana Swap | Verified restricted Jupiter path | Fresh checks and explicit wallet approval remain mandatory |
| Token Launch | Verified restricted Pump.fun desktop and browser-wallet web implementation | Unsigned simulation, exact final review, explicit signing, and receipt verification remain mandatory |
| Robinhood Swap | Verified restricted ETH-USDG execution | Healthy Robinhood RPC, live route, balance, gas, and wallet approval are required |
| Bridge | Verified restricted Solana-Robinhood execution in both directions | Provider route, liquidity, source confirmation, and destination settlement are checked per transfer |
| DCA / TP-SL | Verified restricted monitoring, proposal, wallet-approval, and receipt lifecycle | No autonomous signing or unattended broadcast |
08
Troubleshooting
A proposal is blocked
Confirm the wallet network, exact asset identity, amount, provider configuration, deadline, and global transaction limits.
Wallet signature is not requested
Confirm the session reached approval state and the proposed action passed every policy check.
Runtime shows stale market data
Refresh the wallet, verify RPC connectivity, and request a new quote. Never reuse stale simulation evidence.
A receipt is missing
Check the local workspace path and available disk space. Silfable fails closed when receipt storage is unavailable.