How Trident works

Holding grants access

TRIDENT has two accepted access tokens. Hold either the Pons token on Robinhood Chain or the Solana token to qualify; holding both is not required. The app verifies your wallet signature and checks that network’s token balance at both confirmed and recent state. The default requirement is 10,000 tokens. The operator may change TRIDENT_MIN_HOLDING; the access page displays the active requirement.

There is no token registration, personal credit purchase or model-specific token. One holder key accesses every supported text model. More tokens do not create more keys or a larger wallet allowance.

Each key remains bound to the wallet and network that created it. Both networks draw from one funded provider balance and one global spending limit. Existing Pons keys remain valid.

A request, end to end

1. The gateway validates the hashed bearer key or signed browser session and current terms acceptance.
2. It verifies current holdings using the configured RPC. A failed RPC check cannot grant access.
3. It obtains current model pricing and verified OpenRouter account credits.
4. In one database transaction, it checks rate and spending limits and reserves a conservative request cost against the shared provider balance.
5. It forwards the request using the server-only provider key. The client never receives that credential.
6. It records actual provider-reported billing. Unknown billing or interrupted streaming keeps a reservation pending investigation.

Parallel app instances share one accounting lock in PostgreSQL. Duplicate request identifiers cannot charge the same request twice. Existing separately allocated legacy budgets, if any, are excluded from the capacity available to TRIDENT holders.

Which numbers mean what

The system does not promise that holding tokens has financial value or produces income. Availability depends on provider credits and infrastructure. No historical chart data or connected-wallet activity is invented.