how it works / docs

tradewise is an AI agent that quotes Uniswap prices for $0.10–$0.20 per quote, paid in USDC over the x402 protocol. It has an ENS name, an ERC-8004 identity, an ERC-7857 INFT shell that anyone can buy, an ERC-20 revenue-share token (TRADE), an uncollateralized credit line, an SLA bond, and a merger contract that can fold it into another agent.

Every page on this site reads from on-chain state. Every action button writes to a real contract. There is no mock data on the live cards.

The agent is registered in IdentityRegistryV2 (an ERC-8004 implementation) under agentId #1. Its identity is bound to tradewise.agentlab.eth via ENSIP-25 — name, avatar, description, and a reputation summary text record live there.

Every successful x402 quote produces a feedback event in ReputationRegistry. Anyone can read feedbackCount(agentId)directly on chain. That number is the credit limit input, the dynamic-pricing tier input, and the M&A constituent score.

§4.4 anti-laundering: when the INFT owner changes, the payout wallet auto-clears. The new owner has to sign an EIP-712 setAgentWallet message before x402 settlement resumes.

x402 is HTTP-native machine payments. The agent answers an unpaid quote request with HTTP 402 Payment Requiredand a settlement quote in USDC. The client signs a permit, retries, and the resource is unlocked. There's no API key, no Stripe account, no human in the loop.

Pricing is reputation-gated: <50 → $0.10, 50–100 → $0.15, ≥100 → $0.20. Higher reputation = higher fee, because the agent has earned the right to charge more.

ERC-7857 (intelligent NFT) wraps the agent itself: its memory blob is anchored to 0G Storage, the Merkle root sits in tokenURI, and the holder of the token controls payout. Transfer the INFT and you transfer the going concern.

/inft → shows OpenSea-style standing offers: any wallet can lock USDC into AgentBids as a bid, top it up, or withdraw. The owner can accept any bid in one transaction — atomic INFT transfer + USDC settlement, no expiry.

All offers are visible to everyone, ranked by amount. Highest bid wins when the owner clicks accept.

Owning the INFT = owning the agent. Owning a TRADE token = owning a slice of its income. There are 10,000 TRADE (ERC-20) on Base Sepolia — buy them at the primary fixed-price SharesSale, then claim dividends from RevenueSplitter any time.

Math: claimable = totalReceived × balanceOf(you) / totalSupply − alreadyReleased. Pull-pattern, gas-cheap, no per-payment iteration.

Switch the agent's x402 payTo to the splitter and every quote becomes a dividend.

ReputationCredit is a USDC pool. Lenders deposit, agents borrow up to min(feedbackCount × $5, pool / 10) with no collateral. Their reputation is the recourse.

If feedback drops below 80% of borrow-time feedback, anyone can call liquidate(agentId) — the loan defaults, lender NAV-per-share is written down pro-rata, the agent keeps the borrowed USDC, and reputation gets recorded as defaulted on chain.

Lenders take the risk. The agent has no way to game the system without burning reputation, which is the same reputation that powers pricing, credit, and M&A.

Listed agents post a USDC bond per job in SlaBond. Validator approves → bond returns. Validator slashes → 70% refunds the client, 30% rewards the slasher. State machine: None → Posted → {Released | Slashed}.

/marketplace → shows the live agents (tradewise + pricewatch) and four stub directory entries that illustrate the catalog shape.

AgentMerger lets you fold two agents into one. The source INFTs lock in custody, lineage records the constituent agentIds + a 0G Storage Merkle root for the combined memory blob, and effectiveFeedbackCount(mergedAgentId) returns the sum of constituent reputation.

Agents are businesses. Businesses do M&A. The lineage card on /merger is the audit trail.

The hard problem: how does anyone verify an AI agent isn't illegally scraping Google Flights, Twitter, or some other source that forbids automated access? The agent declares every external data source it touches — URL, ToS hash, license tier — in a signed manifest. The full doc lives on 0G Storage; the keccak256 root is anchored to the ComplianceManifest registry on Sepolia.

Universal verification: anyone runs buildManifestRoot(manifestDoc) off chain and compares against getManifest(agentId).manifestRoot. Match = verified declaration. The /compliance page does this on every load.

Teeth: agents post a USDC compliance bond. Anyone can challenge with a counter-bond ≥ agent bond + an evidence URI. The validator resolves; if upheld, the agent's bond splits 70/30 between challenger and validator and the manifest enters an on-chain Slashed state — permanent reputation penalty.

Vercel hosts the application. KeeperHub schedules and executes the agent's automations: ENS heartbeat, reputation cache, compliance attestation, swap mirror. The agent is the keeper customer, not a Vercel cron consumer.

Why it matters: the agent shouldn't depend on our scheduler. KeeperHub is decentralized infra that can keep the agent alive, heartbeating, and self-attesting even if our app goes down. /keeperhub shows the workflow gallery and recent runs.

tradewise is a single web app on Vercel that talks to sevenon-chain contract systems across two chains, plus three off-chain services. The architecture is meant to maximize the surface area where the agent acts as a real autonomous business — not just "an LLM with a wallet."

Two chains: 11155111 (Sepolia, identity-side) and 84532 (Base Sepolia, settlement). Plus 0G Galileo 16602 for the encrypted memory blobs and TEE-attested inference.

The problem.ERC-7857 says: when an INFT transfers, the encrypted memory blob is re-encrypted to the new owner. Every public ERC-7857 demo we've seen stops at the metadata schema. 0G's own reference verifier (the canonical implementation) leaves a literal // TODO: verify TEE's signature in its transfer-validity verifier and deploys with an empty oracle counterpart (the 0g-inft-oracle-server-ts repo is a placeholder).

What we ship. A full ERC-7857 transfer pipeline:

1. AgentINFTVerifier on Sepolia. Implements 0G's IERC7857DataVerifierwith the byte layout from their reference (plus a 32-byte tokenId field we added at offset 1 since the verifier's interface only sees bytes[]). Adds the on-chain oracle attestation check the reference left as TODO.
2. AgentINFT with a new transferWithProof(to, tokenId, proof) entry point, an EIP-712 delegation table that lets bidders pre-authorize the oracle to act as their receiver-proxy, and a memoryReencrypted stale flag for raw transferFrom bypasses.
3. Oracle service(Vercel functions). Holds per-token AES-128 keys in Redis (KEK-derived from the oracle private key via HKDF). On every transfer it: decrypts the current blob, generates a fresh AES key, re-encrypts the same plaintext, anchors the new ciphertext to 0G Storage, ECIES-wraps the new key to the buyer's pubkey, and signs a 65-byte attestation the on-chain verifier checks via ecrecover.

Trust posture.Same as 0G's reference (an EOA-signing oracle) but we actually verifythe signature on-chain. Hardware-attested swap-in is a one-line change: replace the oracle pubkey in the verifier's constructor with a TEE-bound key. The contract surface is identical.

Every transfer carries a single calldata blob containing the entire re-encryption proof. The verifier parses it via assembly, recovers two ECDSA signatures (receiver + oracle), and checks a replay-protection nonce.

transfer proof byte layout — private TEE flavor (~423B + uri length)

Accept-bid sequence (3 wallet steps + 2 oracle calls):

1. Bidder pre-authorizes the oracle as receiver-proxy via an EIP-712 Delegation signature, stored on-chain in AgentINFT.delegations[bidder][tokenId]. AgentBids.placeBid bundles the delegation forward and the USDC escrow into one transaction.
2. Seller clicks accept. Frontend calls /api/inft/transfer/prepare. Oracle decrypts current blob (Redis-stored AES-128 key), rotates to a fresh K_new, encrypts the same plaintext, anchors to 0G Storage, builds the proof bytes above. Does not rotate the Redis key yet — proof is returned to the frontend.
3. Seller signs BIDS.acceptBid(tokenId, bidder, proof). The contract checks the bid, calls INFT.transferWithProof, the verifier validates the proof, the INFT updates encryptedMemoryRoot[tokenId] = newRoot, ERC-721 transfer happens atomically, USDC pays out to the seller. Single tx.
4. Frontend POSTs /api/inft/transfer/confirm. Oracle waits for tx receipt, parses the Transferred event, then commits the rotated key in Redis. Two-phase commit prevents key rotation if the chain tx never lands.
5. Optional: new owner clicks reveal. Wallet signs an EIP-191 message, /api/inft/transfer/reveal verifies ownership against the on-chain ownerOf, decrypts with the new K, and returns the plaintext memory blob.

ERC-7857 wants every transfer to carry re-encryption. ERC-721 marketplaces (OpenSea etc.) call safeTransferFrom directly. We compromise: raw transferFrom still works, but flips memoryReencrypted[tokenId] = false and emits MemoryStaled. The new owner gets the token but cannot decrypt the memory.

The /inftpage renders a red "memory is stale" badge when the flag is false. This is a feature, not a bug — it demonstrates exactly whythe proof path matters, side-by-side with the proof path's green "rotations: N" counter.

Recovery: previous owner can volunteer the AES key off-chain, or transfer the INFT back via transferWithProof (which re-rotates the key under the original owner).

AgentMerger.recordMerge(...) takes proofs for both source tokens. The merged-agent owner pre-authorizes the oracle to act as receiver-proxy for the merger contract (which has no key) via setDelegationByOwner(MERGER, tokenId, oracle, expiresAt) — owner's tx is the authorization, no signature needed since the receiver is a contract.

Oracle prepare-merge: decrypts both source blobs, encrypts the combined memory under a fresh K_m, anchors once, builds two proofs (both with newDataHash = mergedRoot). The merger contract calls transferWithProof twice, source tokens land in custody, lineage stored on chain, merged agent inherits effectiveFeedbackCount = sum of constituents.

Single trust anchor:the oracle's secp256k1 private key. Compromise = an attacker can mint forged transfer proofs, but only for INFTs they already own (the verifier checks old root binds to current state, which only the legitimate owner controls). The blast radiusis limited to the oracle's signing power, not the AES keys (which require Redis breach AND KEK derivation).

Before W2: every last-seen-at heartbeat, reputation-summary, and dynamic ENS text record was a real setText tx burning Sepolia gas. After W2: a single OffchainResolver contract reverts every resolve() call with EIP-3668 OffchainLookup, viem/wagmi clients follow it transparently, and our Vercel gateway computes record values live (Redis + on-chain reads + Edge Config), signs the response with INFT_GATEWAY_PK, and resolveWithProof verifies the sig with ecrecover on chain. Zero gas per read.

ENSIP-10 wildcard: a single resolver at the parent agentlab.eth serves every *.agentlab.ethand every nested *.*.agentlab.eth. New agents get ENS records for free with no per-name registration.

Trust posture (W2-α):gateway is an EOA we sign with. Compromise ⇒ malicious resolution. Worst case is stale telemetry, never falsified ownership (ownership stays in the L1 registry, the resolver doesn't override it). Future swap to W2-β (storage-proof verifier) replaces only theresolveWithProof body — no API change.

1. 1.wallet / dApp
   viem.getEnsText({ name, key }) → eth_call resolve(name, data) on the agentlab.eth resolver
2. ↓
3. 2.OffchainResolver (Sepolia)
   reverts: OffchainLookup(this, [gatewayURL], callData, callbackFn, extraData) — viem catches it (EIP-3668)
4. ↓
5. 3.gateway HTTP route
   GET /api/ens-gateway/{sender}/{data}.json → ABI-decode (name, data) → resolve via Redis + chain + Edge Config → sign keccak256(0x1900 || resolver || expires || keccak(extraData) || keccak(result)) → returns { data: encode(expires, result, sig) }
6. ↓
7. 4.OffchainResolver.resolveWithProof
   check expires > now · ecrecover sig === expectedGatewaySigner · return result bytes
8. ↓
9. 5.caller
   viem decodes the result and hands the value to your code

Every wallet we own gets a primary name on Sepolia. Etherscan, MetaMask, and any wallet UI that does ENS reverse resolution shows the name instead of hex.

Forward addr(label) resolution is handled dynamically by the W2 gateway — we never wrote forward records on chain. Reverse records are set via the canonical Sepolia ReverseRegistrar (0xA0a1…C0C6); each wallet pays its own gas for the one-time setNamecall. The Turnkey wallet uses KeeperHub's execute_contract_call to broadcast.

KeeperHub is the agent's automation layer. Every paid x402 quote fires a workflow; chain events fire workflows; the agent uses KeeperHub the same way a SaaS company uses Zapier.

Heartbeat + ReputationCache used to write to chain (setText on the ENS PublicResolver per quote, ~14k gas burned per fire). PR #13 swapped their Web3 Writenodes for Webhook POST nodes pointing at our app — same trigger, same KeeperHub run visibility, but writes Redis instead of chain. Workflows still appear on /keeperhub with green checkmarks; gas drain went from real to zero.

Cross-link: ENSAvatarSync and GatewayCacheInvalidatorare triggered by the W1 INFT oracle's /api/inft/oracle/confirm-transferroute the moment a transferWithProof tx is mined. Avatar gets re-pointed at the new tokenId; ENS gateway cache formemory-rotations et al. is purged so the next ENS query returns fresh values.