{id}, {epoch}, and {wallet} identify a resource within a route. Their format, validation, and permitted use belong to the selected integration.
Authentication Model
The documented account model includes Sign In With Solana, or SIWS: a client obtains a challenge, asks a wallet to sign the sign-in message, and submits the result for verification. The design then associates subsequent requests with an authenticated session. A signing request needs to make its purpose clear to the participant. The wallet handles signing; the application uses the resulting signed message. The integration defines session creation, expiry, logout, and which operations an account may perform. Account sessions, service webhooks, and operator controls have different authority requirements. People and agents act within the permissions assigned to them.Authentication
The session-cookie and social-linking details need to match the chosen service. A session reference identifies an account context; individual actions still depend on that account’s permissions.
Arcade & Gaming
This family connects games, sessions, scores, saved state, and rankings. An experience’s rules define valid participation and how results are interpreted.
A score submission, an accepted result, and a point entry describe different steps. Points are interpreted under the experience’s terms. The VAP guide describes participation-record verification.
Cabinet control also needs the authority of the relevant creator or operator. Reading a cabinet’s state and changing its game session are separate responsibilities.
Battles
The battle design covers creating an instance, finding instances, and joining a chosen game session.
The game’s rules need to define who may join, when entries close, and how the application handles a full, ended, or interrupted battle.
Lottery
The round-based design includes round descriptions, entries, result selection, and supporting records. Each experience would define its entry rules, permitted operators, selection method, and treatment of interrupted rounds. Prize allocations, reward claims, and payout records belong to SW4P Earn. Current status: SW4P Earn is not yet publicly available. No staking, liquidity, reward, or claim programme is currently open.Round and entry records
The catalogue documents an earlier/round family alongside a /chat/round family.
Results and supporting records
Selection records and payment records need to remain connected to the same round. The application should distinguish a selected result, an allocation, and a confirmed payment.
Chat-round creation and start controls belong to the operator responsibilities described under Admin.
Leaderboards
Leaderboard records describe rankings under a specified scoring model and reporting period.
The documented period values are
day, week, month, and year. An integration needs to define the period boundaries, score sources, pagination, and visibility rules it uses.
Rewards
This family describes financial programme records and proposed claim operations within SW4P Earn. SW4P Earn extends SW4P’s economic model into source-aware allocation, claims, rewards, payout schedules, reserves, and reconciliation. Current status: SW4P Earn is not yet publicly available. No staking, liquidity, reward, or claim programme is currently open. The symbols below preserve the documented reward-interface design. A future programme would supply its eligible activity, funding source, allocation rules, recipients, claim timing, supported network and addresses, effective date, and support path.Epoch and proof records
The programme would define the proof representation and the meaning of each epoch state. A commitment record and a completed payment have distinct meanings.
Claims and recipient records
An estimate, an eligible allocation, a submitted claim, and a confirmed payout need separate records. The selected programme would explain the transitions between them, including any off-chain settlement record.
Referrals
The referral design connects a shared reference with an account and the activity attributed to it.
An integration needs to make link creation, binding rules, visibility, and duplicate handling clear. Referral activity is a reporting input; any financial referral programme would use SW4P Earn’s funding and allocation terms.
Profile & Daily Tasks
Account records can bring together participation, ranks, linked accounts, task state, and payment history.
The interface needs to identify the environment to which a preference or record belongs. Points, task completion, and payments remain distinct: a task report is checked under the experience’s rules, while a payment record describes an economic operation.
Events & SSE
Server-Sent Events, or SSE, lets a service send updates over a persistent connection.
Named examples in the design include
new_entry and chat_message. An integration needs to define subscription authority, event fields, reconnection, and how a client catches up after an interruption.
Token-burn event records
The documented event model also includes descriptions and rankings associated with token-burn events.
Event creation and activation are operator responsibilities. A burn record, participation points, and a programme reward represent different actions and records; any reward programme belongs to SW4P Earn’s model and current programme status.
Quests
Quest interfaces describe requirements, progress, scoring factors, and participation records.
Each experience defines what its points and multipliers mean. Financial reward, claim, and payout functions belong to SW4P Earn, whose reward and claim programmes are not currently open.
Social Integration
The social design covers incoming service events and material prepared for sharing.
The provider integration defines how incoming events are authenticated and associated with the relevant account or activity. Preparing a post and publishing it are separate actions with their own authority.
Clips
An upload record describes the media operation. If an experience uses uploads as a quest requirement, its quest rules determine how that activity is checked and recorded.
Eligibility & Configuration
Eligibility is specific to a product, feature, or participant role. Getting started with RNDRNTWRK requires an internet-enabled device; a particular experience may define further access conditions.
The integration needs to explain which rules and data source apply. Price information also needs an understood source and freshness; the price-cache symbol does not define a settlement quote.
Service-health checks are covered by the operator responsibilities under Admin.
Wallet & Webhooks
An identifier resolution needs the selected integration’s identity and address rules. Payment updates need the authorised sender and the payment context required to interpret the result.
Hyperlink describes the payment-request interaction. SW4P coordinates settlement and its confirmed outcome. An application uses those payment records to determine whether its payment requirement has been met.
Admin
Operational controls belong in a service’s operator reference, with explicit authority for the affected system and action. The documented responsibilities include:
These are operational design subjects. The operator documentation defines the controls, credentials, and procedures appropriate to the service.
Error Responses
The documented error model includes a human-readableerror message. An integration defines the full error envelope and any additional fields a client should retain.
A client should distinguish an input problem, an authority problem, and an interrupted operation. Retaining the relevant request and operation references helps the user follow the appropriate next step.