FIDES is live on Robinhood Chain via Pons.
Build complete agent transaction flows across MCP, x402 and onchain actions, with authorization built into the execution path.
- owner sets budget, assets, contracts, services, limits and expiry, and signs once
- agent actions are built into one execution plan
- every action is checked against the signed FIDES before it runs
- compatible calls and payments are grouped
- only the required transactions go onchain
agent workflow → FIDES Builder → group + verify → execute
contracts deployed and source-verified on mainnet. app, SDK, CLI, API and Claude extension available now.
https://t.co/hOfT921NMS
OFFICIAL CA : 0x44114d6f66202a267b92bdbb57ae81480a86f0b3
deploying FIDES NET to Robinhood Chain.
FidesNetRoots: 0x2f57277b2170d189c6329cbd0e796ae9a984dd8c
deploy tx: https://t.co/ds1xD4teTX
verified source: https://t.co/KF9PkNZjZu
what it does:
- publish(epoch, obligationsRoot, settlementRoot) one round of netting, committed onchain
- two roots: every obligation it was computed from, every transfer that settles it
- immutable: a round can't be overwritten once published
- verifyObligation / verifyTransfer: prove any single payment against the roots with a Merkle proof
- no admin, no owner, no upgrade path
the netting itself runs in the Builder. the settlement goes through the FIDES Account, checked and simulated like every other bundle.
the contract is the public record anyone can check it against. preparing for 01 release.
What if agents only settled what they actually owed?
Here’s a simple example of FIDES NET.
4 payments between 3 agents:
• A owes B 5 USDG
• B owes A 3 USDG
• B owes C 2 USDG
• C owes A 1 USDG
That’s 11 USDG across 4 separate payments.
Now net the balances:
• A owes 5, but is owed 4 → net −1
• B owes 5, but is owed 5 → net 0
• C owes 1, but is owed 2 → net +1
The result?
A pays C just 1 USDG. B doesn’t need to transfer anything.
4 payments → 1 settlement transfer.
Same final balances. 10 USDG less movement. 3 fewer transfers.
That’s FIDES NET. Instead of settling every individual agent payment, we calculate what each participant actually owes and settle the difference.
01 / FIDES NET drops tonight on Robinhood Chain.
https://t.co/hOfT921NMS
We’ve been building towards exactly this with FIDES.
Agents are getting access to MCP tools, payment rails and onchain execution. But they still need spending limits enforced at the contract level, and a way to execute without sending a separate transaction for every action.
Our Transaction Builder is already live on Robinhood Chain.
Tonight we’re shipping FIDES NET, adding payment netting so agents can settle final balances instead of every individual payment.
Each release extends the same execution infrastructure we’ve been building from the ground up. @RobinhoodApp@vladtenev
Crypto doesn't sleep. Neither does your agent.
AI agents can trade crypto on Robinhood in a dedicated account, on your terms, 24/7. Not available in NY.
An agent doing one job doesn't make one transaction.
It makes a pile of them. Service calls, approvals, payments, transfers. Each one its own signature, its own transaction, its own chance to go wrong.
The FIDES SDK turns that into one plan.
npm install @fidesbuild/sdk
Load a signed FIDES. Hand the Builder the agent's actions. Simulate. Execute.
Every action is checked against the FIDES before anything is sent.
5 actions in.
3 authorized.
1 over the spend limit, blocked.
1 calling a contract nobody allowed, blocked.
3 calls out, as 1 transaction on Robinhood Chain.
One signed scope. One execution plan.
FIDES. Transaction Builder for autonomous agents.
https://t.co/xAP4GRkK7w
Why we built FIDES.
AI agents are moving onto Robinhood Chain.
They trade 24/7, pay for APIs and data over agent payment rails, spend through MCP servers and run workflows nobody watches in real time.
The models got smart. The execution underneath didn't:
- give the agent a hot key with full access, or approve every move yourself
- every payment and action sent as its own transaction
- limits living in an app setting the agent can route around
- no proof of what the agent was allowed to do
So we built the execution layer agents on Robinhood Chain run through. All our own tech.
1. Limits signed once
One FIDES (EIP-712): budget per token, allowed contracts and functions, paid services with caps, expiry.
The agent gets a session key with no funds and no gas.
2. Enforced onchain
Funds sit in a FIDES Account. Every bundle passes the Verifier: signature, nonce, time window, revocation, policy on every call.
The agent can be wrong. The limits still hold.
3. A Builder, not a signer
The agent hands over actions. The Builder checks each one, groups what can go together, simulates, and sends only the required transactions.
Paid API calls, MCP tool calls and onchain actions, one authorized path.
4. No gas, full record
A relayer submits bundles. Receipts land onchain for everything executed.
That's live today.
Where the agent meta goes next, and what we're building for it:
→ agents paying many services all day: FIDES NET nets it down to the final positions. Release 01.
→ agents hiring agents: SUB-FIDES, a child can never exceed its parent
→ agents running 24/7 on a schedule: LONG FIDES, limits that reset daily or weekly
→ agents choosing how to execute: FIDES ROUTER, cheapest valid route wins
→ agents finding services themselves: SERVICE MANIFESTS
→ agents with strategies worth hiding: PRIVATE FIDES, zero-knowledge
→ agents proving they followed the rules: FIDES PROOF
Agents are coming to Robinhood Chain either way.
We're building the rails they execute on.
https://t.co/xAP4GRkK7w
The FIDES roadmap is here.
We're building the execution layer for autonomous agents on Robinhood Chain.
Agents are about to move real money onchain: paying for services, running workflows, managing assets.
Right now they either hold a wallet that can do anything, or wait for a human to approve every step.
FIDES fixes that. You sign the limits once. The Transaction Builder turns everything the agent does into one plan, checks it against your limits, groups it and only sends the transactions that need to go.
That's live today. Here's where it goes next. 7 releases:
01 FIDES NET
Agents paying many services means hundreds of tiny payments.
NET adds up who owes what and settles only the final balances.
→ far fewer transactions as agents scale.
02 SUB-FIDES
Your agent can hire another agent and hand it part of its budget.
The second agent can never go beyond what the first was allowed.
→ agent teams, safely.
03 FIDES ROUTER
For any job, the Builder plans several ways to do it, simulates them all and picks the cheapest one that works.
→ agents that don't waste money.
04 LONG FIDES
Sign once and the agent runs on a schedule, with limits that reset every day or week.
→ set it up and leave it running, revoke anytime.
05 SERVICE MANIFESTS
Services publish what they do and what they cost in a format the Builder reads.
→ agents find and use new services without anyone wiring them in.
06 PRIVATE FIDES
Prove the agent stayed inside its limits without showing the limits, the services or the strategy.
→ privacy for serious money, using zero-knowledge proofs.
07 FIDES PROOF
One proof linking your signature to everything the agent did onchain.
→ anyone can check an agent followed its rules without trusting us.
The infrastructure autonomous execution runs through.
Builders: npm i @fidesbuild/sdk
https://t.co/xAP4GRkK7w
What you can do with FIDES. Live on Robinhood Chain.
01 / Agent Authorization
Set budgets, approved contracts, assets and expiry. Agents execute within signed limits. Anything outside gets rejected.
02 / Payment rails
Agents pay for APIs and services directly from their authorized budget. Every payment tracked.
03 / MCP Execution
Every tool call checked against FIDES policy before reaching the MCP server.
04 / Transaction Builder
Plans, verifies, simulates and groups agent actions into fewer onchain transactions.
05 / Gasless Execution
Hosted relayer handles submission. Agent keys need zero ETH.
06 / Claude Integration
Run authorized workflows directly from Claude Desktop or Claude Code.
07 / Receipts & Revocation
Track spending, inspect executions, withdraw funds or revoke permissions anytime.
Built in-house:
Transaction Builder, FIDES Account, Verifier, policy contracts, SDK, CLI, API, MCP + x402 adapters.
One signed authorization across the entire execution path.
FIDES - Transaction Builder for autonomous agents.
https://t.co/LNVWawaqqV
First FIDES transactions on Robinhood Chain. Executed entirely through Claude set up as an example.
One prompt. Plain English.
1. Authorization
Signed one FIDES:
• 2.7 USDG budget
• Paid API capped at 0.1 USDG
• 7-day expiry
2. Paid API
Claude purchased live chain data through a paid API. 0.01 USDG deducted from the budget.
3. Transaction Builder
Claude planned 4 payments.
• 3 passed FIDES authorization checks
• 1 exceeded the budget (3 USDG) - blocked before execution
4. Execution
• Transactions simulated before submission
• 3 payments grouped into 1 onchain transaction
• Gas covered by the FIDES relayer
• No ETH required by the agent
Remaining budget: 2.08 / 2.7 USDG
MCP tools, paid APIs and onchain payments operating under one signed authorization.
First execution, verifiable onchain.
TX: https://t.co/EPgmfDA3rs
Docs: https://t.co/LNVWawaqqV
FIDES is on npm. 📦
Our own Transaction Builder for autonomous agents. Live on Robinhood Chain.
Agents doing real work fire off a pile of separate actions.
Every one is its own signature, its own transaction, its own gas.
FIDES builds them into one.
Example: an agent runs weekly payouts.
5 contributors, 2 invoices. 7 payments in USDG.
Without FIDES:
→ 7 approvals from you
→ 7 separate transactions
→ 7 gas payments, so the agent needs ETH
→ an agent wallet that can send anything, anywhere
With FIDES:
→ you sign once: 500 USDG a week, these addresses only, 30 days
→ the agent plans all 7 payments
→ Builder checks each one against your limits and simulates the batch
→ 7 payments go out as 1 transaction
→ gas paid by the relayer, agent holds 0 ETH
The agent then tries an 8th payment to an address you never allowed.
Blocked. Never sent.
Same path for MCP tool calls, agent payment rails and contract calls.
The FIDES Stack, all built in-house:
◈ @fidesbuild/core: FIDES format, EIP-712, Builder planning
◈ @fidesbuild/contracts: deployed contracts on Robinhood Chain
◈ @fidesbuild/sdk: create, verify, build, simulate, execute
◈ @fidesbuild/x402: agent payments inside signed budgets
◈ @fidesbuild/mcp: every MCP tool call checked first
◈ @fidesbuild/cli: run and manage it from the terminal
◈ @fidesbuild/mcp-server: Claude integration, gasless execution
Not a wallet. Not an agent.
The execution layer agents run through.
📦 npm i @fidesbuild/sdk
https://t.co/Ro86jUmfLU
https://t.co/xAP4GRkK7w
we didn't launch FIDES with one way in. we launched with three.
app: create and sign a FIDES, fund your FIDES Account, run transfers and contract calls, withdraw or revoke. connect a wallet, nothing to install.
claude: add the FIDES extension to Claude Desktop, or in Claude Code:
claude mcp add fides -- npx -y @fidesbuild/mcp-server@latest
then say "Set up FIDES" and sign your limits once.
sdk / cli / api: for agent builders. MCP and payment adapters included, plus a hosted relayer so your agent needs no gas.
npm install @fidesbuild/sdk viem
same signed FIDES across all three. funds stay in your account.
install and setup:
https://t.co/3cmzA8kHeb
Team tokens officially burned. Verifiable onchain.
$FIDES is live on Robinhood Chain.
Transaction infrastructure for autonomous agents. One Builder for MCP, x402 and onchain execution, with authorization built into every step.
https://t.co/hOfT921NMS
Burn TX:
https://t.co/PMFPqxRoZQ
fides is a transaction builder for autonomous agents.
the user sets budget, assets, contracts, services, limits and expiry. agent actions are built into one execution plan. every action is checked against the original oath, compatible calls and payments are grouped, and only the required transactions go onchain.
agent workflow → oath builder → group + verify → execute
fides contracts are on robinhood chain mainnet
factory 0x5acc1cf7bb580ffeedd2d1a0d325f57254ac54ca
account impl 0x861fb06b7a28c770d0fcc05ee75ecab06fe50f86
verifier 0xb31b4add508b12bb92eb8c3dcc370e9fe9723274
policy 0x29a127fdbc885ba78b11b04447d5ca0be346f5a6
revocation 0xe7432ae5d7b16f888e9cea070cf4cb2d60ea2cf6
receipts 0xe94cd83415a585f2a2b06315411056a42f9327e0
accounts are 1167 clones off the factory, one per owner, address is deterministic.
owner signs one eip-712 scope: agent key, spend caps, target + selector allowlist, services, max actions, expiry.
agent signs bundles against it. the account checks every call against the scope, counts spend by balance delta,
bitmap nonces for replay. anyone can relay, relayer has no authority.
sigs go ecdsa first, then 1271. revoke is one tx from the owner.
solc 0.8.28, via-ir, 800 runs. verified on sourcify, exact match on creation + runtime:
https://t.co/xVz8JxS8f3
FIDES
Transaction Builder for autonomous agents.
Builds complete agent transaction flows across MCP, x402 and onchain actions, with authorization built into the execution path.
• User sets budget, assets, contracts, services, limits and expiry
• Agent actions are built into one execution plan
• Compatible calls and payments are grouped through the Transaction Builder
• One authorization can cover the full workflow
• Removes repeated approvals, signatures and unnecessary transaction steps
• Every action is checked against the original FIDES before execution
• Only the required transactions are sent onchain
Agent workflow → FIDES Builder → Group + Verify → Execute
24/7 agent loops make execution permissions even more important.
robinhood is bringing trade approvals into agents. oath extends that idea to onchain workflows.
one owner-signed boundary for budgets, contracts, services and expiry. every mcp, x402 and onchain action verified before execution.
Introducing Robinhood Agents. 🔥
With Agents, anyone can now build their own agent directly inside Robinhood and get started with agentic trading. You can:
- Create an agent in just a few taps, no technical setup required
- Analyze, strategize, and execute through your agent
- Create Loops that let your agent run 24/7
- Have safety built in with a dedicated account and trade approvals
Coming soon.
an agent doing one job doesn't make one transaction.
it calls a service, pays for it, approves a token, calls a contract, pays again. every step is its own approval, its own signature, its own transaction.
nothing looks at the whole workflow before it starts hitting the chain.