# Fork Theta AMM

Review draft · 2026-09-16. This guide does not approve a deployment or fee programme.

## Choose a starting point

Start from the working [Gyro app](https://thetanuts.finance/dev/gyro/app.html).
A fork owns its frontend, configuration and design. It does not need to stay in
lockstep with Eiko, Gyro or Meryl. Shared services are optional.

Today, select existing supported vaults and Markets deployments and bundle them
in your UI. Here, “bundle” means a selection of markets, not a new contract that
pools customer funds. A pooled product needs a separate review.
An existing-market frontend fork does not need a new market deployment; shared
service registration is a separate step.

**New markets, assets and chains need Thetanuts approval, deployment and seeding.**
Managed seeding and sizing checks remain part of the protection against sizing
attacks. A new chain also needs RPC, keeper, indexing and operational coverage.
Do not advertise unrestricted market creation or treat an empty series as ready
for its first customer deposit. Ask Thetanuts to seed or reseed it.

This is the supported launch process, not a claim that every factory method is
permissioned. A callable contract method does not grant market-launch approval,
service coverage or a seed allocation.

## Build an existing-market fork

1. Obtain the approved frontend source release and its asset/licence terms from
   Thetanuts. A versioned public starter bundle is a release task; this guide
   does not invent a repository or download URL.
2. Copy the frontend and its local dependencies. Give the fork its own name,
   styling and configuration. Use your own RPC credentials and permitted assets.
3. Select approved chain, vault, series, router, Markets and lens identities.
   Pin the deployed generation and Markets release. Do not copy a beta's retired
   Markets addresses or infer a new deployment from a token ticker.
4. Request shared-service registration, or supply your own services. If using
   the shared API, set `INDEX_API = 'https://amm.thetanuts.finance/api'` after
   registration. Keep base/quote decimals and chain IDs explicit.
5. Set a unique site/storage identity. Do not rename the existing `gyro`,
   `eikobeta` or `merylbeta` namespaces, or borrow one for a new fork.
6. Begin with no additional partner surcharge and no advertised reward budget.
   Choose any future monetization path from the [fee proposal](fees-and-incentives.md).
7. Run the release checks below, then request the appropriate launch review.

## Request shared services

Supply Thetanuts with:

- Site name, proposed site ID, owner contact and production browser origins.
- Return URL, approved chain/vault/token identities and selected Markets release.
- Which services you want: position/IV/lending history, cards, referrals or leaderboard.
- Your fee-adapter and campaign plans, if any; no secrets or private keys.

The shared gateway checks browser origins. Its backend separately registers
site names, assets, card identities and referral destinations. A config edit
alone cannot register a fork. A successful command-line GET does not prove
browser CORS is ready. No self-service registration API is published here.

The current service supports Ethereum (1), Base (8453), HyperEVM (999) and
Robinhood Chain (4663), with registered vaults rather than every vault on those chains. Keep unavailable
or paused operations unavailable; service support is not trading readiness.

## Release checks

- Verify deployment identity, bytecode/ABI compatibility, series order and token units.
- Test deposit minimums, decimal limits and preview versus static-call amounts.
- Test withdrawal paths, buyer maximum spend, refunds, approvals and wallet/chain changes.
- Preserve actual withdrawal-value returns versus the approved passive limit order.
  Historical epoch results, wallet returns and rewards are different records.
- Keep LP fees and strike lending interest out of personal wallet earnings unless
  the wallet's share is actually calculated. Missing or stale data is not zero.
- Verify browser reads from the new origin, referral first touch and destinations.
  Public share-card creation needs explicit test approval; it writes a public record.
- Cache-bust changed scripts/styles. Test phone and desktop. Keep a rollback route.
- Treat wrappers as new financial paths: verify ownership, fee limits, receipt
  attribution, refunds and exits before enabling them.

## For an agent starting this task

Return a proposed market list, configuration diff, dependency list and test plan
before requesting live funding or transactions. Keep secrets out of generated
files. Do not promise yield, activate a fee, remove a safety gate or announce a
reward campaign because it appears in an example. Keep unresolved choices explicit.