ADEXTO Protocol (adexto.xyz)

Market infrastructure for the agent economy. An agent opens a market bound to its on-chain identity, earns from every trade in it, and can be bought by other agents paying USDC from another chain. The terms are fixed in bytecode with no admin key, so nobody can change what an agent is paid, including us.

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 from wherever their money already is. Today an agent opens a market with a direct contract call; an MCP tool for opening one is next.

Live on 0G, Base, Arbitrum One and Monad from one byte-identical factory. The contracts, tests and web app live here; the chain-specific engineering lives in 0xcuy/adexto-arbitrum and 0xcuy/adexto-monad.

What this is

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 these arrive with it — none of them a roadmap item, none needing a listing or an application:

Launching is built to be quick to decide on. The studio shows what the launch will cost on the chain you picked before you sign, its default Express mode needs only a name, a ticker and an image, and the success screen drafts the announcement for X and Farcaster. Beside the markets, every market can be staked from its first block, and Agent Compute gives a staker an API key to an OpenAI-compatible endpoint on the 0G Compute router: with tiered allowances for $ADEXTO on 0G and $SAI on Monad, Arbitrum One and Robinhood Chain, and with an allowance funded by the market's own trading for every other market.

What is not here: no autonomous trading bot runs a market on a creator's behalf. ERC-8004 identity binding is real and verified on-chain at launch, but it is opt-in and it records an identity rather than starting a strategy.

How the market itself 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. Nothing is added on top. Markets created by the previous factory keep their own rates permanently. Full breakdown in Fee split.

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 historically happened. There is also no withdrawal function anywhere in the curve, so no one — 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 one of these tokens on any external AMM without our permission, and we could not stop it — a second market with its own price can exist alongside the curve. The guarantee is narrower than "one market": we never migrate, and nobody can withdraw the curve's reserves.

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:

AdextoFactory 0.11.0, which created the six markets listed today. 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:

Read totalFeeBps() 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.

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. 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 — 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 after a delivery once the bucket covers three times the gas, and so far only $ADEXTO has burned anything.

Related MCP server: Tollbooth MCP Server

⚙️ What one launch creates

graph TD
    Creator([Creator]) -->|1 tx per chain, gas only<br/>deployTrinity is NOT payable| Factory[AdextoFactory v1.0.0]

    Registry[[ERC-8004 Identity Registry<br/>optional, off by default]] -.->|ownerOf agentId — 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 curve first,<br/>so the token can bind it immutably| Curve[AdextoCurve — own AMM<br/>virtual reserve, no deposit<br/>no owner, no withdraw/sweep/rescue]
        Factory -->|2. deploys token,<br/>mints 100% of supply to itself| Token[AdextoToken — plain ERC-20<br/>no owner, no pause, no blacklist<br/>1%-per-tx cap through launchBlock+5]
        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]

    classDef live fill:#f5f3ff,stroke:#7c3aed,stroke-width:2px,color:#201810;
    classDef partial fill:#fffbeb,stroke:#f59e0b,stroke-width:2px,color:#201810;
    classDef ext fill:#eef2ff,stroke:#4338ca,stroke-width:2px,color:#201810;
    class Factory,Token,Curve,Depth,CreatorFee,Vault,Burn live;
    class Meta partial;
    class Registry ext;

Three things in that picture exist but are not part of deployTrinity:

• agentIdentity is just an address. It is required non-zero and stored immutably on both the token and the curve, and it may call executeTreasuryBuyback to 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 buy with the payer as recipient, exactly like any other address, and it holds no privileged position: it cannot deposit into treasuryNative, 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. executeBuyback carries only nonReentrant and live — 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 by a direct eth_getCode call against the chain's RPC. 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, executable generation, broadcast on 2026-10-01 to five mainnets: 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. Every new launch goes through it.

Its runtime bytecode is byte-identical across all five chains (21,806 bytes, keccak 0x1ca02ca53a3b2a2082f9e5dab6924e1339110e3037608f750981699678881fd4) and 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. Sourcify reports an exact match, creation and runtime, on all five chains. 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. /security has the commands to check each of these yourself.

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.

0.11.0 is listed alongside it because the six earlier markets were created by it, and they keep its rates permanently. Each row states its VERSION as read from the contract.

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 from commit f8328ab43375c8a785ccf86fb4dfe39c83c2986f. 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. There is no owner, pause, lock or reward. Its runtime is byte-identical across all five chains (4,278 bytes, keccak 0x88247303e4851282bbf22dd4f23e753b08a6862ea40f32d9c0464e92730b081a) because it has no immutables: the factory and exclusion lists live in storage. Sourcify reports an exact match, creation and runtime, on all five chains.

0G Mainnet · chain ID 16661

Base Mainnet · chain ID 8453

Arbitrum One · chain ID 42161

Monad Mainnet · chain ID 143

Robinhood Chain · chain ID 4663

An Arbitrum Orbit chain. ADEXTO v1 is the first generation here, so there is no superseded factory. Its first market is $SAI (SAi Robin).

The factory sits at the deployer's first-nonce address, and on Base and Monad that same address holds an unrelated pre-release contract. An address means nothing without its chain id.

Deployer: 0x8a3c7524Aaed081825aC88eC7f4cCECFc583ee7D

Protocol treasury: 0x24268Fffc119ec5550F68e80D94476fD64daE967 — the immutable destination of the 0.10% protocol leg on every 0.11.0 and v1 curve. 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 on all four mainnets when it was chosen.

📋 Honest status

Why a bonding curve rather than a liquidity pool

The reason is the launch model, and it is checkable in the contracts rather than a matter of taste.

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 holders, and "we won't" is only a promise. Here the guarantee is the absence of code that could do it.

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 — the factory calls ownerOf(agentId) and reverts unless the caller owns that agent. 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.

Five things that will bite you otherwise, and the first one already bit us.

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 four mainnets, which invites the assumption that an id is global. It is not — each registry keeps its own state, and ownerOf(0) returns three different owners across the four chains. Our own registrations came back 84622 on Base, 1457 on Arbitrum, 3545431 on 0G and 10247 on Monad for the same agent — plus 10251, a second Monad registration, which is the one the live Monad markets bind. Launching four chains with one id binds on the chain it came from and reverts on the rest 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 0G, Base, Arbitrum One and Monad, 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 our own four chains shows 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 devchain

Registering on all four cost roughly $0.10 in total across eight transactions.

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.

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 — 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.

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.

Two mechanics worth knowing before building on it:

• The burn is funded by trading, it runs without anyone deciding to, and supply has already fallen. treasuryNative fills from the buyback leg of swap fees, so nothing can be deposited into it and nothing needs to be — an x402 delivery is itself a buy, so it pays that leg and the vault grows on every fill. After a purchase settles, the edge spends the vault through executeBuyback to buy and burn, gated on the vault being worth at least 3x the gas to trigger it: one call costs about 0.0005 0G while a fill contributes 0.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 destroyed 7.110759702852663544 $ADEXTO and took total supply to 999,999,918.730575824909329011 — 0x792023ab…8ab66bc5. executeBuyback has no caller gate, so the burn does not depend on us running it, which was verified by simulating the call from a random address.

• agentIdentity is set once, at launch, and is immutable. On the live $ADEXTO token it is 0x8a3c…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. No bridge, and no need to hold that chain's gas asset. All four mainnets are live targets; when the market happens to live on Base too, payment and delivery land on the same chain and nothing crosses — same code path, one less hop.

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 TransferWithAuthorization is 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 retired X-402-Authorization header 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_KEY is 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. Because transferWithAuthorization is permissionless and its whole content is signed by the payer, including to and value, 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 503 once 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.

All four mainnets are delivery targets, and none of them 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. Each one has been paid for once with real funds; the transaction hashes are in the status table.

Making that work on the two 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.

The buyback router that would close the revenue edge above, together with the Monad-specific engineering, is tracked in a separate repository: 0xcuy/adexto-monad. The curve, factory, registry and terminal stay here.

An LLM can now 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: 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.

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/).

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.

The v1 factories are not in the manifest yet. networks.json still names only the 0.11.0 and 0.10.0 factories, so a market launched on Base or Arbitrum today does not appear in either subgraph. Nothing breaks: the site falls back to RPC logs and its own per-market index, which read from the launch block. The fix is small, because v1 emits exactly the events 0.11.0 does — TrinityProjectDeployed, AgentBound, CurveInitialized and the eleven-field Swap share their signatures and topic0 — so the existing templates apply and only a data source for the new factory addresses is missing. It has not been published yet.

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 Graph cannot serve either of those chains anyway — 0G is absent from its networks registry, and monad is listed there without Subgraphs support. 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.

Known bug, stated because it affects numbers this subgraph publishes: subgraph/src/shared.ts counts sell volume as the event's amountOut, which is the native a seller receives after fees, while a buy counts msg.value, which is gross. So the same trade size registers as two different volumes depending on direction, and volumeNative on Base and Arbitrum is short by the fee slice on every sell. The Envio indexer had the identical bug and it is fixed there; correcting it here means publishing a new subgraph version across the live chains, which has not been done yet. The contract itself had this bug first — see the comment on totalVolumeNative += leaving + depthFee in contracts/AdextoCurve.sol.

v0.11.0 indexes both curve generations side by side, because the two 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 the new factory would have dropped every market the old factory created — and reported itself healthy while doing it. There are two data sources and two 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.

Nothing is published to the decentralized network, and publishing alone would not make it serve queries: indexers are paid in proportion to curation signal, so a subgraph with token signal gives them no reason to index it. The Studio endpoints above answer queries today without that.

Two of the four chains cannot use Subgraph Studio. That is The Graph's coverage, not our choice:

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.

🛠️ Local development

git clone https://github.com/0xcuy/adexto.git
cd adexto
npm install
cp .env.example .env.local
npm run dev          # http://localhost:3000

Contracts 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 gas

Before 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 time

One 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 symbolRegistry as reserved, and nothing can release them, so nobody — us included — can launch them on that factory. The list is scripts/reserved-symbols.json. Every chain reserves the same 16: the six live markets (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: USDG and 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 with isSymbolAvailable. The 0.11.0 factories have no such list.

• In the application. checkSymbolAvailable in src/lib/registry.ts refuses the major-asset names for everyone and the protocol's own tickers (ADEXTO, ADX, AEGIS, QNOVA, CSENT, MQUANT) unless the caller is in ADEXTO_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).

© 2026 ADEXTO Core Contributors · adexto.xyz