Docs

A creator launches a token and picks one to three approved RWA reward assets, with weights totalling 100%. From the first trade, Pons charges fees on the ETH side of the market. Those fees do not go to the creator's wallet — they go to a contract that converts them into the chosen RWAs and sends them to the people holding the token.

How that ETH gets spent is not a fixed formula. An AI agent reads recent prices for the basket's assets and decides the split for the hours ahead, including whether to sit on some ETH rather than buy into a spike. Its room to move is bounded on chain and the bounds are set at launch, so the furthest it can stray is a modest distance either side of the weights the creator chose.

The RWAs are a reward, not a trading pair. Every Arctis market is TOKEN / ETH regardless of what its basket contains.

The same five steps, in protocol terms. Each launch runs its own three-minute clock:

1. Trading on Pons accrues ETH creator fees, credited to the launch's BasketDistributor.
2. When the window closes, a keeper calls processEpoch. The distributor pulls its accrued ETH out of the Pons fee escrow.
3. The ETH is split — by the agent's standing plan, or by the declared weights when there is no valid one — and swapped for each RWA through RewardRouter, which only follows pre-approved routes.
4. The purchased RWAs are moved to AutoAirdropDistributor and recorded as that epoch's reserve.
5. The airdrop worker computes each holder's share and submits it in batches. The contract transfers the tokens out.

Arctis launches through PonsV2LaunchFactory on Robinhood Chain (chain id 4663). Two details carry the whole integration.

The fee recipient. Pons' launch parameters include a creatorFeeRecipient. Arctis sets it to the launch's own BasketDistributor. That single field is what makes Pons pay holders instead of the creator, and Pons fixes it at creation — so a creator cannot redirect the reward stream after the fact.

ETH as the quote asset. Arctis always passes the zero address as the pair token, which is how Pons expresses a native-ETH market. Fees therefore arrive in one uniform asset for every launch.

Pons credits fees to an escrow rather than pushing them, and its claim() takes no arguments — it pays whoever calls it. So each distributor pulls its own balance during processEpoch; nothing can claim on its behalf, and a keeper has no recipient or calldata to manipulate.

A basket holds one to three assets from a curated registry, with weights in basis points that must total exactly 10,000. The assets are fixed at launch and cannot be changed afterwards, by the creator or by protocol admins — not by the agent either, which chooses how much of each to buy but never what to buy.

The weights are the creator's declared split, and they remain the reference the agent is measured against. It may move within a bounded range around them, described in the agent.

Only assets in RewardRegistry can be chosen, and each must have an approved swap route. A creator cannot point a basket at an arbitrary token address.

Each launch is paired with an agent that decides how its fees are spent. Every six hours it reads recent prices for the basket's assets and answers two questions for the epochs ahead: how to weight the legs, and whether to hold ETH back instead of buying now. Between those decisions the plan simply stands, so the model is consulted on the timescale a view actually changes rather than once per three-minute epoch.

Its discretion is small on purpose, and the limits are enforced by BasketDistributor rather than by the agent itself. The contract rejects a plan that breaks any of them, so an agent that is wrong, broken, or compromised still cannot spend outside these bounds:

Drift is measured relative to each declared weight rather than as a flat allowance, so a large leg is given proportionate room and a small one is not handed enough to double. A leg declared at 50% may sit anywhere from 35% to 65%; a leg declared at 10% moves only between 7% and 13%. Whatever the agent picks, the legs still have to total 100%.

The two remaining bounds are what stop “wait for a better price” from becoming “never buy”. Only a small amount of ETH can sit idle, and after twenty held epochs the launch must deploy its fees regardless of what the agent thinks. Holding is a pause, not a veto.

Nothing here can stall a launch. A plan that fails validation is discarded rather than repaired, and that epoch runs on the creator's declared weights instead — quietly clamping a bad answer would execute a split nobody chose. A plan also expires after 24 hours, so if the agent stops producing decisions the launch falls back to the creator's split on its own. Before submitting, the engine simulates the plan against live prices, so an allocation that could not actually be swapped never becomes a stuck epoch.

Every decision is stored with the model's reasoning and the prices it saw, so any basket a launch bought can be traced back to the plan that caused it.

With many launches running at once, nothing about a distribution is global. Every launch gets its own BasketDistributor clone, and Pons pays that specific contract, so fee streams never mix: a token's ETH physically lands in its own distributor.

Holder rewards are held in one shared AutoAirdropDistributor, but every record inside it is keyed by the launched token first:

Two guards keep those namespaces honest. Only a launch's registered distributor may credit that launch's reserves, and no allocation can exceed the reserve recorded for its own token and epoch. This matters because the reward assets themselves sit in one pooled contract balance: if two launches both reward the same asset, they share an ERC-20 balance, and it is the per-launch accounting that stops one from spending the other's share.

The holder list itself is not computed on chain. The indexer follows ERC-20 transfers for each launched token and keeps balances per token and wallet, so a wallet holding two Arctis tokens has two independent balances and earns each basket separately. At epoch close, the worker reads the snapshot for that one token, allocates pro-rata by balance, and submits the result as an explicit list of recipients and amounts.

So a holder of token A receives only token A's basket, in proportion to their share of token A. Holding both tokens simply means being included in two separate distributions.

Eligibility is a token balance at the epoch snapshot. There is no staking, no lockup, and no registration. Allocation is strictly pro-rata: your share of the basket equals your share of the eligible supply.

A small set of addresses is excluded explicitly — the zero and burn addresses, the protocol's own contracts, and the launch's Pons bonding curve. The curve matters most: Pons mints the entire supply to it, so until the launch graduates the curve is by far the largest holder. Leaving it in would hand nearly every reward back to the venue.

Rewards are pushed, not claimed. There is no claim() function for holders to call, which means no gas cost, no forgotten rewards, and no advantage for whoever watches the chain most closely.

Two details make pushing safe. A reward below a per-asset dust threshold stays pending and accumulates instead of being sent, so tiny balances do not cost more in gas than they are worth. And a transfer that fails — a token that reverts on a particular recipient, for instance — is isolated: that holder's balance stays pending and the rest of the batch still goes out.

The protocol's own $ARCTIS token follows a different economic model. Its creator fees go to the protocol treasury rather than buying an RWA basket, so it never gets a BasketDistributor and never distributes RWA rewards. The launchpad rejects any attempt to give it one.

Six contracts are deployed once on Robinhood Chain and shared by every launch, listed here in the order a launch touches them. Every address is shown in full and links to the explorer, so nothing on this page has to be taken on trust.

One per launch

BasketDistributor is the exception: there is a separate one for every token, created at launch, and its address is shown on that token's page. It is the contract Pons pays. It holds that launch's ETH, runs its three-minute clock, and on each epoch pulls its fees out of the Pons escrow, splits them by the basket weights, sends them through RewardRouter, and hands the purchased RWAs to AutoAirdropDistributor. Its basket is fixed at creation and cannot be changed by anyone, including protocol admins. Neither the creator nor an admin can withdraw from it — there is no function to do so.

Supporting code

BasketLib holds the basket rules, so the same validation applies wherever a basket is read: one to three assets, no duplicates, no zero weights, every asset in the registry, and weights summing to exactly 10,000 basis points. V3Path encodes Uniswap V3 swap paths and checks that an approved route really starts at WETH and ends at the asset it claims to buy. ArctisTreasury receives the native token's fees and is deliberately never attached to a launch, which keeps protocol revenue and holder rewards from touching the same accounting.

Retired

The launchpad and the adapter are not upgradeable, so changing them means deploying new ones. These are the versions they replaced. They can no longer create launches, but the tokens they did create are unaffected and still earning: a launch's rewards run through its own distributor, which does not depend on the launchpad that created it.

Two keys sign continuously from a server: a keeper that closes epochs and a worker that sends the airdrops. Both are deliberately limited, because a server key is the one most likely to be stolen.

The agent holds neither a key nor a role. It writes plans to a database; the keeper is what carries one on chain, and the distributor bounds-checks it on arrival. So the agent's influence stops at choosing a point inside a range that was fixed when the token launched.

What no role can do matters more. Nobody can change a basket after launch, redirect where a launch's fees go, withdraw ETH or RWAs from a distributor, or pay a swap out to an address of their choosing. Those are not permissions that are withheld — the functions do not exist.