Privacy policy

Version 2026-09-22.3 · effective 22 September 2026

This policy describes information processed by Trident Protocol's website and wallet-based API gateway. Privacy enquiries: @TridentProtocol, or the support contact published on the site. Do not send private keys, seed phrases, API keys or sensitive information in public posts.

1. Wallet access is pseudonymous

The sign-in flow does not ask for your legal name, email address, telephone number or personal profile. Public pages use project branding. Wallet addresses, public chain history and infrastructure metadata can nevertheless identify or be linked to a person. This service does not promise anonymity or provide a zero-knowledge identity or mixing service.

2. Information the application processes

• Wallet address, selected chain, signed-message challenge, nonce, expiry, whether verification succeeded, session identifier and session expiry. The verification endpoint processes your signature; the application database stores the challenge and verification state, not the submitted signature itself.
• The policy version accepted by your wallet and the time of acceptance. The signed challenge contains links to the Terms, Privacy Policy and Risk Disclosures and the memecoin acknowledgment.
• Public token metadata and holdings queried to determine access eligibility.
• API key name, prefix, cryptographic hash, creation and last-use times, and revocation status. A new secret is shown once; the application stores its hash rather than the secret.
• Request model, timestamp, wallet account, key identifier, request fingerprint, reserved and actual cost, settlement status, and provider generation identifier when returned.
• Authenticated session last-seen times used for aggregate active-wallet counts.

If historical deposit or legacy compute features have been used, their records can also contain public transaction hashes, receipt verification, balances, accounting adjustments and stored legacy response text. Those flows are not required for the current TRIDENT holder service.

3. Prompts and model responses

Requests pass through Trident's server to OpenRouter and the selected model provider. The current holder gateway does not intentionally persist prompt or response bodies in its application database. It records accounting metadata and a SHA-256 request fingerprint. A fingerprint is not a guarantee of anonymity, particularly for predictable inputs.

Providers and infrastructure may process or log content according to their own settings and policies. The service does not guarantee zero data retention by OpenRouter or a model provider. Historical personal-compute records can contain response text saved for recovery; that text may repeat prompt information. That inference endpoint is now retired.

Do not submit confidential or sensitive information unless you have assessed the relevant processing and have authority to submit it.

4. Why information is used

Information supports wallet authentication, recording policy agreement, checking holdings, issuing and revoking keys, serving requests, accounting, rate limits, abuse prevention, reconciliation, troubleshooting and applicable legal obligations. The application does not include advertising trackers or sell personal information as part of its implemented functionality.

The wallet agreement records acceptance of the Terms and acknowledgment of this notice. It is not blanket consent to unrelated advertising, publication of private content or any future use of personal information.

5. Public statistics and wallet counts

The public wallet count measures distinct chain-and-wallet accounts with an unexpired signed-in session and an authenticated heartbeat within the preceding five minutes. Signing in records an initial heartbeat. Visible signed-in pages refresh it approximately once per minute. Disconnecting removes that session; an inactive session ages out of the active count. Two tabs or sessions for the same chain-and-wallet account count once.

Public activity contains aggregate counts, timestamps and service events. It excludes wallet addresses, API secrets, prompts and responses. A separate total-signed-in count is historical and is not a claim that those wallets are currently online or that each wallet represents a unique person. The count is not a token-holder count or an audit of human users.

Provider-credit observations and aggregate costs are public while treasury publication is enabled. Public blockchain records and third-party explorer data remain public independently of this application.

6. Providers and international processing

OpenRouter and the selected upstream model provider process inference. RPC providers, including Alchemy where configured, receive blockchain queries. Vercel hosts the application; the configured PostgreSQL or Turso provider stores application records. Wallet software and optional WalletConnect/Reown handle wallet connections and pairing metadata. Remote image hosts can receive request information when images load. Legacy integrations can involve exchange-rate, IPFS or payment data providers when enabled.

These services can process information outside your country. Processing locations depend on the configured hosting/database region, routing and chosen model provider. This application does not promise Australian-only storage. Consult OpenRouter's privacy policy and the chosen providers' policies before supplying sensitive content. Information may also be disclosed where required by law or reasonably necessary to address security incidents and protect legal rights.

7. Cookies and browser storage

A functional HttpOnly session cookie authenticates your wallet for up to 24 hours. Production uses Secure and SameSite protections. Wallet software may store its own connection state; optional WalletConnect uses its own session storage. Legacy payment recovery can store pending transaction hashes locally. The application does not bundle non-essential advertising cookies.

Cookie expiry and logout end authentication; they are not promises that all underlying records and backups are immediately erased.

8. Retention

Model-price and provider-credit observations are pruned to approximately 90 days; indexed market observations to approximately 30 days when collection runs. Price-history views may show a shorter window.

There is no automatic expiry-based deletion workflow for every authentication, acceptance, key, usage, accounting or backup record. Those records can remain after a session expires or a key is revoked. Retention must be limited to what is reasonably necessary for operation, disputes, security and applicable obligations. The current implementation does not promise a fixed deletion date for all account records or deletion from independent provider systems.

9. Access, correction and privacy requests

Use the public project contact to request a private support channel for an access, correction, deletion or privacy complaint. Account ownership may be verified by a fresh wallet signature. Do not provide your private key. Depending on applicable law, records may be corrected or deleted subject to security, accounting and legal retention requirements. Public chain records and data held independently by third parties cannot be erased by this application.

Where applicable, Australian privacy concerns can be escalated to the Office of the Australian Information Commissioner. This policy does not remove statutory privacy rights or imply that all data-handling obligations are satisfied merely by publishing a notice.

10. Security and changes

The service uses signed challenges, expiring sessions, hashed API keys and server-side provider credentials. No system guarantees complete security. Report suspected compromise promptly through the project contact and revoke affected API keys. Material policy changes are dated and versioned; the connection and protected API flow require agreement to the current version.