How the Atlas protocol works

Overview

Atlas is an NFT collection where the only thing that changes an NFT's value is what its holder chooses to do with it. There is no rarity roll at mint. Every sphere starts identical: mass 1, Tier 1, inactive. From there, two independent choices shape it: whether to merge it into something heavier, and whether to activate it to earn a share of protocol revenue.

Both are opt-in, both cost something real, and neither is required to hold a sphere. That's deliberate. A sphere that's never touched after mint still exists, still belongs to whoever holds it, and costs nothing to keep.

The short version

Mint a sphere. Merge it into others to raise its mass, at a cost, if you want it heavier. Activate it by depositing $ATLAS, sized to its tier, if you want it to earn. Activated spheres share in buybacks by weight. Vote with that same weight to trigger the next buyback once enough revenue has accumulated. Every step after mint is optional, reversible where it makes sense to be, and irreversible where reversibility would break the model, merging most of all.

The loop

There's no epoch or fixed schedule driving Atlas. Merging happens whenever two holders agree to it. Activation happens whenever a holder decides the yield is worth the $ATLAS. The only thing on a cycle is the buyback vote, and even that has no fixed cadence, it happens whenever quorum is reached, which could be the same day or take a week depending on real usage.

Network

Everything runs on Robinhood Chain. Spheres, $ATLAS, the vault, the vote, and the liquidity pool are all on the same chain, so no step in the loop crosses a bridge.

Spheres & mass

Ten thousand spheres exist once mint completes: 9,500 public, capped at 25 per wallet, and 500 reserved for the team, minted through the exact same code path as everyone else's, mass 1, Tier 1, no head start.

Mass is the one number that matters. It's stored on chain, exactly, as a fixed-point value scaled by 1e6, and it only ever grows through merging. A sphere's radius in the site's visuals is derived directly from it:

Everything else, tier, weight, activation cost, is computed from mass. Nothing about a sphere is stored redundantly or can drift out of sync with its mass.

Metadata

Art is off-chain, IPFS-hosted: five static renders, one per tier, matte black through a subtle progression to Tier 5's violet glow. tokenURI() reads a sphere's on-chain mass, computes its current tier, and returns that tier's image URI. Mass itself is always exact on chain, the image is a per-tier representation rather than a per-mass render, so merging into a new tier changes the returned image on the next metadata refresh, nothing has to be re-minted or re-uploaded.

Merge

Merging is the only way mass grows, and it's cross-wallet: you don't need to own both spheres.

1. Propose. proposeMerge(myTokenId, targetTokenId), callable by whoever owns myTokenId, paying a flat 0.001 ETH protocol fee.
2. Lock. Both tokens lock immediately, they can't be transferred, listed, or entered into another proposal while this one is pending.
3. Accept or expire. The current owner of targetTokenId calls acceptMerge(proposalId) to complete it. Ownership of both tokens is re-checked at accept time, so a token that changed hands mid-proposal fails safely rather than merging the wrong owner's asset. If nobody accepts within 24 hours, the proposal expires and either side can clear it; the proposer can also cancel manually before then.
4. Settle. On accept, the two masses combine and 8% of the total burns:

The resulting sphere belongs to the proposer. The target sphere is burned outright, it no longer exists after the merge, not transferred, not held in reserve.

Tiers & weight

Weight is what actually earns. It's read off a fixed table by mass range, and it grows deliberately slower than mass, on purpose: mass is unbounded and grows every time two spheres merge, but weight is capped per tier so a single sphere's earning power can't run away just because its holder kept feeding it mass.

Notice the ratio: going from Tier 1 to Tier 5 takes roughly 64× the mass but only pays 18× the weight. A holder who merges aggressively toward Tier 5 is paying an accelerating mass cost for a decelerating weight return, that's the deliberate anti-whale shape of the table, not a bug in it.

Activation

Owning a sphere earns nothing by itself. Activating one deposits the $ATLAS listed for its current tier, 8% of which burns immediately and permanently, 92% of which is held as a stake the holder can reclaim in full, any time, by deactivating.

Auto-deactivate on transfer

Selling, gifting, or trading an activated sphere deactivates it automatically as part of the transfer. The 92% stake returns to the wallet that originally staked it, not the new owner, and the new owner receives a clean, inactive sphere they have to activate themselves if they want it earning. Without this, a buyer could deactivate immediately after receiving an activated sphere and claim a stake they never deposited.

Voting eligibility has a timing rule

A sphere must have been continuously activated since before the current voting window opened to count toward that window's quorum. Activating and voting in the same window, or the same transaction, doesn't work, this is the flash-loan guard described under governance.

The vault

RewardsVault holds every activated stake and every unclaimed reward, and it's the only contract that moves $ATLAS between holders. Two things worth understanding about how it pays out: the accounting pattern, and the whale cap.

Reward accounting

A sphere's weight can't change while it's activated, merging an active sphere is blocked in both directions (see security notes), so every active token earns at a constant rate for its entire active period. That lets the vault use a single global accumulator rather than tracking every wallet's history individually, the same pattern used by MasterChef- and Synthetix-style staking contracts:

• Every buyback increases a running accumulator by holderPool × PRECISION / totalActiveWeight.
• Each activated token stores a snapshot of that accumulator at the moment it last settled. Its pending reward is always weight × accumulator / PRECISION − snapshot.
• claim(tokenIds[]) is pull-based: the caller supplies which of their own tokens to settle, bounding their own gas cost, and it automatically folds in any balance rolled over from tokens they've since deactivated. Deactivating never forfeits reward already earned.

The 5% whale cap

No single wallet can claim more than 5% of a given buyback's holder pool, regardless of mass or how many spheres it holds. The cap is applied at claim time, against the most recent buyback's holder pool, a v1 simplification: for anyone who claims reasonably often this is identical to an exact per-round cap, it only diverges for a wallet that lets rewards sit unclaimed across several buybacks. Flagged here as a known v1 design choice.

Whatever a claim would exceed the cap isn't redistributed to other holders in that round, it stays in the vault's balance as a buffer rather than being lost or reinjected.

The vote & buybacks

Revenue, merge fees and secondary royalties, accumulates in the vault as ETH continuously. It doesn't convert to $ATLAS automatically or on a timer, that only happens through a buyback, and a buyback only fires when holders vote it into existence.

Flash-loan guard

Only spheres activated before the window opened count toward that window's quorum. A sphere activated after the window's already open, even seconds after, can't vote in it. This closes the obvious attack: borrow a large $ATLAS balance, activate a pile of spheres, vote, and unwind it all in one block.

What happens the instant quorum crosses

The vote that pushes cumulative "yes" weight past 33% triggers the buyback in that same transaction. BuybackGovernor calls RewardsVault.executeBuyback(amountOutMinimum), which wraps the vault's ETH balance to WETH and swaps the whole balance for $ATLAS through a Uniswap-V3-shaped router. amountOutMinimum is computed off chain against a slippage bound (3% default, adjustable through the timelocked parameter path); if the swap can't clear that minimum, the whole call reverts and the ETH stays in the vault for the next attempt rather than executing at a bad price.

The $ATLAS received splits 70% to activated holders, 30% to the team, sent to the team address immediately. The holder side doesn't get paid out directly, it funds the accumulator described under the vault.

Liquidity & LPLock

Liquidity is self-deployed, not routed through a launchpad. 25% of total mint proceeds funds the ETH side of a Uniswap V4 pool (0.3% fee tier), paired against the full 60,000,000 $ATLAS liquidity allocation.

The resulting position, a V3 NFT, is sent straight to LPLock.sol, a purpose-built contract with no function anywhere, public or owner-only, that can move the underlying liquidity back out. The only thing it can do is collect trading fees already owed to the position and forward them to a configurable recipient. This isn't only described here, it's verified directly: one of the contract's own tests scans its full ABI and asserts no withdraw, unlock, or liquidity-decreasing function exists anywhere in it.

$ATLAS

Fixed supply, no minting after deploy, and no reward emission. Nothing here is a promise about future behavior, it's a description of what the contract is capable of: there is no function anywhere in AtlasToken that creates new supply beyond what's minted once, at construction.

There is deliberately no fifth "circulating" or treasury bucket. Every $ATLAS that isn't vesting to the team or held for claim in the airdrop is already in the liquidity pool from day one, nobody, including the team, holds an undisclosed stash. Circulating supply is the pool; anyone acquires $ATLAS by buying from it, the same as any other market participant.

Where $ATLAS gets burned

Two separate, permanent burn paths, serving different purposes:

• Activation burn (8%). Every activation permanently removes 8% of the deposited $ATLAS from supply. This is a cost of participating in yield, not a reward mechanism.
• Merge burn. Merging burns 8% of combined mass, a separate on-chain quantity with no direct dollar value, not $ATLAS itself. The real revenue from merging is the flat 0.001 ETH protocol fee, kept deliberately separate from the mass mechanic.

The sell fee, and why it isn't a transfer tax

$ATLAS itself is a plain, unmodified ERC-20, there's no fee override in the token contract, no exemption list, nothing to be exempt from. The 5% resting fee lives one layer up, in SellFeeHook, a Uniswap V4 hook attached only to the $ATLAS/WETH pool, charged only on sells (WETH received for $ATLAS given), never on buys, and never on a plain wallet-to-wallet transfer.

That distinction is the entire point. A token-level tax breaks composability with routers and aggregators that assume the amount sent equals the amount received, forces an exemption list covering every contract that ever needs to move the token (every DEX router, every aggregator, LPLock itself), and is exactly the pattern most token scanners flag as a red one. A pool-level hook fee avoids all of that: a plain transfer() or transferFrom() never touches the hook at all, only an actual swap through that specific pool does. See the vote & buybacks for the merge-fee-and-royalty side of revenue, and section 7a of ATLAS_SPEC.md for the fee's exact parameters (5% resting, 10% hard ceiling, no opening ramp, split 80% RewardsVault / 20% team).

The pool

One position, not a ladder. $ATLAS's liquidity is a single full-range Uniswap V4 position, seeded once and handed to LPLock permanently, see liquidity & LPLock. There's no tranched or laddered structure releasing supply in stages as price climbs.

That's a real tradeoff, made on purpose. A laddered position prices size better, a large buyer pays more per token than a small one, which a single flat position can't do. But it also means managing many separate positions over time: tranches to place, potentially to adjust, more contract surface doing more things. LPLock's entire guarantee rests on being the simplest thing it can possibly be, hold one NFT, forward its fees, do nothing else, forever. A single full-range position is what makes that guarantee easy to verify at a glance instead of something you have to trust a management process to maintain correctly over months.

Reward emission: none

Rewards paid to activated holders come only from real buybacks, funded by real revenue, merge fees and secondary royalties. There is no scheduled unlock, no decaying curve, and no token minted to pay yield. A quiet week with little merge or trading activity pays a small buyback. That's the honest shape of the design: it can be quiet, but it can never become insolvent by promising more than it collected.

Roadmap

Two things extend the core loop above, in active development alongside everything on this page: a native NFT marketplace that makes the 5% royalty non-optional and adds a bundled buy-and-merge action, and a token launchpad that reuses LPLock's permanent-lock design for every project launched through it. Full detail, including how launchpad featuring and $ATLAS-paired launches work, is in the whitepaper's roadmap section.

Who can do what

Nothing in this table can mint $ATLAS beyond the fixed 100,000,000 supply, move a sphere's mass or ownership without its owner's transaction, or withdraw the locked LP position. Those aren't permissioned actions with a gate somebody could open, they're functions that don't exist anywhere in the contracts.

Upgrades & immutability

None of the five contracts are upgradeable. There's no proxy pattern anywhere in Atlas, no UUPS, no Transparent proxy, nothing. Once each contract is deployed, its logic is permanently fixed. There is no owner key, multisig, or vote anywhere that can replace what a contract does.

What can change is a narrow, pre-defined allowlist of parameters, not logic:

Every change to a timelocked parameter is publicly visible for 48 hours before it takes effect, nothing lands instantly. And regardless of what's adjusted, the multisig can never:

• Touch a holder's funds directly, there's no sweep or admin-transfer function over user balances.
• Mint $ATLAS beyond the fixed 100,000,000 supply, the mint path doesn't exist past construction.
• Alter mass, weight, or ownership of any sphere.
• Move the locked LP position out of LPLock, there's no function anywhere in it that could.

Security notes

Engineering defaults applied throughout, not points of pride:

• Reentrancy guards and checks-effects-interactions ordering on every function that moves ETH or $ATLAS.
• SafeERC20 used for every token transfer in the codebase.
• Merge proposals lock both tokens for their full duration, closing any double-use or transfer-out-from-under window.
• Buyback swap slippage is bounded; a swap that can't clear its minimum reverts rather than executing at a bad price.
• A sphere can never be both activated and merge-eligible at once, checked in both directions (SphereNFT checks the vault, the vault checks SphereNFT), closing a path that could otherwise orphan a stake permanently.

Two risks are inherent to the design and disclosed rather than hidden:

• Sybil limitation. Any address-based weight system is vulnerable to activity split across many wallets. The 5% whale cap and 33% quorum reduce the practical impact but don't eliminate it.
• MEV on the buyback swap. Any on-chain swap triggered by a public transaction can in principle be front-run. Slippage bounds limit the damage; they don't eliminate the risk.

Numbers at a glance

Everything above is enforced by contracts on Robinhood Chain and can be read from the chain rather than taken on trust.