ADEXTO MCP Server
Allows agents to launch and interact with agent-bound token markets on Robinhood Chain, including opening markets, earning creator fees, and buying tokens via the ADEXTO protocol.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@ADEXTO MCP Serverdiscover agent-bound markets and quote 100 USDC for one"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
The loop
What happens | Read it on chain | |
Open | An agent calls |
|
Earn | The launching address is the curve's immutable |
|
Get bought | Another agent finds the market over MCP, receives an HTTP 402 quote, and pays USDC on Base by signing an EIP-3009 authorization with its own wallet. The token is delivered on the market's chain before the payment settles. |
|
Verify | Fees, treasury and supply are readable before anyone trades, and there is no owner, proxy, pause or withdraw function. |
|
Launchpads are built for people clicking buttons. An agent needs a market it can open without asking anyone, terms it can check without trusting anyone, and buyers who can pay it without a bridge. It opens one with a direct contract call, or over MCP: prepare_launch returns the unsigned transaction, the agent signs and sends it with its own key, and register_launch lists the market.
Related MCP server: Tollbooth MCP Server
Live on six mainnets
One factory, byte-identical on every chain (21,806 bytes, an exact match on Sourcify on all six), and every new launch goes through it.
The 12 listed markets, read from chain on 2026-10-04 (SAi Arc on 2026-10-06). The same ticker on two chains names two separate markets, with separate supply and price.
Market | Chain | Generation · trader pays | ERC-8004 agent | Contracts |
$PARCEL Parcel Market | Monad |
|
| |
$SAI SAi Monad | Monad | v1 · 1.00% |
| |
$LOOP Loop | Monad | v1 · 1.00% |
| |
$WOMBO Wombo | Arbitrum One |
| none | |
$SAI SAi Arbitrum | Arbitrum One | v1 · 1.00% |
| |
$LOOP Loop | Arbitrum One | v1 · 1.00% |
| |
$SAI SAi Robin | Robinhood Chain | v1 · 1.00% |
| |
$SAI SAi Arc | Arc | v1 · 1.00% |
| |
$BLOOP Bloop | Base |
| none | |
$ADEXTO ADEXTO | 0G |
| none (why) | |
$ADT ADEXTO Protocol | 0G |
| none | |
$ZEEBO Zeebo | 0G |
| none |
"Trader pays" is the curve's own totalFeeBps(): 40 on every 0.11.0 curve and 100 on every v1 curve. Factory, stake and hub addresses for every chain are in Mainnet deployments.
Repository | What lives there |
| contracts, tests, the web app, the MCP server's source, the x402 gateway and the indexers |
MCP connection guides, the tool reference, and an agent kit that signs with your own key | |
the Arbitrum One engineering | |
the Monad engineering | |
the Arc engineering: what is different on Arc, the go-live log, a read-only probe, and the demo video |
Architecture
Three ways in, one set of contracts. People use the web app with their own wallet, AI agents use the MCP server with their own key, and any HTTP client can buy over x402 with USDC on Base. Every launch, stake and claim is signed by the user's own key: the web app and the MCP server prepare those transactions and never hold that key. The x402 gateway buys on the market's chain with its own relayer key and the payer as recipient, and only after that delivery does it submit the payer's USDC authorization on Base.
What we run, and what we don't. The web app and the MCP server (Next.js, this repo), the x402 gateway (a Cloudflare Worker in cloudflare-worker/) and the market index are ours, off-chain. On chain nothing has an owner: no factory, curve, token or stake contract has an admin key. The ERC-8004 Identity Registry, USDC, 0G DA, the 0G Compute router and the indexers belong to third parties.
Start here
Explorer lists every market on every chain, and /creator shows what any address has earned. To run it yourself, see Local development.
Connect an agent
claude mcp add --transport http adexto https://adexto.xyz/api/mcp{ "mcpServers": { "adexto": { "url": "https://adexto.xyz/api/mcp" } } }Fourteen tools: discover and quote markets, buy with USDC on Base, read trade history and stakes, ask a market's agent, and launch, stake and claim with your own key. Guides for other clients and the agent kit are in 0xcuy/adexto-mcp.
Buy over x402
curl -i 'https://x402.adexto.xyz/v1/x402/buy/loop?chain=143'Sign the EIP-3009 authorization it describes and send the request again. The curve on the market's own chain delivers to your address, and only then is the payment settled. Reference: adexto.xyz/x402 and the OpenAPI document.
What arrives with a market
A launchpad hands a creator a token and a page. Here one transaction opens a working venue, whether an agent or a person sends it, and all of this arrives with it. None of it is a roadmap item, and none of it needs a listing or an application.
What is not here: no autonomous trading bot runs a market on a creator's behalf. ERC-8004 identity binding is real and checked on-chain at launch, but it is opt-in, and it records an identity rather than starting a strategy.
How the market works
The token opens inside a bonding curve against a virtual reserve. There is nothing to seed, so a launch costs gas and nothing else. 100% of supply enters the curve, so the creator holds no allocation to sell. Income arrives instead as a share of every swap, taken from inside the fee the trader already pays: on the studio's standard preset a trade costs 1.00%, and 0.70% of it goes to the creator.
The curve is the permanent venue. There is no graduation step and no migration into an external pool, which is where most launchpad exploits have happened. There is no withdrawal function anywhere in the curve, so nobody, including us, can drain a market.
That is a statement about the protocol, not a restriction on the token. A v1 AdextoToken limits every receiving wallet to 1% of supply only while block.timestamp < launchTime + 180 (the six 0.11.0 tokens capped single transfers for their first 5 blocks). After that, _update adds no condition at all, and there is no blacklist, no pause, no Ownable and no permanent transfer hook. It is a plain ERC-20, so anyone can list it on any external AMM without our permission, and we could not stop it. The guarantee is narrower than "one market": we never migrate, and nobody can withdraw the curve's reserves.
The reason is the launch model, and it is checkable in the contracts rather than a matter of taste.
this curve | a standard liquidity pool | |
Capital to open a market | none: the native side starts entirely virtual, and | real liquidity must be deposited by someone |
Creator's token position | none: the whole supply is minted to the factory and loaded into the curve in the same transaction, and the factory then requires its own balance to be zero before the launch can succeed | the creator must hold tokens to pair with liquidity |
Can reserves be pulled out | no: there is no | yes, and correctly so: a provider may withdraw at any time |
Migration step | none: the curve is the permanent venue | the usual launchpad pattern graduates a curve into a pool, and that step is where much of the historical exploit surface lives |
Creator fee | a share of every swap accrues on-chain inside the total the trader pays (0.70% of 1.00% on the studio's standard preset), so paying the creator costs the trader nothing extra | fees accrue to liquidity providers; paying a creator needs custom hook support the venue may not offer |
Code paths across our six chains | one, byte-identical | whatever venue happens to exist per chain |
Row three carries the weight. A liquidity provider being able to withdraw is not a flaw, it is what an AMM is for, but it means the venue can be pulled out from under the people holding the token, and "we won't" is only a promise. Here the guarantee is the absence of code that could do it.
Fee split
Every swap pays four legs: creator, depth, buyback and protocol. Each rate is fixed when the market is created, and where the protocol leg sits depends on the factory generation that created it.
ADEXTO v1 (AdextoFactory 1.0.0), which every launch from the studio uses. The creator configures a total, and that total is exactly what a trader pays: the protocol's 0.10% is carved out of it rather than added on top. The studio's standard preset, which a curve reports as totalFeeBps 100:
Share | Rate | Goes to |
Creator | 0.70% | accrues as |
Depth | 0.10% | stays in the curve, raising the price floor as volume accumulates |
Buyback | 0.10% | accrues on the curve as |
Protocol | 0.10% |
|
Trader pays | 1.00% |
ReadtotalFeeBps() on the curve instead of adding these up. It is the contract's own answer to what a trade costs, whichever generation created the market. No rate has a setter, on the factory or on any curve.
AdextoFactory 0.11.0, which created the six markets launched before v1. Its protocol leg is charged on top of the configured total. Those markets were configured at 0.30%, so a trader pays 0.40% on them, permanently:
Share | Rate | Comes from | Goes to |
Depth | 0.15% | inside the creator's 0.30% | stays in the curve |
Creator | 0.10% | inside the creator's 0.30% | accrues as |
Buyback | 0.05% | inside the creator's 0.30% |
|
Protocol | 0.10% | added on top |
|
Trader pays | 0.40% |
The protocol leg is a public constant PROTOCOL_FEE_BPS on the factory and an immutable protocolFeeBps on each curve, with no setter in either. A setter would make the contracts owned, which is the opposite of what /security claims about them. So a 0.11.0 market can never move its leg inside the total: its rates are immutable too. That is permanent, not a migration waiting to happen.
claimProtocolFees() is permissionless. Anyone may call it, and the native always lands at the immutable treasury, so no key is needed to collect the fee. The treasury's key is only needed by its owner, later, to move the money elsewhere.
The studio's three presets (0.60% / 1.00% / 2.00%) are UI only. The v1 contract accepts any split subject to swapFeeBps <= 500 and creatorShareBps + treasuryShareBps + PROTOCOL_FEE_BPS <= swapFeeBps, so the 5% cap applies to what a trader pays and there is always room for the protocol leg. Depth is the residual, not an input: the factory computes swapFeeBps − creatorShareBps − treasuryShareBps − PROTOCOL_FEE_BPS, and the curve re-checks the sum against its own ceiling. On 0.11.0 the cap read swapFeeBps + PROTOCOL_FEE_BPS <= 500 and depth was swapFeeBps − creatorShareBps − treasuryShareBps.
The buyback is permissionless and self-contained. executeBuyback carries only nonReentrant and live, with no caller gate, so anyone can trigger it, capped at 1% of the native reserve per call. v1 curves also wait one hour between calls. The native never leaves the contract: the call moves treasuryNative into the curve reserve and burns whatever that purchase bought, so supply falls without paying anyone. That is deliberate: a burn path that depended on us being willing to run it would be a promise rather than a mechanism. It is not automatic either. The buyback share accrues on every swap, but a burn happens only when someone calls it. Our x402 gateway does so after a delivery once the bucket covers three times the gas, and so far (read 2026-10-04) only $ADEXTO has burned anything.
Inside one launch
graph TD
Creator([Creator]) -->|1 tx per chain, gas only<br/>deployTrinity is NOT payable| Factory[AdextoFactory 1.0.0]
Registry[[ERC-8004 Identity Registry<br/>optional, off by default]] -.->|ownerOf agentId: the launch reverts<br/>unless the caller owns that agent| Factory
Meta[0G DA<br/>launch metadata anchored] -.->|metadataRoot in calldata| Factory
subgraph "Deployed atomically in that transaction"
Factory -->|1. deploys the curve first,<br/>so the token can bind it immutably| Curve[AdextoCurve: its own AMM<br/>virtual reserve, no deposit<br/>no owner, no withdraw, sweep or rescue]
Factory -->|2. deploys the token,<br/>mints 100% of supply to itself| Token[AdextoToken: plain ERC-20<br/>no owner, no pause, no blacklist<br/>1% per wallet for the first 180 s]
Factory ==>|3. seeds 100% into the curve, then<br/>asserts its own balance is zero| Curve
end
Curve -->|0.10% depth| Depth[stays in the curve,<br/>raising the floor]
Curve -->|0.70% creator| CreatorFee[claimCreatorFees →<br/>immutable creator address]
Curve -->|0.10% buyback| Vault[treasuryNative:<br/>a balance on the curve,<br/>not a separate contract]
Curve -->|0.10% protocol, carved OUT OF<br/>the 1.00% standard preset| Protocol[protocolOwed →<br/>claimProtocolFees is permissionless,<br/>destination is immutable]
Vault -->|executeBuyback: no caller gate,<br/>max 1% of reserve per call, 1h apart| Burn[buys along the curve,<br/>burns what it bought]Three details that are easy to misread, none of them part of deployTrinity:
agentIdentityis just an address. It is required non-zero and stored immutably on both the token and the curve, and it may callexecuteTreasuryBuybackto burn tokens it holds itself. It is not automatically the 0G Compute agent: the studio passes the creator's own wallet by default.The x402 edge is a customer of the curve, not an operator of it. It calls
buywith the payer as recipient, exactly like any other address, and it holds no privileged position: it cannot deposit intotreasuryNative, which fills only from the buyback leg of swap fees. The 0G Compute agent is an inference route and holds no key to anything on-chain. See agent-to-agent.The buyback burns, but nobody is in charge of it.
executeBuybackcarries onlynonReentrantandlive, with no caller gate, so anyone may trigger it, bounded to 1% of the reserve per call and, on v1 curves, one call per hour.
Mainnet deployments
Every address below was confirmed to hold bytecode with a direct eth_getCode call against the chain's RPC, and audit_consistency.mjs re-reads the bytecode, VERSION and size of every factory, stake and hub row on each deploy. Testnet deployments are deliberately not listed here. They belong in the operator runbook, not in the public README.
ADEXTO v1 (AdextoFactory VERSION 1.0.0) is the current generation, broadcast on 2026-10-01 to five mainnets and on 2026-10-06 to Arc. It deploys the token and its curve in one transaction, needs no liquidity deposit, can bind an ERC-8004 agent identity, takes its 0.10% protocol fee out of the total the creator configures, and gives every market a 180-second launch window in which no wallet may hold more than 1% of supply.
Its runtime bytecode is byte-identical across all six chains: 21,806 bytes, keccak 0x1ca02ca53a3b2a2082f9e5dab6924e1339110e3037608f750981699678881fd4. Sourcify reports an exact match, creation and runtime, on all six chains. /security has the commands to check each of these yourself.
AdextoStakeHub (VERSION 1.0.0) is the stake contract for every market that does not have its own AdextoAgentStake: one per chain, broadcast on 2026-10-01 (Arc on 2026-10-06). It accepts a token only when one of the factories fixed in its constructor returns a curve for it from curveOf, which only a launch writes, so a new market is stakeable from its first block with nothing deployed for it. It refuses the four tokens that have their own stake, so no market has two stake contracts. The minimum is 0.001% of the token's current supply, and there is no owner, pause, lock or reward. Its runtime is byte-identical across all six chains (4,278 bytes, keccak 0x88247303e4851282bbf22dd4f23e753b08a6862ea40f32d9c0464e92730b081a) because it has no immutables, and Sourcify reports an exact match on all six.
0.11.0 is listed alongside v1 because it created the six earlier markets, and they keep its rates permanently. Each row states its VERSION as read from the contract. A 0.12.0 generation was live on four mainnets from 2026-09-29 until v1 replaced it on 2026-10-01. It created one unlisted test market ($VOLT on Monad) and is on no launch path; its addresses are in release v1.0.2.
The v1 runtime is reproducible from source at commit 71b5adfe774ed7a93f9fe589b4430c8122febb1f with node scripts/compile-contracts.mjs --via-ir (solc 0.8.37, EVM cancun, 200 runs, via-IR). The compiled output differs from the chain only in the two slots that hold the immutable protocolTreasury. With those two slots zeroed, the code on every chain and the compiled artefact hash to the same 0x0e70cb93fbb10b66109cc71d547329cb48b4c3953791c2c4609519ff92221d62.
A shallow clone (git clone --depth 1) does not contain that commit. Fetch it by its full hash first, git fetch --depth 1 origin 71b5adfe774ed7a93f9fe589b4430c8122febb1f && git checkout FETCH_HEAD, or clone without --depth. The stake hub was broadcast from commit f8328ab43375c8a785ccf86fb4dfe39c83c2986f.
Byte-identical is not automatic here. protocolTreasury is immutable, and Solidity puts immutables inside the runtime bytecode, so the hashes match only because the same treasury was used on every chain. One chain with a different treasury and the claim is false. The reserved tickers differ by chain (Robinhood Chain reserves more, see A note on reserved tickers), but they live in storage, not in the code.
Monad Mainnet · chain ID 143
Contract | Address | Notes |
AdextoFactory | current · ADEXTO v1 · | |
AdextoFactory | superseded · | |
ERC-8004 agent (ours) | both registered and both owned by the deployer · | |
SAi Monad ( | token | the first v1 market on Monad, launched from the studio ( |
Loop ( | token | launched over MCP on 2026-10-03: the creator wallet signed the attestation and the launch transaction itself ( |
AdextoAgentStake | live · the | |
AdextoStakeHub | live · every Monad market except |
Arbitrum One · chain ID 42161
Contract | Address | Notes |
AdextoFactory | current · ADEXTO v1 · | |
AdextoFactory | superseded · | |
ERC-8004 agent (ours) | registered, owned by the deployer · id is chain-specific | |
SAi Arbitrum ( | token | the first v1 market on Arbitrum One, launched from the studio ( |
Loop ( | token | launched over MCP on 2026-10-03: the creator wallet signed the attestation and the launch transaction itself ( |
AdextoAgentStake | live · the | |
AdextoStakeHub | live · every Arbitrum One market except |
Robinhood Chain · chain ID 4663
An Arbitrum Orbit chain. ADEXTO v1 is the first generation here, so there is no superseded factory.
Contract | Address | Notes |
AdextoFactory | current · ADEXTO v1 · | |
SAi Robin ( | token | the first v1 market anywhere, launched from the studio ( |
AdextoAgentStake | live · the | |
AdextoStakeHub | live · every Robinhood Chain market except |
An address means nothing without its chain id. The factory here sits at the deployer's first-nonce address, and on Base and Monad that same address holds an unrelated pre-release contract.
Arc · chain ID 5042
Circle's L1, where the native gas asset is USDC (18 decimals at the native level). ADEXTO v1 is the first generation here, broadcast on 2026-10-06 from commit 3b23f56, whose factory sources are identical to 71b5adf. Sourcify reports an exact match, creation and runtime, for both contracts below.
Contract | Address | Notes |
AdextoFactory | current · ADEXTO v1 · | |
SAi Arc ( | token | launched over MCP on 2026-10-06: the creator wallet signed the attestation and the launch transaction itself ( |
ERC-8004 agent (ours) | registered, owned by the deployer · id is chain-specific | |
AdextoStakeHub | live · every Arc market, from the v1 factory · |
Same addresses, different chains. The factory sits at the deployer's first-nonce address, as on Robinhood Chain, and the stake hub's address holds the unrelated pre-release hook on Base and Monad. Arc also enforces Circle's USDC blocklist on native transfers: a blocklisted address cannot pay into an Arc curve or be paid by one. The ADEXTO contracts have no blacklist of their own.
Base Mainnet · chain ID 8453
Contract | Address | Notes |
AdextoFactory | current · ADEXTO v1 · | |
AdextoFactory | superseded · | |
ERC-8004 agent (ours) | registered, owned by the deployer · id is chain-specific | |
AdextoStakeHub | live · every Base market, from the v1 and |
0G Mainnet · chain ID 16661
Contract | Address | Notes |
AdextoFactory | current · ADEXTO v1 · | |
AdextoFactory | superseded · | |
ERC-8004 agent (ours) | registered, owned by the deployer · id is chain-specific | |
AdextoAgentStake | live · stakes $ADEXTO for Agent Compute and the market's agent ( | |
AdextoStakeHub | live · every 0G market except $ADEXTO, from the v1 and |
Deployer: 0x8a3c7524Aaed081825aC88eC7f4cCECFc583ee7D
Protocol treasury: 0x24268Fffc119ec5550F68e80D94476fD64daE967, the immutable destination of the 0.10% protocol leg on every 0.11.0 and v1 curve. It is deliberately not the deployer: that key is online and is already the creator of live markets, which would make protocol revenue and creator revenue indistinguishable on-chain. It was a fresh address with no code, nonce 0 and no balance when it was chosen, and on 2026-10-06 it still had no code and nonce 0 on all six chains.
Honest status
What works, and exactly what that means. Every figure below was read from chain or from the live service, with the date it was read. 🟢 live · 🟡 live, with a gap the row names.
Component | State | In one line |
ADEXTO v1 ( | 🟢 Live on 6 mainnets, current | Byte-identical on all six, an exact match on Sourcify, and every new launch goes through it. |
| 🟢 Live on 4 mainnets, superseded | Still permissionless; its six listed markets keep their 0.40% permanently. |
| 🟢 Live on 6 mainnets | Any market is stakeable from its first block, with nothing deployed for it. |
Protocol fee revenue | 🟢 Accruing on all six | The 0.10% leg is charged on every |
ERC-8004 agent binding | 🟢 Works, opt-in | The factory reverts unless the caller owns the agent; 7 of the 12 listed markets are bound. |
Launching through the site | 🟢 Enabled on six chains | The studio launches on v1 everywhere, Express and Advanced. |
Creator earnings ( | 🟢 Live | Reads matched chain field by field; both claim paths were exercised on a local chain. |
Live markets | 🟢 12 on six mainnets | Every launch that exists on chain is accounted for in |
Trading | 🟢 Live on all six, nearly all of it ours | 70 fills and one treasury buyback across the 12 listed curves, every fill sent from one of our wallets. That proves the paths, not outside demand. |
MCP server | 🟢 Live, 14 tools | Launch, stake and claim with the agent's own key, plus one capped, operator-signed purchase tool. |
x402 edge gateway | 🟢 Settles on Base; delivers on all six | Paid deliveries on all six chains. Delivery runs before the charge, so a failed fill never costs the buyer. |
Agent Compute | 🟢 Live on all six | A stake gets an API key for an OpenAI-compatible endpoint on the 0G Compute router. |
Market staking ( | 🟢 Live on every market | A stake in the market's contract opens its agent over MCP. |
Agent inference (0G) | 🟢 Works | The router reports Intel TDX; that is its word, attributed to it, not our verification. |
0G DA metadata anchoring | 🟢 Live | All 12 listed markets have a storage transaction on 0G mainnet. |
The Graph | 🟢 Base and Arbitrum One, v1 included |
|
Envio (Monad, Robinhood Chain, Arc) | 🟢 Live for Monad | Every live market there matches its curve. |
Trade history, holders, positions | 🟢 Complete from each launch block | The MCP |
No admin surface | 🟢 Guaranteed by the contracts | Every fee rate is immutable, nothing on the launch path has an owner or a setter, and no curve can be drained. |
Component | Works? | Exactly what that means |
ADEXTO v1 ( | Live, current | Broadcast on 2026-10-01 (Arc on 2026-10-06) by |
| Live, superseded | Superseded by v1, which moves the protocol leg inside the total and adds the per-wallet launch window. Still deployed and still permissionless, and its six listed markets keep their 0.40% permanently. Broadcast and read back on each chain: |
| Live | Broadcast on 2026-10-01 (Arc on 2026-10-06) by |
Protocol fee revenue | Live and accruing on all six chains | The leg is charged and accrues on every |
ERC-8004 agent binding | Works. Optional, enforced at launch | Pass an agent id at launch and the factory calls |
Launching through the site | Enabled on six chains | All six |
Studio: cost card, Express mode, announcement drafts | Live; exercised locally and by three mainnet launches | Before you sign, a cost card shows the launch's gas on the chosen chain from that chain's live |
Creator earnings ( | Live; reads checked against chain, claims exercised on a local chain | For any address it lists every market whose curve names that address as |
Verify-it-yourself checklist ( | Live | Copy-paste |
Live markets | 12, across all six mainnets | Listed in Live on six mainnets. |
Trading / swap | Live on all six mainnets, and nearly all of it is ours | Real fills exist on every chain. Read on 2026-10-06 from each curve's |
MCP server for AI agents | Live, 14 tools |
|
Own AMM ( | Deployed per launch | The curve ships with the factory, one per market. |
Agent inference (0G) | Works | The market agent's chat runs through the 0G Compute Router ( |
Agent Compute (stake for an API key) | Live on all six mainnets; tiered on four stakes, fee-funded on every other market | Stake at least 5,000 $ADEXTO in |
Market staking ( | Live on every market | Four markets have their own |
x402 edge gateway | Settles on Base; paid deliveries on all six mainnets | Quote, payment and delivery run through the same endpoint. Paid deliveries have been exercised on all six: 0G, Base, Arbitrum One, Monad, Robinhood Chain and Arc. The first on Arc delivered |
0G DA metadata anchoring | Live | Launch metadata is anchored and its storage root travels in calldata as |
The Graph indexing | Live on Base and Arbitrum One for all three factory generations, v1 included |
|
Trade history, holders and positions | Complete from each market's launch block |
|
Envio indexing (Monad, Robinhood Chain, Arc) | Live, full history for Monad | Since 2026-10-05 |
No admin surface | Guaranteed by the contracts | Every fee rate is |
Deep dives
ERC-8004 agent identity
It works, and it is off unless you ask for it. Pass an agent id at launch and AdextoFactory calls ownerOf(agentId) on the ERC-8004 Identity Registry, refusing the launch unless you own that agent, so a token cannot attach itself to somebody else's identity and inherit its reputation. Leave the id out and the launch is one transaction with no agent attached.
Scope, stated precisely: this integrates the Identity Registry. The standard has three registries, and ownership is the one that matters at launch. Reputation and Validation are outside what a launch needs, so they are not touched, and supportsInterface is not implemented. Calling this "ERC-8004 compliance" would overstate one registry into three.
Identity Registry |
|
Our own agents | registered on five mainnets: Monad |
Exercised at launch | on Monad, Arbitrum One, Robinhood Chain, Arc and 0G. Seven of the 12 listed markets read |
Regression, stated because it is permanent | the live |
Registry on testnets | absent, so the agent path can only be exercised on mainnet or a local devchain |
Status of the standard | EIP-8004 is a Draft, so what we integrate against can still change. This is about the EIP, not about our code |
Who controls the registry | not us. It is an upgradeable proxy owned by a third party, so its behaviour can change without our involvement or consent |
Reputation / Validation registries | not used |
Read on a token |
|
The agents ADEXTO operates point at permanent cards. Each one had its agentURI set with setAgentURI to https://adexto.xyz/agents/<chainId>/<agentId>/registration.json, a file that lists the MCP and x402 endpoints and a registrations entry pointing back at the identity. scripts/check-agent-cards.mjs checks every card, and on 2026-10-04 all 10 passed.
Chain | Agent | Owner | Bound market | Card set in |
Monad |
| deployer | none | |
Monad |
| deployer |
| |
Monad |
| creator wallet | SAi Monad | |
Monad |
| creator wallet |
| |
Arbitrum One |
| deployer | none | |
Arbitrum One |
| creator wallet | SAi Arbitrum | |
Arbitrum One |
| creator wallet |
| |
Robinhood Chain |
| creator wallet | SAi Robin | |
Base |
| deployer | none | |
0G |
| deployer | the first |
The deployer is 0x8a3c…ee7D; the creator wallet is the demo wallet 0x4247…daa5, which registered its own agents before launching. Both Loop Agents registered themselves from that wallet before launching $LOOP over MCP, and their cards use the market's own logo. The trade-off of a hosted card is that whoever controls adexto.xyz can change what it says; the market a token is bound to stays immutable either way.
A relaunch drops the binding unless something carries it. The first $ADEXTO market, created by the 0.10.0 factory at 0x0860a80f…37C6, reads agentBound true, agentId 3545431, agentRegistry 0x8004A169…a432. It was relaunched onto 0.11.0 so the market would pay the protocol fee leg, and the live market at 0xA1358C17…1DF7 reads agentBound false, agentId 0, registry at the zero address.
Nothing failed. scripts/relaunch-market.mjs sent bindAgent: false and agentId: 0 as literals, in the same file that goes to deliberate trouble to preserve every fee rate so that "the only difference is the protocol leg". The transaction succeeded, every post-launch check passed, and no line ever read agentBound() on the token it had just created. Because agentBound is immutable, the live market can never be bound. Only another relaunch would restore it, and that would abandon the market's trading history.
The script now reads agentBound(), agentId() and agentRegistry() off the old token, checks ownerOf(agentId) still returns the deployer and stops rather than proceeding unbound, passes the id through to deployTrinity, and then reads the binding back off the newly created token before the registry is touched. A correct argument and a correct result are two different things, and this bug lived in the gap between them.
An agent id means nothing without its chain. The registry sits at one address on all six mainnets, which invites the assumption that an id is global. It is not: each registry keeps its own state, and on 2026-10-06 ownerOf(0) returned four different owners across the six chains. The deployer's own registrations came back 84622 on Base, 1457 on Arbitrum, 3545431 on 0G, 10247 on Monad and 1422 on Arc for the same agent, plus 10251, a second Monad registration, which is the one $PARCEL binds. Launching on several chains with one id binds on the chain it came from and reverts on the others with Factory: agent not owned by caller, after gas has been spent on each. Register once per chain and pass that chain's id.
Binding is a separate step from launching. ERC-8004 wants the registration file to contain its own agentId, and the id does not exist until register() returns, so a file pinned beforehand cannot contain it. The creator registers first and passes the id to the launch. Leaving the identity off keeps the launch at one transaction, which is why the gas-only property is unaffected.
The studio can do the registration itself: one register() transaction from the creator's own wallet on the chosen chain, after which the new id is read from the mint event and filled into the launch form. That file is built before the id exists and the studio deliberately skips a second setAgentURI transaction, so it does not carry its own agentId, and it has no registrations entry pointing back at the identity. scripts/register-agent-8004.mjs takes the longer route and writes a file that does.
agentBound() is the flag to read, not agentId(). Agent id 0 is a real agent with a real owner on all six mainnets, so zero cannot mean "no agent". An earlier revision of this used agentId == 0 as that sentinel; testing against the live registries caught it before it was frozen into immutable bytecode.
The registration file is data: until IPFS pinning is configured. ERC-8004 permits a base64 data: URI for fully on-chain metadata, and that is the default here because an ipfs:// CID that nobody pins is a dead link recorded permanently. Set PINATA_JWT to pin instead; the CID is recomputed locally and compared with what the service reports. This matters: an empirical study of ERC-8004 found most registrations are placeholders with no live endpoint (arXiv 2606.26028), and reading agent #40 on four of these chains showed an empty string on 0G, un-encoded raw JSON on Monad, and an HTTPS URL whose embedded id does not match the token on Base.
The script reads the id out of the mint Transfer event rather than assuming ids are sequential, then calls setAgentURI with a rebuilt file that contains that id.
node scripts/register-agent-8004.mjs --chain base # dry run, no gas
node scripts/register-agent-8004.mjs --chain base --broadcast # registers, then sets the URI
node scripts/test-erc8004-binding.mjs # 24 assertions, local devchainRegistering the deployer's agents on four chains cost roughly $0.10 in total across eight transactions, and pointing the first eight agents at their cards cost about $0.05 in gas.
Agent-to-agent: where the loop closes and where it breaks
This is the point of pairing an agent identity with a bonding curve, and every edge of the loop carries value end to end, verified with real funds rather than reasoned about. A buyer, human or agent, pays without a human, an account or a card. What it buys is a position in a market on another chain, and that money reaches the token itself.
Edge | State | Evidence |
Agent has an on-chain identity | works | ERC-8004 binding, verified by |
An LLM can drive the whole sequence | works, with the signer named | The MCP server at |
Buyer discovers the terms | works | HTTP 402 + |
Buyer proves it can pay | works | EIP-3009 signature recovered and matched to |
Buyer actually pays | works |
|
Buyer receives the token | works | the curve's |
Earnings buy the token | works | a plain native transfer to the curve, with empty calldata, executes a market buy |
Agent burns what it bought | works |
|
So the whole loop is reachable today and needs no new contract: a buyer pays on one chain, the curve delivers on another, and native spent on the curve can be bought and burned so supply falls permanently.
The last two were verified on 0G mainnet rather than reasoned about. Sending 0.003 0G to the curve with no calldata returned 148.317329 tokens, incremented swapCount, and moved the spot price, because receive() routes into _buy. Then executeTreasuryBuyback destroyed 74.158664 of them, and totalSupply fell by exactly that amount. A random address calling the same function is rejected with Unauthorized agent.
The burn is funded by trading, it runs without anyone deciding to, and supply has already fallen.
treasuryNativefills from the buyback leg of swap fees, so nothing can be deposited into it and nothing needs to be: an x402 delivery is itself abuy, so it pays that leg and the vault grows on every fill. After a purchase settles, the edge spends the vault throughexecuteBuybackto buy and burn, gated on the vault being worth at least 3x the gas to trigger it: one call costs about0.0005 0Gwhile a fill contributes0.000257 0G, so burning every time would destroy less than it spent. The gate reads chain state rather than waiting for a person. The first burn destroyed7.110759702852663544 $ADEXTOand took total supply to999,999,918.730575824909329011:0x792023ab…8ab66bc5.executeBuybackhas no caller gate, so the burn does not depend on us running it, which was verified by simulating the call from a random address.agentIdentityis set once, at launch, and is immutable. On the live $ADEXTO token it is0x8a3c…ee7D. That permission is what gates the burn, so choosing the address at launch decides who can trigger it for the life of the market.
x402 edge
It sells one thing: a position in one of these markets, bought with USDC the payer already holds. Pay 0.10 USDC on Base and the curve on the market's own chain sends the tokens to your own address, with no bridge and no need to hold that chain's gas asset. Delivery is wired on all six mainnets, and paid deliveries have been made on all six: Monad, Arbitrum One, Robinhood Chain, Base, 0G and Arc. When the market lives on Base too, payment and delivery land on the same chain and nothing crosses: the same code path, one hop fewer.
Step | State | What actually happens |
1. Quote the terms | works | An unpaid call gets HTTP 402, a |
2. Verify the payment | works | The caller signs an EIP-3009 |
3. Deliver, then collect | works | The curve's |
The third step was the one that used to be missing, and it was closed with real money rather than declared done. One request produced a Base settlement and a 0G delivery 16.2 seconds apart; a replayed authorization is refused with invalid_transaction_state. Full payload reference, status codes and both transaction hashes: adexto.xyz/x402.
Three things that are easy to gloss over, and shouldn't be:
Settlement rides on USDC's own signature check, not on a scheme of ours. EIP-3009
TransferWithAuthorizationis verified by the token contract itself, so there is no escrow to trust and nothing custom for an integrator to learn. A caller still sending the retiredX-402-Authorizationheader gets an explicit rejection naming the reason rather than a silent failure.The relayer key is funded and in use, and its blast radius is deliberately small.
X402_RELAYER_PRIVATE_KEYis read and used to submit both legs. It belongs to a dedicated operator, not the deployer: the deployer key was never placed in the Worker. BecausetransferWithAuthorizationis permissionless and its whole content is signed by the payer, includingtoandvalue, that key cannot move anyone's funds or redirect a payment. The worst outcome of a leak is drained gas and inventory.The two legs are not atomic, and delivery capacity is finite. Payment clears on Base while delivery happens on the target chain, with nothing on-chain binding them. The buyer carries no funds risk because no charge is taken until a delivery succeeds, but they do rely on us submitting that buy. Filling an order also means spending native inventory we hold, so the endpoint answers
503once it runs low, before any authorization is touched.
The boundary is declared in the payload rather than in prose: every 402 carries quote.inventory.remainingBuys and quote.inventory.inStock, so an integrator learns the limit from the first reply instead of after building a payment client.
None of the delivery targets is hard-coded. DELIVERY_RPC in the worker maps a market's chainId to its own endpoint, so the destination comes from whichever market the ticker resolves to. The transaction hashes of the paid deliveries are in the status table.
Making that work on the ETH chains needed one number fixed, and it is worth recording because the number looked harmless. The inventory gate was gasHeadroom = parseEther("0.05"): 0.05 of the native token, on any chain. On 0G and Monad that is a cent or less. On Base and Arbitrum it is 0.05 ETH, roughly $120 that had to sit idle before a $0.10 fill was allowed, and the symptom was a quote reporting remainingBuys: 7 and inStock: false in the same breath. It is now the chain's own gas price times 150,000 gas times 3, with a fallback of one percent of the order's native value if the gas price cannot be read: proportional to order size, so it can never be a flat $120 again.
An LLM can complete a purchase, and the honest version of that claim matters. The MCP server exposes fourteen tools, and pay_and_buy is the one that finishes a buy on the server's side: the agent chooses the market and the size, and the EIP-3009 authorization is signed by the operator's key on this server. The agent does not hold funds. Every term (recipient, asset, amount) is read back out of the gateway's own 402 challenge and compared against hard-coded limits before anything is signed, the delivery address is never exposed because tokens always go to the signer, and the whole endpoint is gated on an x-agent-key header and capped at 0.20 USDC. So the correct sentence is the agent decided what to buy and executed the purchase, not the agent paid from its own funds. This was exercised end to end against $ZEEBO on 0G: the buy landed at block 44560323 and settled on Base at 51419336. An agent that holds its own USDC uses buy_token instead and signs the authorization itself, which is how both $LOOP markets were bought on 2026-10-03 and SAi Robin on Robinhood Chain on 2026-10-05.
The Graph
Deployed for Base and Arbitrum, and read by the site: SUBGRAPH_URL_* points at both. The manifest and per-network config are generated from subgraph/chains.json plus build/deployments.json (npm run networks in subgraph/).
Subgraph | Version | Endpoint |
|
|
|
|
|
|
Both are published to The Graph Network on Arbitrum One since 2026-10-06, owned by the deployer 0x8a3c…ee7D and with no curation signal: ADEXTO Base and ADEXTO Arbitrum One. The network serves the same deployments as Studio v1.0.1 (QmT1W8wY…qGCj9m on Base, QmYpYjRU…ehvMo9 on Arbitrum One), under the label v1.0.0 they were published with. The site reads the Studio endpoints above.
v1.0.1 changes documentation only. Its mappings, ABIs, data sources and start blocks are byte-identical to v1.0.0, and the two manifests differ in one line: the schema file, whose comments and field descriptions were translated to English. Studio refuses to reuse a version label for a new deployment, hence the patch version.
v1.0.0 indexes all three factory generations, v1 included. The label follows ADEXTO v1. The same build was deployed to Studio as v0.12.0 first, so both labels served one deployment per chain (QmeRWYsg…NV3jQ6 on Base, QmRRZJM8…jsfTcxr on Arbitrum One). The v1 factories have their own data source, AdextoFactoryV1. v1 emits exactly the events 0.11.0 does (TrinityProjectDeployed, AgentBound, CurveInitialized and the eleven-field Swap share their signatures and topic0), checked against the contract sources by scripts/verify-subgraph.mts and against real v1 logs on Arbitrum One, so it reuses the 0.11.0 ABI and curve template and adds only the factory addresses. The generator that writes networks.json changed with it: it now matches each data source by contract name and version, and refuses to write while any live market comes from a factory no data source covers. The old rule, "current entry" and "newest superseded entry", would have put the v1 address into the 0.11.0 data source and dropped $BLOOP and $WOMBO the moment v1 became current.
Three of the six chains cannot use Subgraph Studio. That is The Graph's coverage, not our choice, read from its networks registry (v0.8.6). Arc can, and is indexed by Envio instead, in the same indexer as Monad and Robinhood Chain:
Chain | Target | Reason |
Arbitrum One, Base | Subgraph Studio | Subgraphs served, indexing rewards enabled: deployed and published, see above |
Monad | Envio instead | listed, but served by Firehose and Substreams only, not Subgraphs |
Robinhood Chain | Envio instead | listed, but served by Firehose and Substreams only, not Subgraphs |
Arc | Subgraphs served. Indexed with Envio by choice, in the indexer that already covers Monad and Robinhood Chain | |
0G | RPC logs and the market index | absent from |
v0.11.0 indexed nothing on either chain, and v0.11.1 exists to fix it. For a long time the empty result was correct: Base and Arbitrum had factories and no markets. $BLOOP and $WOMBO ended that, and the endpoints stayed empty anyway, synced far past both launch blocks with hasIndexingErrors: false.
The fault was in the published build rather than in the mappings. subgraph/networks.json is generated, and the committed copy had AdextoFactory (the 0.11.0 generation) recorded as 0x0000000000000000000000000000000000000000 on every network, with the startBlock of the old factory. So the manifest that was deployed wired up only the 0.10.0 data source, and 0.10.0 created no markets on Base or Arbitrum. A data source pointed at the zero address indexes nothing and reports itself healthy while doing it, which is exactly why an indexer is worth checking against chain state rather than against its own status field.
npm run networks regenerates the file with the real addresses and start blocks, and v0.11.1 is that build, republished to Studio. Both chains confirm it, read on 2026-09-30: Base returns one project, BLOOP, one curve at curveVersion 0.11.0 with swapCount 2 and volumeNative 80300218841094, and Arbitrum returns WOMBO with swapCount 5 and volumeNative 200113996278028, in each case the same numbers the curve contract stores.
Neither endpoint is load-bearing: SUBGRAPH_URL_0G is empty and 0G trades come from RPC logs and the market index, and Monad is served by Envio. The two testnet slugs, adexto-base-sepolia and adexto-arbitrum-sepolia, are named in chains.json but have never been created in Studio, so a deploy to them answers Subgraph not found. They index the 0.10.0 factories and no markets exist on either, so nothing is lost by that.
Sell volume, fixed in v1.0.0. Up to v0.11.1, subgraph/src/shared.ts counted sell volume as the event's amountOut, the native a seller receives after fees, while a buy counts msg.value, which is gross. So the same trade size registered as two different volumes depending on direction. v1.0.0 counts a sell as amountOut plus all four fee legs, which is exactly what every curve generation adds to totalVolumeNative (leaving + depthFee in contracts/AdextoCurve.sol; 0.10.0 has no protocol leg, and its adaptor passes zero). The Envio indexer had the identical bug and was fixed first, with the same formula. No market on Base or Arbitrum One has a sell yet, so on these two chains the fix is checked against the contract's arithmetic rather than against a live sell. The contract had this bug first: see the comment on that line.
Since v0.11.0 the subgraph indexes curve generations side by side, because the 0.10.0 and 0.11.0 Swap events are not the same event: 0.11.0 inserts protocolFee before both reserves, giving it eleven fields and a different topic0. One data source cannot match both, so repointing the existing one at a new factory would have dropped every market the old factory created, and reported itself healthy while doing it. There are three factory data sources (0.10.0, 0.11.0, v1) and two curve templates, with the mapping logic held once in src/shared.ts.
Curve.curveVersion exists for the same reason: without it, protocolFeeBps: 0 on an old curve is indistinguishable from a new curve that charges nothing, which would suggest the rate can change. It cannot: it is immutable per curve.
Earlier versions: v0.10.1 fixed a 1e18 unit mismatch between openingPriceNative and spotPriceNative. v0.10.2 removed "agent buyback burns" from the manifest description, since executeBuyback has no caller gate and attributing it to an agent overstated the contract.
Both subgraphs are published to the decentralized network without curation signal. Indexers are paid in proportion to signal, so no independent indexer has a reason to pick them up. The site reads the Studio endpoints above, not the gateway.
Self-hosting runs from subgraph/docker-compose.yml. Public-RPC eth_getLogs ceilings are probed rather than assumed and recorded per chain in subgraph/chains.json: 2,000 blocks on 0G, and a hard 100 on Monad, which returns -32614 above that.
Security
There has beenno human review of these contracts. Deployed bytecode is permanent: a fix can only ship as a new factory at a new address, while every existing market keeps the code it was born with.
Several analysers and fuzzers run against the contracts (Foundry fuzz and invariant tests, Echidna, Slither, Aderyn, Solhint and Semgrep), and every finding is triaged in public at adexto.xyz/security, which also has copy-paste cast commands to check each deployment yourself. That is not offered as a substitute for a review. audit/README.md is the scope document for one: 825 SLOC across the five v1 contracts and the registry interface, with the expected results (forge test: 80 passed, 0 failed).
Report a vulnerability privately as described in SECURITY.md. Please do not open a public issue for it.
Feedback and ideas
Something broken, confusing or good? Open a feedback issue. Ideas for what to build next go to Discussions › Ideas, where they can be upvoted.
Local development
git clone https://github.com/0xcuy/adexto.git
cd adexto
npm install
cp .env.example .env.local
npm run dev # http://localhost:3000Contracts compile reproducibly, with no Hardhat run required:
node scripts/compile-contracts.mjs --via-ir # -> build/artifacts/
node scripts/deploy-factory.mjs --chain base # dry run, no gas
node scripts/deploy-factory.mjs --chain base --broadcast # spends gasBefore anything is sent, the dry run proves that the artifact was compiled from the current sources with the pinned compiler settings, that the chain executes the opcodes the bytecode uses, and that simulating the creation returns the artifact's runtime code with the treasury in its immutable slot. It prints every reserved ticker (scripts/reserved-symbols.json), because reservations are permanent. A mainnet broadcast refuses unless those sources are committed and pushed, and every fact is read back from the chain afterwards.
A full launch, buy and claim can be driven through the UI against a local chain instead of mainnet:
cd devchain && npx hardhat node # chain 31337 on :8545
node scripts/deploy-factory.mjs --chain devchain --broadcast
set -a && . ./.env.local && set +a && source scripts/devchain-env.sh
npx next build && npx next start -p 3100 # NEXT_PUBLIC_* are inlined at build timeOne thing this does not isolate: with a 0G storage key in .env.local, a local launch still anchors its metadata on 0G mainnet, which costs about 0.0013 0G per launch.
A note on reserved tickers
There are two layers, and they bind different people.
On chain, in every v1 factory. The factory's constructor writes a list of tickers into
symbolRegistryas reserved, and nothing can release them, so nobody (us included) can launch them on that factory. The list isscripts/reserved-symbols.json. Every chain reserves the same 16: the six0.11.0markets (ADEXTO,ADT,ZEEBO,WOMBO,BLOOP,PARCEL), so no lookalike can open under their names, and ten major-asset names (ETH,WETH,USDC,USDT,BTC,WBTC,0G,A0GI,MON,ARB). Robinhood Chain reserves 196 more:USDGand the 195 tokenized stocks listed as active on chain 4663 when the factory was deployed, so a curve token can never pose as a stock there. A stock listed after that date is not covered. Check any of them withisSymbolAvailable. The0.11.0factories have no such list.In the application.
checkSymbolAvailableinsrc/lib/registry.tsrefuses the major-asset names for everyone and the protocol's own tickers (ADEXTO,ADX,AEGIS,QNOVA,CSENT,MQUANT) unless the caller is inADEXTO_OFFICIAL_DEPLOYER, which is empty by default. This binds only launches that go through/api/deploy; a direct call to a factory is bound only by that factory's own list.
License
Business Source License 1.1 (BUSL-1.1). See LICENSE for terms.
Change Date: 2030-09-29 (MIT).
This server cannot be deployed
Maintenance
Related MCP Connectors
Marketplace and payment rail for AI agents: list, buy and settle with signed receipts.
Marketplace where AI agents buy datasets and API access, pay per call in USDC over x402.
Market data and web intelligence for AI agents, paid per call in USDC on Base via x402.
USDC/x402 agent marketplace. Verified Base mainnet pilot, testnet and public enrollment.
Related MCP Servers
- AlicenseAqualityDmaintenanceEnables AI agents to participate in a marketplace for buying, selling, and trading services with atomic escrow and cryptographic verification. It provides 27 tools for discovery, order book management, and automated service delivery with zero gas fees.3213 npmMIT
- AlicenseNot gradedqualityCmaintenanceEnables AI agents to resolve tokens, get quotes, check for honeypots/rug pulls, build swaps, and retrieve receipts via x402 micropayments.1MIT
- AlicenseNot gradedqualityFmaintenanceEnables autonomous agents to discover, quote, and purchase paid APIs on Base by describing capabilities in natural language, with automatic provider ranking, validation, and direct non-custodial x402 payments.MIT
- AlicenseNot gradedqualityCmaintenanceEnables agents to discover, sample, and pay per call in USDC for live threat intelligence, ZK proof generation, and arbitrage signals via the x402 protocol.MIT