Security and trust boundaries

Wallet and session security

Sign-in challenges bind a wallet address, chain, origin, random nonce and expiry. EVM signatures and Solana Ed25519 signatures are checked server-side. Nonces are consumed atomically. Sessions last 24 hours and use an HttpOnly, same-site cookie, with Secure enabled on HTTPS origins.

Cookie-authenticated mutations require the configured exact origin. The application never asks for a wallet recovery phrase or signing private key. Changing browser wallets does not transfer ownership of an existing preparation.

Transaction integrity

EVM receipts are checked against sender, destination, value, full calldata, successful execution, confirmation depth and block timing. Solana submissions must match the exact prepared message and valid signatures. Receipts cannot be credited twice across payment preparations.

RPC operators remain trusted data sources. Confirmation depth reduces ordinary reorganization risk; it is not a cryptographic finality proof. Inspect chain-specific assumptions and RPC reliability before production.

API and budget security

Random API secrets are hashed at rest and revoked server-side. Wallet eligibility, terms acceptance, rate limits, shared provider capacity and community allowances are checked before inference. PostgreSQL transaction-scoped advisory locks, or libSQL write transactions, serialize accounting reservations against the shared database. Local development uses the same SQL schema with a file database.

API keys are credentials, not bearer ownership of transferable credit. They remain tied to their issuer wallet and community. A stolen key can consume that wallet’s allowance until revoked; do not embed one in a public browser bundle.

Known limitations

There is no formal audit, proof of solvency, automated fee sweep, person-level anti-Sybil system, complete regulatory compliance platform or guarantee against malicious tokens. Registration does not verify issuer ownership. A token may change balances or behavior, implement controls or lose market liquidity.

An RPC outage can stop eligibility and receipt checks. Provider latency or cancellation may leave reservations held. A compromised operator can change server code, treasury configuration and accounting. The native funding treasury is operator-controlled; describing wallet signing as non-custodial does not make contributed funds trustless.

Operational response

Pause a community when a credential, provider balance or accounting incident is suspected. Revoke affected API keys, rotate provider credentials outside the app and inspect audit records. Reconcile unknown generations before releasing reservations. Publish a proportionate incident notice when appropriate and preserve legal notification duties.

Do not expose local administrative scripts over public HTTP. Restrict database and backup access, run a supported Node version, update dependencies and perform deployment-specific security review. Disable request-body logging at reverse proxies and observability vendors if you intend to preserve the gateway’s no-content-storage design.

Report an issue

Use the operator’s published support channel with request IDs and transaction hashes. Never send API secrets, recovery phrases or private keys. Until that channel is configured, this package is a local development build.