Legacy personal compute

This page describes the optional legacy personal-balance service. The primary TRIDENT holder API is documented in API access and Funding. It is disabled by default. Direct Uniswap-created tokens are excluded from the legacy token-sale adapter.

Paying directly

Sign in on Solana to pay SOL, or on Robinhood Chain to pay ETH. The receiving wallet must be configured by the operator and is shown before signing. Never send funds to an address copied from an unofficial message.

Quotes use a fresh Coinbase ETH/USD or SOL/USD spot reference and disclose the configured FX buffer. Native assets are received by the operator; the quote produces an application service balance denominated in USD. This is not a transfer of OpenRouter-owned credits.

Paying with a launched token

Only confirmed tokens in this application's registry are eligible. Token amounts use the decimals fixed by the supported launch implementations: 6 for Pump launches, 18 for Pons launches.

Solana

Before graduation the official Pump SDK builds the sale; after graduation the official PumpSwap SDK uses the canonical pool. A minimum SOL payment to the treasury and an identifying memo are included in the same transaction. If the sale cannot satisfy its minimum or the transfer fails, the whole transaction fails. Any excess sale proceeds stay in the user's wallet.

Pons

Before graduation, an exact-amount approval is followed by a curve sale paying ETH directly to the treasury. Actual receipt event proceeds are credited. After graduation, an exact ERC-20 approval and a five-minute Permit2 router allowance precede a Uniswap V4 sale. The router sends the quoted minimum to the treasury and excess to the user's wallet. During the intermediate graduation phase, redemption waits for pool creation.

Approvals are separate transactions on EVM. If the final swap fails or is cancelled, a prior approval may remain. The interface never asks for an unlimited token allowance. Users can revoke remaining allowances with their wallet or a trusted allowance tool.

Confirmation and replay protection

The backend checks the successful receipt against the full prepared transaction. It requires the expected wallet, network, recipient, value, and calldata or Solana serialized message. A (chain, transaction hash) unique constraint prevents one payment from funding multiple accounts or preparations. Credit and receipt insertion happen in one database transaction.

A quote is valid for five minutes at mining time. Confirmation may occur later. Native exchange rates can move during that window; the operator carries this risk and should keep the window and payment caps conservative.

Using a balance

The playground currently supports non-streaming text prompts, with no tool execution or file uploads. It obtains a fresh model price, conservatively estimates an upper bound, reserves service credit atomically, and sends a capped request to OpenRouter. Actual reported usage determines the charge plus the disclosed markup. Unused reservation credit returns to the account.

Model provider routing is constrained by the quoted input/output price ceiling. Context and output limits, a per-request USD cap, request rate limits, and a global daily compute budget also apply. The operator absorbs any verified provider charge above the user reservation; it must monitor those exceptions.

Ambiguous provider failures

A timeout may happen after a provider accepts a request. Automatically refunding every timeout would allow unpaid compute. The system therefore holds uncertain reservations for reconciliation. Known provider rejection responses release the reservation. Missing cost information also requires reconciliation. Account history shows these requests.

Operators must promptly reconcile held reservations against OpenRouter's generation records. A restart does not automatically release pending reservations. The reconciliation CLI is described in the operations guide.

Funding and service availability

The operator must maintain sufficient OpenRouter funds, monitor outstanding customer balances, and pause new payments when service capacity is insufficient. Native cryptocurrency balances are not equivalent to funded provider capacity. The platform cannot promise future provider availability or an immutable tariff.

Unused balance handling, corrections, and statutory remedies are governed by the Terms and applicable law. Contact the configured support channel with a transaction hash and request ID; never send your private keys.