Converted from source DOCX

Automated text/table extraction for archival convenience. The original DOCX remains the authoritative visual source if formatting matters.

SPAWN.FARM

Robinhood Chain — Contract & Operations Specification

Current on-chain state, operational flows, and reference scaffolding for the retool + v2 build

| Scope of this document<br>This specifies the Robinhood Chain side of Spawn: what is deployed today, the operational flows around it, and the intended (not-yet-deployed) protocol you will retool and build upon.<br>It is compiled from spawn.farm's own public documentation and on-chain references gathered during the site crawl. It is a specification, plus clearly-labeled REFERENCE scaffolding — it is NOT the project's deployed source code (see Section 1). |

| --- |

| Read first — where the real source lives<br>No production source code is reproduced here because it was never available to capture. The authoritative sources are: (1) the client's own repository / Lovable export for the front-end, and (2) the VERIFIED contract source on robinhoodchain.blockscout.com for the deployed token. Pull the deployed contract from its "Contract" tab before retooling — never work from a reconstruction.<br>Any Solidity in this document is new, unaudited reference scaffolding to stand up a dev environment. It must not be deployed to mainnet without a professional audit. Real funds are at stake. |

| --- |

1. What this document is (and is not)

You asked for the contract and operations for the Robinhood Chain side specified, and for source code to stand up a temp dev site. Two honest clarifications shape what follows:

On "all the source code": The site crawl captured rendered page content, not the repository. A React app's real source cannot be recovered from rendered HTML, and the deployed token is compiled bytecode. So this document specifies and scaffolds — it does not reproduce the project's actual code.

On "the contract": The $SPAWN token is deployed and its behaviour is documented; the factory, locker, runtime escrow, keeper and challenge contracts are designed but NOT deployed on Robinhood Chain. "Retooling the original contract" therefore means the token + the surrounding operations; "building upon it" means implementing the rest of the protocol.

Everything in Sections 2–6 is drawn from spawn.farm's public documentation. Section 7 onward is reference scaffolding authored for the dev environment. Where the public docs are self-contradictory (see the site inventory doc), the contradiction is flagged rather than silently resolved.

2. Chain & venue context

Attribute	Value / note
Canonical chain (this side)	Robinhood Chain — an Arbitrum-Orbit L2 (per docs.robinhood.com). Newer site copy migrates toward "Arc"; this doc covers the Robinhood side only.
Block explorer	robinhoodchain.blockscout.com (Blockscout instance)
AMM / trading venue	Pons v2 — a Uniswap-v2-style AMM. $SPAWN trades against ETH.
Liquidity model	v2-style: LP represented as ERC-20 LP tokens (locking = locking LP tokens). NOTE: the Arc design targets Uniswap v4 position NFTs — a different lock mechanism. Retooling for Robinhood should assume v2 LP-token locking.
Gas / value asset	Native ETH on the L2 (contrast: the Arc design settles in USDC).
Wallets supported	EIP-6963 injected discovery, WalletConnect, Coinbase Wallet SDK.

Key retool decision: the deployed side is Pons v2 (v2-style AMM). Any locker/fee-sweep logic must be written against v2 LP tokens, not the v4 PositionManager the Arc whitepaper assumes. Confirm the exact Pons v2 router/factory addresses with the client before building.

3. Deployed contract — $SPAWN token

The only Spawn contract deployed on Robinhood Chain today. Parameters below are as the project publicly documents them; verify each against the deployed bytecode / verified source before relying on it.

Parameter	Documented value
Contract address	0x41080c9d7908ce567efe239042c49d8159a2a3bb
Total supply	1,000,000,000 (fixed)
Decimals	18
Mint function	None — supply is permanent
Burn	burn(uint256); where unsupported, transfer to 0x…dEaD
Trading tax	1% on $SPAWN trades — documented as intended; VERIFY in deployed code
Tax destination	Accumulates, then periodically injected into $SPAWN's own liquidity pool (injected liquidity not withdrawable)
Tax injection trigger	UNDETERMINED in public docs — assume a privileged trigger until the verified code proves otherwise
Trading venue	Pons v2, ETH pair
Pool id	0x0423fcbbfb7b8d443177d6843dd2f175c5928fe7d6e93aa163ea6f2958714e29

Contradiction to resolve before retooling: the /token page states $SPAWN is "Live — contract deployed, pool trading" on Robinhood Chain at 0x41080c9d… The /docs and Arc whitepaper state no$ SPAWN is deployed, citing a different address (0xf73801d9…) on Arc. Establish which is the true canonical token for this side before any retool — the answer determines what you are actually modifying.

4. Key on-chain addresses & constants

Compiled from the Token and Treasury pages. Treat as a starting registry; confirm all against the explorer.

Role	Address / value
$SPAWN token	0x41080c9d7908ce567efe239042c49d8159a2a3bb
Treasury Safe (multisig)	0x5625F1B20D473DEE8cC589F0663DeDF16AbeeA0E
Deployer / buyback executor	0x172211c83F6B2C6a1BCBE6EB78c5a200C498602c
Burn sink	0x000000000000000000000000000000000000dEaD
Launch-gate burn amount	100,000 $SPAWN (spent, non-refundable)
Protocol fee share	15% (fixed)
Runtime fee share	40%–80% (creator-set at launch)
Creator fee share	0%–40% (creator-set; three shares must total 100%)

5. Operations (current, off-chain-assisted)

Because the factory/locker are not deployed, the live flows are the token itself plus server-assisted operations. These are the processes to preserve or replace during the retool.

5.1 Interim launch registry (burn-to-register)

Until the factory deploys, launching an organism is a burn plus an off-chain registry insert:

Creator burns 100,000 $SPAWN (burn() or transfer to 0x…dEaD) — one on-chain transaction.
Creator signs, free (no gas), a message over: "Spawn launch\nburn: {tx}\nprovenance: {hash}\nchain: {id}".
Server verifies the burn receipt: the Transfer log originates from the $SPAWN contract, carries >= the required amount to a burn destination, and the signer equals the log's from.
Server inserts the organism into Spawn's database registry, where burn_tx_hash is unique (one burn -> one organism).

Burned launches are documented as "migrated first" when the factory deploys. The registry is an application database, not a contract — a point v2 should make explicit to users.

5.2 Treasury & buybacks

A buyback is defined narrowly: a deployer-sent transaction spending native currency that returns $SPAWN to the deployer wallet. Inbound transfers the deployer did not pay for are NOT buybacks.

Buybacks are then routed into the Treasury Safe in separate routing transactions.

Burns tracked: transfers to 0x…dEaD and burn() calls (emitted as transfers to the zero address). Launch-gate burns are labelled with the organism they created.

The Treasury page reads all of this live from Robinhood Chain; every figure is verifiable transaction-by-transaction on the explorer.

Operational note for v2: The Treasury page currently renders entirely client-side (all figures show "loading…" in server HTML). For the dev site and v2, plan a server-side read layer (indexer or cached RPC reads) so treasury data is present at first paint and indexable.

6. Intended protocol (design target — not deployed)

These contracts are specified in the whitepaper but not deployed on Robinhood Chain. They are the "build upon it" scope.

6.1 Factory

A single launch transaction: deploy token (fixed supply, no mint) -> create Pons v2 pool -> deposit initial liquidity -> call locker.lock(). Fully atomic — if any step reverts, the whole launch reverts. No window exists in which a pool is unlocked.

6.2 Locker (no-withdraw liquidity lock)

The central trust guarantee. Exposes only these; implements none of the withdrawal/admin surface.

Exposed	NOT implemented
lock(token, amount) — factory-only, once	withdraw / unlock / release (any form)
collectFees(recipient) — routes fees to escrow + split	owner / admin / setOwner
positionOf(token) — read-only view	upgradeTo / proxy delegatecall
	selfdestruct

No owner, no admin role, not behind a proxy; deployed bytecode is final. Collecting fees never touches principal; fee destinations are fixed at deploy.

6.3 Runtime escrow & fee split

Trading fees split by the locker: runtime share -> escrow E; creator share -> claimable; protocol share fixed at 15%.

Runtime share is taken from the QUOTE side only, so funding the model never sells the organism's own token.

Runtime economics:

ticks_remaining = floor(E / c)
dE/dt          = phi * V(t) - c * r
V*             = c * r / phi
pause  when  E < (c + c_k)
resume when  E >= h * (c + c_k)

6.4 Keeper / tick & challenge (proposed)

tick(organismId, H_t): permissionless keeper call once the trigger condition holds; escrow pays c to runtime and c_k to the keeper.

Challenge protocol: optimistic checkpoints, bisection dispute to a single tick, bond + slash, falsification bounty paid from the protocol share. Proposed — lowest priority for the retool.

6.5 Protocol invariants (acceptance criteria)

I1  supply(t) = supply(0)
I2  locked(t) >= locked(0)
I3  one burn_tx -> at most one organism
I4  provenance_hash(t) = provenance_hash(0)
I5  c and phi fixed at launch
I6  E(t) >= 0
I7  paused => state + hash chain retained
I8  H_t = SHA-256(H_{t-1} || serialise(s_t) || tau_t)

7. Reference scaffolding for the dev environment

New, unaudited reference code — a starting skeleton to stand up a temp dev site and iterate, NOT the deployed source and NOT production-ready. Replace the token reference with the VERIFIED deployed source once you pull it from the explorer.

7.1 Repo layout (suggested)

spawn-dev/
  contracts/
    src/
      SpawnToken.sol
      interfaces/
        ILiquidityLocker.sol
        ISpawnFactory.sol
        IRuntimeEscrow.sol
    test/
  web/
  indexer/
  README.md

7.2 Reference token (skeleton — replace with verified source)

A minimal ERC-20 with fixed supply, burn, and a 1% trade-tax hook, matching the documented behaviour. Illustrative only.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.24;

import {ERC20} from "@openzeppelin/contracts/token/ERC20/ERC20.sol";
import {ERC20Burnable} from "@openzeppelin/contracts/token/ERC20/extensions/ERC20Burnable.sol";

contract SpawnToken is ERC20, ERC20Burnable {
    uint256 public constant MAX_SUPPLY = 1_000_000_000e18;
    uint16 public constant TRADE_TAX_BPS = 100;

    address public immutable pair;
    address public taxVault;

    constructor(address _pair, address _taxVault) ERC20("Spawn", "SPAWN") {
        pair = _pair;
        taxVault = _taxVault;
        _mint(msg.sender, MAX_SUPPLY);
    }

    function _update(address from, address to, uint256 value) internal override {
        bool isTrade = (from == pair || to == pair);
        if (isTrade && from != address(0) && to != address(0)) {
            uint256 tax = (value * TRADE_TAX_BPS) / 10_000;
            if (tax > 0) {
                super._update(from, taxVault, tax);
                value -= tax;
            }
        }
        super._update(from, to, value);
    }
}

Warning: this is a teaching skeleton — no injection trigger, no reentrancy hardening, no fee-on-transfer edge cases handled. Do not ship it.

7.3 Locker interface

interface ILiquidityLocker {
    function lock(address lpToken, uint256 amount) external;
    function collectFees(address recipient) external;
    function positionOf(address token) external view returns (address lpToken, uint256 amount);
}

7.4 Factory & escrow interfaces

interface ISpawnFactory {
    struct LaunchParams {
        string name;
        string ticker;
        uint256 supply;
        bytes32 provenanceHash;
        uint16 runtimeShareBps;
        uint16 creatorShareBps;
        uint256 costPerTick;
    }
    function launch(LaunchParams calldata p) external returns (address token, address pool);
}

interface IRuntimeEscrow {
    function balanceOf(address organism) external view returns (uint256 E);
    function ticksRemaining(address organism) external view returns (uint256);
    function topUp(address organism) external payable;
    function tick(address organism, bytes32 checkpointHash) external;
}

7.5 Front-end dev site

For the temp dev site, the fastest honest path is a fresh scaffold that reproduces the crawled page structure — not a recovered copy. Recommended baseline:

Next.js App Router or Vite + React
TypeScript
Tailwind
wagmi + viem
Robinhood Chain network config
routes stubbed to the page map

8. Open questions to close before the retool

Which token is canonical for this side — Robinhood 0x41080c9d… or Arc 0xf73801d9…?
Is deployed $SPAWN verified on Robinhood Blockscout?
Exact Pons v2 router/factory addresses.
Real tax-injection trigger.
Robinhood, Arc, or dual-chain?
Front-end repo/Lovable export available, or rebuild from scratch?

9. Engineering & risk caveats

Not advice. This document is a specification and reference scaffold. It is not audited code and not legal or financial advice.

Live money: "retooling" a live immutable contract usually means deploying a new contract and migrating; immutable bytecode cannot be patched in place.

Audit gate: locker, factory and escrow custody user funds and require professional audit before mainnet.

Brand integrity: the project premise was enforced honesty—locked liquidity, no admin, no mint. Introducing hidden admin/withdraw paths would break that promise.

Prepared by Purple AI · Robinhood Chain contract & operations spec · reference scaffolding, unaudited