# Current mainnet installation The wXMR program is already installed and verified. No repeat deployment is required. - Program: `9RSfkTWckTiuCQTae86bgqZWumcLcj4fzDLxi9qNoVeM` - Frozen 75-address lookup table: `9xsTMu1qUdPs6ijzyD7Q555cgQh2BEF5PLqsbrppqs5E` - Operator and treasury: `Cx64PYoAD5a61fds7vRjJsMPxd2AHkecBu62x1FC6biQ` - Dedicated delegated keeper: `EFMjiKgbJLTz6sd9t6iff6yrEAbHZAjChX6eXTdBDmXa` - [Finalized installation verification](deployment-verification.json) - [Operator-only real cycle](canary.html) The isolated keeper is running in **dry-run mode**. Public trading remains disabled. Installation creates no launch token and acquires no wXMR. The operator needs a small wXMR token balance and must sign the real launch/trade/redemption/reward transactions before their finalized receipts can be verified. Platform-token buybacks additionally require the configured platform mint and graduated pool. The reference installation procedure below is retained for recovery and review. # XMR ROOTS · mainnet activation The adapted wXMR program is a fresh deployment. Never use the legacy HYPE program `7y3Y6hkaiRH73vr5EYXnCSYrRQyUpAwChJQ8bH3QXqL3` or its frozen lookup table for this release. ## Exact quote asset and limits wXMR mint: `WXMRyRZhsa19ety5erZhHg4N3xj3EVN92u94422teJp`, SPL Token, 12 decimals. Creator fee: 200 bps. Allocation: 30% token reserve, 20% buyback, 20% creator/holders, 15% development and 15% long-term treasury. Buybacks: at most 10,000,000,000 base units (0.01 wXMR), global 300-second cooldown, output floor and acquired-token burn in the same transaction. Ceiling: 2.88 wXMR/day; budgets and liquidity may reduce it. Operator and treasury: `Cx64PYoAD5a61fds7vRjJsMPxd2AHkecBu62x1FC6biQ`. No wallet private key should be pasted into this site or chat. ## Owner signatures 1. Open `deploy.html`, connect the operator Phantom wallet and refresh the current SOL costs. Review before signing. Automatic upload still requires Phantom approvals and stops before final deployment. 2. Continue to `setup.html` with the new program address. Initialize the immutable identities, create and populate the new lookup table, then freeze it. Download the public `live-config.json`. 3. Open `canary.html` in the same tab and import that public configuration. It checks the exact tested bytecode and all setup requirements. Ordinary visitors remain disabled. 4. Use the operator-only links to launch a small test coin in Creator reward mode. Choose a small wXMR amount in the reviewed quote, buy, sell part, collect and settle fees, burn some tokens for a nonzero reserve payout, and claim a nonzero creator reward. Each action uses real mainnet funds and requires the operator's wallet signature. 5. Record the launch, buy, sell, nonzero settlement, burn and reward signatures. Verify finalized chain evidence on the canary page, then download the public input and proof. 6. Grant the dedicated keeper delegation on `automation.html?operatorCanary=1`. Delegate only `EFMjiKgbJLTz6sd9t6iff6yrEAbHZAjChX6eXTdBDmXa` unless deliberately rotating your keeper. The staged service is isolated from the legacy HYPE service. Its public URL is `https://keeper.77.42.122.139.sslip.io/xmr/status`. Before public activation the operator must install the verified new configuration on the isolated keeper, market and registry containers, verify dry-run output, then explicitly enable submission. Its state directory, pending records and manifests must never be reused from HYPE. ## Read-only receipt checks and public activation Run from the source repository: ```sh node scripts/verify-canary.mjs /path/to/live-config.json /path/to/xmr-roots-canary-input.json /path/to/xmr-proof.json node scripts/enable-mainnet.mjs /path/to/live-config.json /path/to/xmr-roots-canary-input.json ``` The first command sends nothing. The second re-verifies the tested artifact, frozen setup, finalized real cycle, exact onchain keeper delegation and healthy enabled XMR service before writing the local public live configuration. Build and publish that exact source state afterwards. No manual `enabled: true` edit is a substitute for these checks. ## Platform buybacks Select the registered platform mint through `platform.html` using the operator wallet. This choice is permanent. Buybacks require the platform token's canonical graduated wXMR PumpSwap pool, available per-token budgets, liquidity and a funded keeper. A small launch canary does not prove graduation or a real buyback; these need separate actual receipts before claiming they have happened. ## Asset boundary Reserve redemption pays wXMR on Solana. Native XMR withdrawal is a separate operation through wxmr.io, with provider custody, processing and fees. Solana trades remain public. The bridge provider's backing claims are not an independent audit by XMR ROOTS. ## Separate mainnet test wallet The designated canary participant is `5aUJocjgeLmRec9Af1q1T8NYHwuLz4d3zy7z55QvA2uW`. It pays for the test launch and the six verification actions, and receives Creator rewards for its token. The immutable operator and treasury remain `Cx64PYoAD5a61fds7vRjJsMPxd2AHkecBu62x1FC6biQ`. The test allowlist grants no protocol administration or keeper delegation authority. Public trading remains disabled until the finalized real-cycle proof and service checks pass. The default test identity is Root Check / CHECK, with the exact square website logo and metadata describing a validation token. It is not the platform token. All mainnet token identities, instructions and program associations remain public. ## Official token created directly on Pump, paired with wXMR The selected launch plan is a direct Pump launch with creator-fee beneficiary `Cx64PYoAD5a61fds7vRjJsMPxd2AHkecBu62x1FC6biQ`. The token must use exactly `WXMRyRZhsa19ety5erZhHg4N3xj3EVN92u94422teJp` (12 decimals), Creator fees no greater than 2%, and no Mayhem, cashback or Holder Rewards mode. This official token is a buyback target, not an imported Roots vault. Its own creator fees follow Pump’s beneficiary configuration. The keeper does not gain permission to withdraw funds from that beneficiary wallet. Other coins created through XMR ROOTS retain the fixed 15/15/30/20/20 allocation and their existing reserves, reward budgets and payees. A separately tested candidate adds instruction 11: the operator may choose a canonical, initialized Pump wXMR mint as the permanent platform target without requiring that target to have a Roots coin account. Existing registration, settlement, redemption, rewards, delegation and bounded buyback instructions are unchanged. The candidate does not change the configured operator or treasury. - [Tested candidate manifest](upgrades/external-platform.json) - [Candidate SBFv3 binary](upgrades/external-platform.so) - [Platform setup](platform.html) The manifest describes preparation, not proof of a mainnet upgrade. Before an upgrade, recheck its bytecode hash, current upgrade authority and fresh SOL quote, pause the isolated keeper, and stage matching site/keeper configurations. Upgrade the existing program address with the operator’s signer. Verify exact installed bytes, existing configuration, frozen lookup table and delegation before promoting the candidate configuration and restarting the keeper. Do not initialize a new protocol or replace the existing program address. After the CA is known, verify its Pump creator-fee beneficiary separately, select the exact mint with Cx64…6biQ, then wait for curve completion and canonical wXMR PumpSwap migration. The keeper detects that pool and spends only allocated buyback budgets, with the existing 0.01 wXMR cap, global 300-second cooldown and output floor. Confirm a small positive buy-and-burn transaction on mainnet before opening public trading. Fork tests and a prepared upgrade are not that live proof.