Chiron

Why Chiron Exists ??

Robinhood announced Robinhood Agents at HOOD Summit on September 29, 2026. The product gives users dedicated agentic accounts with configurable limits and trade approvals enabled by default.

There is still an important trust question when users run multiple agents.

Robinhood says it does not control, supervise, monitor, recommend, or audit agents.
A normal spend-limit contract can verify that a transaction was signed by an authorized key, but it cannot tell the user what software produced that signature.

Once an owner gives an agent a private key, there is no on-chain proof of which software is actually using it.

Chiron addresses that gap.

We already have a lot of Interested users for Chiron :

Agent owners can run several AI agents while retaining control over which workloads are trusted.

Agent operators can serve multiple customer accounts from a single attested workload.

Inference providers can receive USDG payments tied to the specific model they were contracted to serve.

The Account

Chiron gives an AI agent its own trading account on Robinhood Chain without exposing the owner's private keys.

The account can hold USDG and Stock Tokens and trade through Uniswap v4. Only an agent key that has passed the account's admission process can trade.

The owner controls:

• Which agent software is allowed

• Maximum trade size for each token

• The approval threshold

• The rolling 24-hour spending limit

• Which AI model can be used for inference

Every trade also records the approved workload and the model receipt associated with the decision.

The goal is simple: the owner should be able to tell not just who signed a trade, but what software was allowed to sign it.

The Flow

Agent admission

The owner first approves a workload measurement.

The agent then provides an Intel TDX attestation quote containing its key and a fresh nonce.

The Stylus verifier checks the certificate chain back to Intel's root on-chain. The account only accepts the key when the measured workload matches one approved by the owner.

Executing a trade

Agents cannot submit arbitrary calldata.

Instead, they submit a typed trade containing the intended parameters.

Before execution, the account checks:

• Allowed pool

• Allowed token

• Per-trade limit

• Approval threshold

• Rolling 24-hour limit

The swap is executed through the canonical Uniswap v4 PoolManager.

The transaction fails if the account spends more than the declared amount or receives less than the minimum specified output.

Human approval

Trades above the configured threshold require approval from the account owner.

The owner signs the exact proposed trade. That transaction can only execute the approved trade once.

Recording the decision

The trade event includes the workload measurement of the agent and the inference receipt for the model that produced the decision.

A separate Stylus contract verifies the receipt using Ed25519.

Paying for inference

Inference is paid through Assay.

The account uses a USDG payment channel that releases payment only when the provider supplies a valid receipt identifying the model pinned by the owner.

This allows an operator to run one TDX workload for multiple customer accounts. Each account is still admitted independently using its own nonce.

The v3 factory also blocks Stock Token trades while a pending ERC-8056 uiMultiplier change leaves the account in CorporateActionPending.

What We Built

The main difference from a normal trading wallet is that Chiron verifies the workload itself.

The agent key is not trusted simply because the signature is valid.

The admission transaction verifies the TDX quote and only then stores the agent key.

The Stylus Verifier checks a fresh Phala gateway quote on-chain. The verification costs 2,371,819 gas.

We also tested the security model by removing or weakening 110 protections individually. 109 mutations were detected by the test suite.

Agent revocation is also on-chain. When an owner removes a workload measurement, the account immediately stops recognizing the corresponding agent. Its next execution fails with NotAgent.

Model Specific Payments

Chiron connects the trading account to Assay so inference costs become part of the account's security model.

A provider cannot simply submit a generic receipt and get paid. The receipt has to identify the model that the owner approved.

This means the account can enforce both:

1. Which software is allowed to trade.

2. Which model is allowed to generate the decisions being paid for.

Deployment

Robinhood Chain Testnet

Chain ID: 46630

End to End Test

The complete workflow was executed with real transactions.

An attested agent registered successfully and purchased the official TSLA Stock Token within its configured limit.

A trade above the limit was rejected.

A larger trade then went through after owner approval.

The owner subsequently removed the agent's approved measurement and the agent was unable to execute again.

We also tested two invalid cases:

• A stolen signer was rejected.

• A receipt referring to the wrong model was rejected.

The agent also successfully purchased TSLA using 1 USDG from a second TSLA/USDG pool that the account was authorized to use.

Assay on Arbitrum Sepolia

Chain ID: 421614

Assay:

0x3500DaF0ADcE615A0bEF108FF0751ABb34b1FfCC

Three real inference payments were processed through redeemWithReceipt using real Phala receipts.

The third transaction was:

0x4ed9077a367495ddfb1acf4a3bbc54bf4b79b0d9898e4614fbe9148ec12cf868

Channel 2 paid 0.90 USDG.

Testing

The project currently has:

• 314 Solidity tests across 21 suites

• 27 agent tests

• 40 Rust tests

• Mutation testing covering 110 security guards

• 109 detected mutations

A TDX attestation verifier was also not present in the 116 Arbitrum Open House Singapore projects retrieved from HackQuest's API on October 1, 2026.

Technology

Blockchain

Robinhood Chain, Uniswap v4 and the official TSLA Stock Token.

Confidential computing

Intel TDX, Phala Confidential AI Gateway and Phala Cloud TDX guests.

On-chain verification

Arbitrum Stylus, Rust, stylus-sdk, Ed25519 and TDX quote verification.

Payments

Paxos USDG and Assay.

Smart contracts

Solidity, Foundry and OpenZeppelin components including Ownable2Step, ReentrancyGuardTransient, ECDSA, ERC-1271 and SafeERC20.

Frontend and agent

TypeScript, viem, React and wagmi

Entire project was built during the hackathon