Browse documentation
API keys and holder access
The public flow is wallet → TRIDENT holdings → API key. Users do not register tokens or create communities. The /docs/communities URL is retained for existing links; this guide describes the current holder-access product.
Wallet sign-in
Open API keys. Select a compatible EVM wallet on Pons / Robinhood Chain, or Phantom or Solflare on Solana, then sign the login message and accept the terms. The signature includes the application origin, wallet, network, nonce and expiration. It does not authorize an onchain transaction. Challenges are single-use; sessions are stored in the shared database.
TRIDENT's default threshold is 10,000 tokens. Holdings are checked before key issuance and before inference. The app uses confirmed balances rather than an indexer's displayed holdings. The same rule applies to each eligible wallet, irrespective of holdings above the minimum.
Solana TRIDENT (nEP96tGdP21uCa3Fx5QoqEE5eGycJnmPyoR9PHUpump) and the existing Pons TRIDENT token both qualify independently. The default requirement is 10,000 tokens on the wallet’s network; balances are not combined across chains. Existing Pons keys and sessions remain valid. There is no implied bridge or conversion between these tokens.
Create and revoke keys
Use Create API key, give it a name, and copy the returned secret. A wallet can have up to ten active keys. Keys are random and stored as hashes; the secret is shown once. Revocation takes effect for subsequent requests. Keys share the wallet's limits; generating more keys does not multiply access.
Signing in proves wallet ownership; it does not automatically create a key. The key panel shows the verified balance and the holding requirement. Holdings refresh every 15 seconds while the page is visible and when you return to the tab. Create API key always performs a fresh server-side holding check, so a stale page result cannot lock out a newly eligible holder. A failed key-list refresh does not block issuance. If verification fails, the error appears beside the action and you can retry. A below-threshold wallet cannot receive a key; wait for recent transfers to confirm or connect the wallet holding TRIDENT.
Authenticated browser endpoints:
| Method | Endpoint | Input |
|---|---|---|
| GET | /api/protocol | Both accepted token addresses and threshold |
| GET | /api/protocol/access | Signed session cookie |
| POST | /api/keys/create | { "name": "My app" } |
| GET | /api/keys | Signed session cookie |
| POST | /api/keys/revoke | { "id": "KEY_ID" } |
| POST | /api/protocol/run | Text model, messages and max_tokens |
No community ID or token address is required to create a key. /api/communities/register is retired.
Use an OpenAI-compatible client
Choose OpenAI-compatible / Chat Completions in your app (for example, the OpenAI-compatible connection in a chat or agent client). Set the base URL to https://www.tridentprotocol.fun/v1 and the API key to your Trident secret. The /api/v1 prefix is also supported for clients using that convention. Select a model ID from GET /v1/models.
Use your sk-tr-… Trident key. Do not use an OpenRouter provider key. Do not select Ollama or Responses mode: /api/show and /v1/responses are different API protocols, not holder-access endpoints. Browser clients can use bearer authentication with CORS; do not publish your key in a shared page or extension.
curl https://www.tridentprotocol.fun/v1/chat/completions \
-H "Authorization: Bearer YOUR_TRIDENT_KEY" \
-H "Content-Type: application/json" \
-H "Idempotency-Key: unique-request-id" \
-d '{"model":"openai/gpt-6-astra","messages":[{"role":"user","content":"Hello"}],"max_tokens":256}'
GET /v1/models lists compatible models. GET /v1/access checks holdings. GET /v1/requests/REQUEST_ID retrieves accounting status for your request. Request records do not grant access to another wallet's records.
The supported body includes model, messages, max_tokens or max_completion_tokens, temperature, top_p, penalties, stop sequences, seed, stream, stream_options, function tools, tool_choice, parallel_tool_calls, reasoning options and structured response_format. Text content arrays, developer/system instructions, assistant tool calls and tool-result messages are accepted. Developer instructions are normalized to system instructions. Client-only metadata and unrecognized options are not forwarded.
Request bodies may contain up to 1 MiB, including conversation history and tool definitions. The model context limit, conservative cost estimate and wallet allowance still apply. Tool descriptions and JSON schemas are included in the budget reservation. Function tools execute in your client, not on Trident. Built-in paid server tools, plugins, images, audio, embeddings, Responses requests and multiple completions per call are not supported.
The effective output limit is the smaller of the requested limit, 4,096 tokens and the model limit. A larger client default is capped instead of rejected. X-Trident-Max-Output-Tokens reports the effective cap. Streaming always requests usage metadata so the wallet ledger can settle correctly.
400 indicates invalid or unsupported request parameters and names the affected field. 413 means the 1 MiB body limit was exceeded; shorten history or tool definitions. Errors include request_id for support, without logging prompt bodies or API keys. A holding failure is 403 and a wallet limit is 429; changing client settings cannot bypass either.
Wallet limits
Default limits apply to each chain-and-wallet account across all its API keys and browser sessions:
| Limit | Default |
|---|---|
| Required holdings | 10,000 TRIDENT |
| Daily provider spend | $1 USD |
| Requests per UTC day | 100 |
| Request attempts per minute | 20 |
| Simultaneous in-flight requests | 2 |
| Active API keys | 10 |
The API access page displays the current configured policy and your remaining allowance. Daily limits reset at 00:00 UTC. Pending and uncertain requests continue reserving spend across midnight until settled. Failed provider attempts still count toward the request count; confirmed rejection releases reserved spend. Zero-cost models still consume request and concurrency allowance. Creating or revoking keys, reconnecting, and switching models do not reset usage. These are per-wallet limits, not proof of one person per wallet.
Holdings are read from the configured TRIDENT contract before every inference and key issuance. Robinhood reads both a confirmed block and the observed current block and uses the lower balance. Solana uses the lower of finalized and confirmed balances for the configured counterpart mint. A recent sale or transfer can therefore block a request before the older balance catches up. RPC failures deny access; indexed market data never grants access. Blockchain observations have latency and do not lock tokens while a request is running.
Operator settings are TRIDENT_WALLET_DAILY_USD, TRIDENT_WALLET_REQUESTS_PER_DAY, TRIDENT_WALLET_CONCURRENT_REQUESTS and COMMUNITY_REQUESTS_PER_MINUTE. Finite treasury credits, the global budget and provider availability can restrict use further; the limits are ceilings, not guaranteed credits or token value. Legacy token policies and the old personal-compute endpoint cannot bypass the TRIDENT gate.
Limits and errors
401 means a missing/invalid key or session. 403 includes insufficient holdings. 409 covers repeated request identifiers. 429 indicates rate or daily spending limits. 402/503 may indicate exhausted or unavailable shared credits. Unknown upstream cost is held for review; retrying with another key does not resolve the earlier reservation.
Published model prices describe treasury expenditure, not a direct charge to the holder. Shared credits and provider availability are finite.