Everything Atlas is,
written down in one place.

A sphere that remembers its mass.

Atlas is 10,000 spheres on Robinhood Chain. Every sphere starts with mass 1. Owners can merge two spheres into one heavier sphere, at a cost: 8% of the combined mass is destroyed in the process. Mass determines what a sphere looks like. A separate, deliberately slower-growing number, weight, determines what it can earn.

Earning requires activation: staking $ATLAS against a sphere. Activated spheres share in a reward pool that's funded entirely by protocol usage, merge fees and secondary royalties, never by minting new tokens. That pool only converts to $ATLAS and pays out when activated holders vote to trigger it.

Nothing here is automatic or hidden. Every rate, every split, and every parameter on this page is disclosed before a single contract is deployed.

Mass is not weight.

Mass grows through merging and determines a sphere's tier. Weight is read from a fixed tier table, not calculated proportionally from mass, so it grows much more slowly than mass does. A sphere's radius for display purposes follows radius = 40 × mass^(1/3), a constant-density sphere assumption.

This separation is deliberate. If weight scaled linearly with mass, the optimal strategy would always be to consolidate everything into one wallet. Because it doesn't, holding many small spheres earns meaningfully more per unit of activation cost than holding one enormous one.

Mass is public and permanently on-chain. A separate leaderboard on the site ranks holders by their single heaviest sphere, purely a display feature, not a protocol mechanic. It exists because the whale cap (see Governance) removes any yield incentive to keep growing past a point, so being visibly the heaviest is the only thing left to chase there.

Merging costs mass.

8% of the combined mass is destroyed on every merge, permanently. This isn't a fee paid in a separate currency, it's the asset itself getting smaller in the process of combining. A flat 0.001 ETH protocol fee is charged on top, paid by whoever initiates the merge.

Cross-wallet merging

Merging isn't limited to spheres in the same wallet. Anyone can propose merging their sphere with someone else's:

• The proposer calls proposeMerge, naming their own token and the target token. Both tokens lock, they can't be transferred, listed, or entered into another proposal while pending.
• The target token's owner calls acceptMerge to confirm. Ownership of both tokens is re-checked at that moment, so a proposal can't be accepted against a token that's since changed hands.
• Unaccepted proposals expire automatically after 24 hours, and the proposer can cancel manually at any time before that.
• The resulting sphere belongs to the proposer, who also pays the protocol fee. The target's sphere is burned.

There is no built-in payment or escrow for the counterparty. If two parties want to trade value for a merge, that's arranged directly between them before either side calls propose or accept.

Owning doesn't earn. Activating does.

A sphere earns nothing until it's activated. Activation deposits the $ATLAS listed for that sphere's current tier: 8% is burned immediately and permanently, 92% is held as a reclaimable stake. Deactivating returns that 92% in full, at any time, with no lockup and no penalty.

Transfers automatically deactivate

Selling or transferring an activated sphere deactivates it as part of the same transaction. The 92% stake returns to whichever wallet had it staked, and the new owner receives a clean, inactive sphere that they'll need to activate themselves. This prevents a buyer from deactivating a sphere they didn't stake and claiming someone else's $ATLAS.

Activation age and voting

A sphere only counts toward governance voting weight if it was activated before the current daily voting window opened, see Governance for why.

Locked spheres can't be activated

A sphere with a pending merge proposal can't be activated until that proposal resolves (accepted, cancelled, or expired). This is the same protection from the other direction as the merge-lock rule above, an activated sphere's stake must never be exposed to getting burned mid-merge.

Mint funds the team. Usage funds you.

Mint revenue and ongoing protocol revenue are kept structurally separate, so the team's launch capital and holders' ongoing yield never compete for the same money.

Merge fees, royalties, and the sell fee's holder share all accumulate as plain ETH inside the vault, regardless of source. None of it converts to $ATLAS on a schedule, only a successful buyback vote triggers that conversion, split 70% activated holders / 30% team at that point. What differs is only how each source reaches the vault: merge fees and royalties sit in SphereNFT until swept, the sell fee's split (80% vault / 20% team, in $ATLAS, unwrapped to ETH) happens the moment anyone calls SellFeeHook.distribute(), permissionlessly, no vote required for that step, it's the buyback that converts whatever ETH has accumulated, from any source, into claimable $ATLAS.

This split applies to every buyback, whenever one executes. No wallet can claim more than 5% of a single buyback's holder-side pool; unclaimed excess above that cap rolls forward into the next buyback rather than being redistributed within the same one.

Buybacks need your vote.

A one-hour voting window opens once a day at a fixed time (18:00 UTC by default). Any wallet with a sphere that's been activated since before that window opened can cast one yes vote, weighted by their active weight at the moment of voting.

If cumulative yes-weight crosses 33% of total active weight, the buyback executes immediately in that same transaction: the vault's accumulated ETH swaps for $ATLAS on the open market (with a bounded slippage tolerance, default 3%, supplied by whichever voter's transaction happens to cross quorum) and splits 70/30 as described above.

If a window closes without reaching quorum, nothing resets. The accumulated yes-weight carries into the next day's window and keeps building until 33% is crossed, however many days that takes. The ETH sitting in the vault doesn't expire or decay while this happens.

Window vs. cycle

These are two different spans of time. A window is the one-hour daily slot when voting is possible. A cycle is the longer, variable-length period from one buyback to the next, it may span a single window or many consecutive days' windows while yes-weight accumulates toward quorum. Each wallet can vote once per cycle, not once per window; voting once means waiting for either quorum to cross (starting a new cycle) before voting again.

How rewards are actually tracked on-chain

A sphere's weight can't change while it's activated, merging an active sphere is blocked, so every active token earns at a constant rate for its whole active period. This lets the vault use a single global accumulator (a standard staking-rewards pattern) rather than per-wallet or per-round bookkeeping: every buyback increases that accumulator by holderPool / totalActiveWeight, and each token's pending reward is read off independently. Claiming is pull-based, claim(tokenIds), callers supply which of their own activated tokens to settle, and any balance left over from a token they've since deactivated rolls into a claimable balance rather than being lost.

The 5% whale cap is applied at claim time against the most recent buyback's holder pool, not recomputed retroactively for every historical round a wallet may have skipped. For anyone who claims reasonably often this is identical to an exact per-round cap; it only diverges for wallets that let rewards sit unclaimed across several buybacks, disclosed here as a deliberate v1 simplification.

Fixed supply. No inflation, ever.

$ATLAS has a fixed total supply set at deployment. No function in any contract, including AtlasToken itself, can mint additional supply afterward, which is what makes the 8% activation burn a genuine, permanent reduction in max supply rather than a number that gets quietly re-inflated elsewhere.

There are four allocations, all set once in the constructor. There is no fifth "treasury" bucket held by anyone, everything that isn't vesting to the team or claimable through the airdrop is in the liquidity pool from day one.

Self-deployed, not launchpad-routed.

Robinhood Chain's primary AMM is Uniswap, live with v2, v3, v4, and UniswapX support since the chain's first day. Rather than routing through a launchpad and its fee structure, Atlas deploys its own $ATLAS/WETH pool directly.

25% of total mint proceeds, roughly 12.5 ETH if the collection sells out at 0.005 ETH × 10,000, funds the ETH side of that pool, paired against the full 60,000,000 $ATLAS liquidity allocation. The pool is Uniswap V4, 0.3% fee tier. Originally built on V3 for its simplicity; revisited once the sell fee below was decided, since a fee that lives at the pool level rather than the token level (see Revenue) needs a V4 hook, there's no equivalent on V3.

LPLock.sol

The resulting V4 position is an NFT, minted directly to a purpose-built contract, LPLock.sol. LPLock has no function anywhere, public or owner-only, that can move the underlying liquidity back out; the position stays there permanently. The only thing LPLock can do is collect trading fees already owed to the position and forward them to a configurable fee recipient, which never touches the principal. This isn't just described here, it's verified: one of the contract's own tests scans its full ABI and asserts no withdraw, unlock, or liquidity-decreasing function exists.

SellFeeHook.sol

A Uniswap V4 hook charging a flat 5% fee on sells only (buys and plain wallet transfers are never touched), split 80% to activated RewardsVault holders, 20% to the team. Because it's a pool-level hook rather than a token-level transfer tax, a plain transfer() never routes through it at all, only an actual swap through the $ATLAS/WETH pool does, so it doesn't break router or aggregator composability the way an ERC-20 transfer tax would. No opening ramp: the resting rate applies from the moment trading opens, and a 10% hard ceiling is baked into the contract, not just a default the team promises not to exceed.

Three phases, in order.

• Mint - 10,000 spheres at 0.005 ETH each, 9,500 public (capped at 25 per wallet) and 500 reserved for the team, minted the same way as everyone else's: mass 1, Tier 1, no head start. Merging works immediately. $ATLAS doesn't exist yet, so there's nothing to activate and no rewards to earn in this phase.
• Liquidity - once mint proceeds are collected, AtlasToken deploys (5% to the team's vesting wallet, 95% straight to the pool-seeding address), the Uniswap V3 pool is seeded with 25% of total mint ETH, and the resulting LP position locks permanently in LPLock, per Liquidity above.
• Activation - RewardsVault and BuybackGovernor deploy, and SphereNFT is wired to RewardsVault so transfers auto-deactivate correctly. Activation, voting, and buybacks all turn on together. This is when holding a sphere can start earning something.

Six contracts. Immutable core.

All six are written and covered by an automated test suite (100+ tests passing at time of writing). Addresses will be published here the moment each contract is deployed and verified, alongside a link to the verified source on Robinhood Chain's Blockscout explorer.

Immutable core, limited timelocked parameters

Core logic, ownership rules, merge mechanics, and every path that moves funds, can never change after deployment. A team multisig may adjust only a pre-defined allowlist of parameters (protocol fee amounts, quorum percentage, the daily voting window time and length), and every such change goes through a public 48-hour timelock before taking effect. The multisig cannot touch user funds, cannot mint tokens beyond the fixed supply, and cannot alter any sphere's mass, weight, or ownership. In the current build these parameters sit behind a plain owner key for testability; before mainnet deployment, ownership of both adjustable contracts transfers to a TimelockController so the 48-hour delay is enforced on-chain, not just promised here.

No backend required to function.

Every core mechanic, minting, merging, activating, voting, claiming, runs entirely on-chain and is called directly from a connected wallet. Sphere images are static, tier-based renders hosted on IPFS; tokenURI reads a sphere's on-chain mass and returns the matching tier's image. None of this depends on a company-run server staying online.

What a backend or indexing layer would add is convenience, not function: fast collection browsing, leaderboards, historical merge and vote activity, or social bots announcing on-chain events. Where that's useful, it will likely take the form of a subgraph or similar indexer reading public chain data, never a custodial service holding funds or a required intermediary for any core action.

Defaults chosen for correctness, not convenience.

• Reentrancy guards and checks-effects-interactions ordering on every function that moves ETH or $ATLAS.
• SafeERC20 used throughout for all token transfers.
• Reward claims are pull-based, holders call claim() themselves, the contract never loops through and pushes payments to a list of addresses, which would risk hitting gas limits or being blocked entirely by a single reverting recipient at 10,000-holder scale.
• Merge proposals lock both tokens for their duration, preventing double-use or a token being pulled out from under a pending proposal.
• An activated sphere can't be merged, and a locked (pending-merge) sphere can't be activated, checked in both contracts independently so neither path alone is sufficient to create the gap.
• Governance voting weight requires a sphere to have been activated before the current window opened, closing off same-transaction flash-loan-style vote manipulation.
• Buyback swaps are slippage-bounded. If the bound would be exceeded, the swap reverts and the ETH stays in the vault for the next attempt rather than executing at a bad price.
• LPLock accepts exactly one position, ever, from exactly the configured position manager address, and exposes no function capable of moving that position's liquidity back out, verified directly by scanning the deployed contract's ABI in its test suite rather than only asserted in prose.

Read this before anything else on this page.

Nothing on this page is financial, investment, legal, or tax advice, nor an offer, solicitation, or guarantee of any kind.

• Merging, activating, and claiming are irreversible once confirmed on-chain. There's no undo on a burn.
• The reward pool's existence depends entirely on real usage and a successful governance vote. It can sit at zero for extended periods if usage is low or quorum isn't reached.
• Every rate on this page (8% merge burn, 0.001 ETH protocol fee, 33% quorum, 70/30 split, 5% whale cap) is the current design, not an immutable constant, until the deployed contract says otherwise via the timelocked parameter process described in Contracts above.
• Smart contracts carry inherent risk: bugs, exploits, and unforeseen interactions are possible in any protocol, however carefully built.
• Address-based systems like this one's whale cap and quorum have an inherent Sybil limitation, nothing on-chain can fully prevent activity being split across many wallets to work around a percentage-based cap.
• The buyback swap is a public on-chain transaction and is subject to the same MEV / front-running risk as any DEX trade. Slippage bounds limit the damage but don't eliminate the risk.
• $ATLAS and secondary sphere prices are market-determined and can go to zero. Activation deposits are denominated in $ATLAS, not a stable value.

Short answers to the obvious questions.

Nothing, and nothing is owed. An inactive sphere costs nothing beyond the original mint and never expires or decays.

Yes, the 92% staked portion, any time, with no lockup. The 8% burned at activation is permanent.

500 spheres (5%) and 5,000,000 $ATLAS (5%), both disclosed here rather than left out of the numbers. The team's spheres mint the same way as everyone else's, mass 1, Tier 1, no discount. The $ATLAS vests linearly rather than unlocking at once. Beyond that, the team's ongoing income is the 30% side of every buyback, the same mechanism everyone else's 70% comes from.

An automatic buyback on a timer trades at whatever price happens to exist at that exact moment, with no one deciding it's actually a good time. Gating it behind quorum means it only executes when a real, weighted majority of active holders choose to, and there's no cost to waiting since the ETH doesn't expire.

That's the intent. If any parameter changes before or after deployment, this page will be updated to match, not the other way around, and the deployed, verified contract is always the final authority.

No. The LP position lives in LPLock, which has no withdrawal function of any kind, not for the team, not for anyone. The only thing anyone can ever do with it is collect the trading fees it earns, the underlying $ATLAS and ETH stay in the pool permanently.

Because merging burns one side of the trade. If an activated (staked) sphere could be burned mid-merge, its stake would be permanently stuck in the vault with no owner left to reclaim it. The contracts enforce this from both directions: an active sphere can't enter a merge proposal, and a locked sphere can't be activated.

Two things we're building next.

Both extend the core loop rather than starting a new one, and both are in active development alongside everything above.

NFT Marketplace

Most external marketplaces treat ERC-2981 royalties as optional, many don't pay them at all. A native marketplace makes Atlas's 5% royalty non-optional: a sale simply can't complete without it. Trading fees flow into the same RewardsVault split every other revenue source already uses, no new mechanism, just another input to the same pool.

The more interesting piece is a bundled buy-and-merge action: purchase someone else's sphere and merge it into your own in a single interaction, instead of buying, waiting, then separately proposing and accepting a merge. This lives entirely in the marketplace layer, not in SphereNFT itself, keeping the core merge mechanic exactly as simple as it is today.

Token Launchpad

A bonding-curve launchpad in the spirit of Atlas's own mint: no presale tiers, no team allocation carve-outs for whoever launches through it. Launch fees flow into RewardsVault the same way everything else does. Every graduating token's liquidity locks permanently through the same LPLock design already protecting $ATLAS's own pool, extending "nobody can rug the liquidity" beyond Atlas itself to anything launched through it.

Posting a bond to launch works close to how any standard launchpad works, that part isn't reinvented. What's different is what happens after: activated sphere holders can promote a launch, weighted by their activated weight, the same mechanism BuybackGovernor already uses for buybacks. Holders don't decide which projects are allowed to launch, that stays permissionless, they only decide which ones rise in visibility. Projects that pair their liquidity against $ATLAS instead of ETH get priority placement by default on top of that, a real incentive to route demand through $ATLAS rather than a requirement to.

Why these two, and why together

Sphere ownership becomes the identity and promotion layer, $ATLAS becomes the currency every new activity routes through, the marketplace makes royalties actually collectible, and the launchpad creates recurring reasons for new $ATLAS demand and new fee revenue, all of it landing back in the same RewardsVault split holders already understand.

Plain-language definitions.

Mass

A sphere's size value. Starts at 1, grows only through merging, and determines a sphere's tier and display radius.

Weight

A sphere's earning power, read from a fixed tier table rather than calculated proportionally from mass. Grows much more slowly than mass.

Tier

One of five mass bands, each with its own weight multiplier and activation cost.

Activation

Staking $ATLAS against a sphere so it can earn a share of buybacks. Reversible via deactivation.

Epoch / voting window

The one-hour daily period during which activated holders can vote. Distinct from a cycle, see below.

Cycle

The full accumulating period from one buyback to the next. May span a single window or many consecutive days' windows while yes-weight builds toward quorum. Each wallet votes once per cycle, not once per window.

Quorum

The 33% of total active weight that must vote yes, cumulatively across windows within a cycle, before a buyback executes.

Whale cap

The 5% limit on how much of a single buyback's holder-side pool any one wallet can claim, regardless of weight.

Buyback

The event where the vault's accumulated ETH swaps for $ATLAS on the open market and splits 70/30 between activated holders and the team.

LP Lock

The permanent home of the $ATLAS/WETH Uniswap V4 liquidity position. Trading fees remain collectible; the underlying liquidity itself can never be withdrawn by anyone.