Payments and pricing
Developer-side payments
Billing is intent-based:
- Create a payment intent with a method the operator turned on (direct Monad, x402, or future card rails).
- Confirm with either:
- Direct Monad — send funds to the shown receive guidance; confirm with your transaction hash when the UI asks.
- x402 — the API may return payment required with structured headers; the portal completes the facilitator flow for you.
Clients must handle structured payment challenges—not every error is a plain JSON message.
Treasury addresses and networks come from deployment configuration for each environment.
Pricing model
Pricing is data-driven in the operator console, not hardcoded in the portal UI:
- Categories define the base catalog (also reflected on the public landing).
- Rules encode complexity and other multipliers.
- Campaigns can run first-N or windowed discounts with counters.
- Snapshots on intents or submissions record what price applied for later audits.
Operators maintain categories, rules, campaigns, and payment-method toggles in the operator console.
Manifest generation
AI manifest assist is rate-limited and can be locked after repeated abusive input; the UI points you to Support when that happens.
Validator SIGMA plugins (SBYTE)
Separate from developer deposits: creating SIGMA-type validator plugins debits SBYTE from the validator’s game wallet to the protocol treasury after balance checks and an on-chain transfer. Other plugin families may be free in the same pricing system.
Ledger and model costs
SIGMA tracks LLM usage for protocol accounting. Live model price sync and every billing detail vary by deployment—use operator LLM usage and finance views for reconciliation.