Application and evidence preparation

Use these checklists to prepare a participant onboarding submission or an external product discussion. They organize evidence; they do not represent approval, market access, an exchange listing, or a launch decision.

Participant onboarding

Prepare the fields accepted by POST /api/v1/onboarding:

• individual or company registrant kind;
• requested BUYER, SELLER, or BROKER role;
• contact name, email, country, and organisation where applicable;
• desk display name and optional preferred desk code;
• catalogue model slugs and separately labelled external model names;
• expected monthly token-volume band;
• optional requested credit amount as an exact decimal string; and
• notes that explain the intended workflow without credentials or private provider payloads.

Mint one idempotency_key for the logical submission and reuse it for retries. An accepted onboarding submission records the request; it does not create a trading desk. A signed-in user registers a desk separately with POST /api/v1/accounts; that desk starts TRADING_DISABLED with zero credit and cannot grant its own trading authority.

Workload evidence

Prepare a concise workload profile so the requested product can be evaluated without assuming that all AI capacity is interchangeable:

1. Named models and provider endpoints of interest.
2. Prompt, Cache read, Cache write, and Output proportions for representative workloads.
3. Required service tier and any latency, throughput, availability, region, modality, or context constraints.
4. Spot need or forward tenor and window, kept separate.
5. Expected quantity range and frequency, with the unit stated explicitly.
6. Whether price discovery should use a book, RFQ, or voice workflow.
7. The source and observation date for every external price or performance figure.

Use representative ranges rather than invented precision. Never include passwords, API keys, raw prompts, or customer content in an onboarding note.

External product discussions

For a data-provider or exchange conversation, prepare a separate evidence package:

• economic use case and the risk participants are trying to measure;
• exact product and unit definition, including all four token legs;
• a versioned benchmark methodology;
• source permissions, observation history, contributor coverage, and correction records;
• comparison with external compute reference products without claiming equivalence;
• documented interest from potential buyers, providers, and liquidity participants;
• draft display, market-data, support, and incident workflows; and
• named owners for product, data, engineering, operations, and communications.

The external product owner decides whether and how to proceed. Megatron Markets documentation must not announce a third-party symbol, approval, listing, or date before that owner publishes it.

Evidence register

Track each preparation item with a small, reviewable record:

Field	What to record
Claim	The exact sentence or product statement being supported
Source	Authoritative link or dated internal evidence location
Scope	Product, model, provider, term, geography, and audience
Observed at	UTC date and time of the source observation
Owner	Person responsible for keeping it current
Limits	What the evidence does not establish
Review	Reviewer, decision, and next review date

Preparation is complete only for the claim and scope the evidence actually covers. Keep the API reference separate from planning material so conceptual work cannot be mistaken for callable behavior.