On-chain architecture: one wallet per job

Status, 2026-10-09: moved from pump.fun to Orca. Server signing is off in production until the keys below are set on Railway (see "Switching it on"); Orca launches stay closed until then.

What autoneco does (from autoneco.xyz/docs)

autoneco separates money by job and publishes every wallet:

Fee flows: an agent-launched coin pays 90% of its creator rewards into the agent's wallet and 10% to buyback and burn. Every claim is measured from its own transaction, and every money movement is published with a Solscan link.

The VectorPad version, on Orca

Since 2026-10-09 VectorPad launches on Orca (agentapad's design, ported; see launch-pipeline.md). Every coin's whole fixed supply sits in its own Whirlpool as one position locked with Orca's permanent lock, held by the keeper. Trading fees accrue to that position; the keeper collects and pays them out.

The pool's fee is the tier the dev picked at launch: 0.30%, 0.65%, 1% or 2%, fixed or adaptive (adaptive adds a surcharge while the price swings hard, capped by Orca at 10%). Neither the dev nor VectorPad can change it after launch; only Orca's config fee authority can adjust pool fee rates. Of what the position earns (after Orca's protocol share), paid in SOL (from buys) and in the coin (from sells):

VectorPad 20%  ·  the dev's 80%, directed by the dev, any time:
                   their wallet  ·  the coin's agent wallet  ·  buyback & burn      (default 70 / 10 / 0 of all fees)

Environment: MIRRORPAD_SPLIT_DEV_BPS (8000), _AGENT_BPS (0, a fixed agent share on top), _TREASURY_BPS (2000), must total 10000; MIRRORPAD_DEFAULT_FEE_MIX (8750,1250,0: wallet, agent, burn as basis points of the dev's share); MIRRORPAD_FEE_TIERS (64,96,128,256,1025,1031,1032,1033), MIRRORPAD_DEFAULT_FEE_TIER (256). The dev sets the mix at launch and changes it with POST /tokens/{mint}/fee-mix (creator only); it applies from the next payout.

Buyback & burn: the keeper buys the coin from its own pool with that SOL (orca-buyback: an exact-output swap for the fresh quote less slippage, paying at most that SOL; the unspent rest is carried to the next round) and burns what it bought plus that coin share, in one transaction. Below 0.001 SOL it waits for a bigger round. Every burn is a buyback_burn ledger row with its transaction.

Money flows

trade in the coin's Whirlpool ──► fees accrue to the locked position (2% per trade, Orca keeps its protocol share)
                                     │  keeper: orca-collect (when uncollected fees ≥ 0.002 SOL), measured from the tx
                                     ▼
                                  keeper ── orca-pay ─────► dev wallet (from the coin's frozen metadata) ┐
                                     │               └──────► agent wallet                                ├ the dev's 80%,
                                     │── orca-buyback ──► buy the coin from its pool, burn it             ┘ in the dev's mix
                                     └─ keeps 20% ──► native-buyback: buys VectorPad's own token on Orca, burns it
                                                      (once MIRRORPAD_NATIVE_MINT is set; docs/native-token.md), then
                                                      ops wallet, swept above a 0.05 SOL reserve (never what it owes)
dev ──deposit──► agent wallet      (verified from the transaction, recorded as principal)

What VectorPad earns (read from mainnet, 2026-10-11)

Orca's protocol share is 13% of every pool fee (defaultProtocolFeeRate 1300 on the main config; orca-tiers prints it). VectorPad's 20% is of the 87% that reaches the locked position, so for every 1,000 SOL traded in a coin's pool:

Rule of thumb at the default tier: VectorPad earns 0.348% of a coin's volume. Adaptive tiers charge more while the price swings (up to Orca's 10% cap), so a volatile first hour can pay up to five times the table.

On the Meteora rail (every launch but VectorPad's own token, from 2026-10-11): the curve and the DAMM v2 pool it graduates into charge the fee the dev picked at launch. Meteora keeps 20% of it, and VectorPad's 20% is of the rest, so VectorPad earns fee × 0.8 × 0.2 of volume, all of it in SOL (DBC and DAMM v2 collect fees in the quote token), none of it arriving as the coin; the dev's 80% is fee × 0.8 × 0.8.

Orca's tiers top out at 2% fixed (plus the adaptive surcharge), so higher fixed fees exist only on the Meteora rail.

Four things that shape the real number:

• Half of it arrives as the coin, not SOL. Orca charges the fee on the token going in: buys pay in SOL, sells pay in the coin. The keeper pays the dev's and agent's coin shares out and keeps VectorPad's coin share in its own token accounts; nothing sells it. Count the SOL side (buys) as the cash income.
• Other LPs dilute it. Anyone can add liquidity to a Whirlpool; fees go pro rata to in-range liquidity, and a concentrated position near the price earns more per SOL than the keeper's full-range one.
• Nothing is earned at launch. The dev's ~0.038 SOL goes to rent on the chain, not to VectorPad; the first buy pays the pool fee like any trade. The keeper's own running costs (tick arrays, payee accounts, finishing launches) come out of its float. VectorPad takes no cut of the agents' hunting trades or their LP desks.
• The native token's buybacks spend this income (its own pool's share excepted). At MIRRORPAD_NATIVE_BUYBACK_BPS=10000 all of VectorPad's SOL income buys the token back and nothing replenishes the keeper's float or pays for inference; a lower share (8000 leaves 20% of the income) keeps ops funded from fees (native-token.md).

The keeper's books (gateway/mirrorpad_gateway/orca.py)

• A collect is a round (fee_rounds), recorded from the collect transaction's measured amounts, idempotent on its signature. collecting (sent, not yet measured) → collected → paying → paid.
• Paying claims the round first (collected → paying, one compare-and-set), so two passes can never pay one round. A payout whose outcome is unknown stays paying with its signature and is settled from the chain; one that failed, or that cannot land any more, goes back to collected and is paid again.
• An empty wallet cannot receive SOL below the rent-exempt minimum, so a small share for one waits (carried per coin) and goes out with a later round.
• The sweep subtracts everything the keeper owes (unpaid dev and agent shares, carried amounts) before moving VectorPad's share to ops.
• Every payout is a fee_share ledger row (role dev / agent / treasury) with its signature; coin amounts in detail.

Rules

• The server signs nothing unless MIRRORPAD_ONCHAIN_SIGNING=true, and on mainnet only with MIRRORPAD_ALLOW_MAINNET_SIGNING=true too.
• Launches are open only when the keeper key, signing, the keystore (agent wallets) and the chain worker are all there (GET /launch/config).
• A launch is recorded only if the chain shows a coin with a fixed 1B supply, no mint or freeze authority, frozen metadata naming the signed-in wallet, and its whole supply locked in its own pool across the curve's positions, all held by the keeper (launch-pipeline.md, "The dynamic bonding curve").
• Agent-wallet secrets are sealed with XSalsa20-Poly1305 under MIRRORPAD_KEYSTORE_KEY. On mainnet the gateway refuses to create agent wallets without that key in the environment. The key must be backed up; losing it loses every agent wallet.
• The keeper key is the most sensitive secret: it holds every position (whose fees it collects) and the fees between rounds. It cannot withdraw any liquidity, and it cannot redirect the dev share (the payee is frozen in the metadata).
• Deposits are never trusted: the dev submits a signature, the gateway reads the transaction and records only the SOL it actually moved from that wallet to that agent wallet.
• Withdrawals go only to the coin's creator wallet, are serialized per coin, and always leave the account empty or rent-exempt.
• Only keeper commands of the chain worker get the keeper secret; nothing else (agents, the trade builder) ever sees it.

Coins launched on pump.fun before the move keep their pump.fun fee-sharing path (distribute crank), unchanged.

Security model (after the 2026-10-08 review)

• Who is a coin's creator is decided by the chain, never by a request. Registering a pump.fun coin needs a wallet session whose wallet equals the coin's on-chain creator (read from its bonding curve, or from its fee-sharing config's admin once a split exists). Creator, source and network are written once and never overwritten. Simulated coins take their creator from the session only.
• Agents cannot reach keys. Every mirror-agent gets an allowlisted environment (no MIRRORPAD_*), and in the container runs as the unprivileged mirroragent user, so its shell cannot read the gateway's environment, the registry or any key file. The chain worker gets only the RPC URL, plus the treasury secret for distribute alone.
• No double payments. Every outgoing transfer is signed, recorded as pending with its signature, then sent. Pending rows count as paid until the chain settles them; only a transaction that provably never landed is marked failed. One withdrawal per coin is in flight at a time.
• Earnings release at most 5% of the earnings per 24h (not of the balance, so a deposit cannot unlock them).
• Network guard. Signing needs MIRRORPAD_ONCHAIN_SIGNING=true, a test network or the explicit mainnet switch, and the RPC's genesis hash must match the configured network. Any spelling other than devnet/testnet/localnet is treated as mainnet. On mainnet the dev key file is never used: MIRRORPAD_KEYSTORE_KEY is required.
• Errors never carry the RPC URL (it can hold an API key); sign-in nonces are per request, capped, and validated.
• Fee splits are verified from chain and only coins whose split includes the agent wallet and the treasury's full share are cranked. Cranks that land but cannot be measured are re-measured later; payouts only count sharing-config shareholders.

Tests: gateway/tests/test_onchain.py and gateway/tests/test_security.py. Devnet end-to-end: gateway/scripts/devnet_e2e.py.

The Meteora rail

Coins launched on Meteora's bonding curve (docs/launch-pipeline.md, "Launching on Meteora's bonding curve") use the same wallets and books: the keeper is the partner config's fee claimer and the owner of the migrated pool's permanently locked position; it collects fees in SOL (dbc-collect) and pays the dev's and the agent's shares (dbc-pay) through the same fee_rounds, carries and ledger rows as an Orca coin. Meteora's protocol fee is 20% of every trading fee, taken before the keeper sees anything; the keeper's commands that sign are dbc-config --create, dbc-collect, dbc-pay and dbc-migrate (in KEEPER_COMMANDS). Variables: MIRRORPAD_LAUNCH_VENUES (default meteora), MIRRORPAD_DBC_CONFIG (optional; kv keeps the configs the keeper made), MIRRORPAD_NATIVE_QUOTE_MINT (ORCA on mainnet: what VectorPad's own token prices in; its fees and payouts are then in ORCA and its ledger rows carry detail.quote).

Tests

• gateway/tests/test_orca.py: pool maths, launch guards, the keeper's books (split, carry, crash recovery, sweep).
• chain/e2e-orca.ts: the chain worker against a local validator with Orca's program (bun localnet.ts first).
• chain/e2e-gateway.ts: the real gateway on that validator: launch as the browser does it, trades, the keeper paying 80 / 10 / 10 across rounds, a cut-short launch finished by the keeper, refusals, and VectorPad's own token launched through the gateway and bought back with VectorPad's 20% (native-token.md).

Mainnet

Then set MIRRORPAD_NETWORK=mainnet, a paid MIRRORPAD_RPC_URL, MIRRORPAD_ALLOW_MAINNET_SIGNING=true, and on Vercel NEXT_PUBLIC_SOLANA_CLUSTER=mainnet-beta and NEXT_PUBLIC_RPC_URL. Never reuse the devnet file.

What does not port to pump.fun

• Agents-only trading. autoneco's transfer-hook program needs control of the token mint. pump.fun creates the mint, so we cannot attach a hook.
• A platform token. VectorPad's own token launches through the launchpad like any coin; VectorPad's 20% buys it back from its own pool and burns it (native-token.md). Hold-to-create and drops to holders are not built.
• Agent trading. VectorPad's agents do not trade; agent wallets would make that possible later, and it is the highest-risk addition of all.

The money in ORCA

Every coin pairs with ORCA (MIRRORPAD_DEFAULT_QUOTE, "orca" wherever the ORCA mint is configured), so fees, the 80/20 split and VectorPad's share all move in ORCA; the first five coins stay in SOL. What the keeper holds of each quote token beyond what it owes others (carries, per token) and what queued buybacks hold back is swept to the ops cold wallet's associated account every treasury pass (worker command token-sweep, floor MIRRORPAD_SWEEP_MIN_QUOTE, default 1 unit), after the SOL sweep. The ledger keeps tokens apart: rows in another quote carry detail.quote, totals are keyed fee_share_treasury_orca, sweep_orca and so on in raw units, and the Proof page shows them as ORCA. VectorPad's own token MIRROR (C6iAyS6afW8F1gjwPxTGQutxjvgH3MRN4Enhp7dK1pad) is named with MIRRORPAD_NATIVE_BUYBACK_BPS=0: the flagship card shows, nothing is bought back, MIRROR's own fees stay with the team, every other coin's VectorPad share accrues in ops.