Privacy Policy

Last updated: 2026-10-26

1. Overview

Nanotoll.dev ("the Service") is designed for AI agents and automated systems. This Privacy Policy describes what data the Service collects, how it is stored, and how long it is retained.

The Service stores no names, no postal addresses and no payment card data. The categories it does store:

• The requesting IP address, in the web server's access log (section 2.6).
• An email address and the requesting IP address, only when the free trial is used (section 2.4).
• Key hashes, balances, payment and billing records (sections 2.1 to 2.3).
• A support contact address, only if you write to it.

2. Data Collected

2.1 API Keys (Hashed)

When a user registers via POST /api/v1/register, the Service generates an API key and stores only its SHA-256 hash. The plaintext key is returned to the user exactly once and is never stored. The hash cannot be reversed to recover the original key. No portion of the key is stored in plaintext.

2.2 Billing Logs

For each billable API call, the Service records:

• User ID (internal integer, not the API key)
• Number of input characters processed
• Cost in nanos (1/1,000,000 of a dollar)
• Timestamp
• Charge status (charged or refunded)

These logs are used for billing verification and accounting.

2.3 Payment Logs

For each on-chain USDC deposit, the Service records:

• Transaction hash and log index (on-chain, public data)
• Amount credited
• Chain (Base L2)
• Confirmations seen at credit time
• Status (confirmed, reorged, reorg_pending_review)
• Timestamp

2.4 Audit Log

The Service maintains an append-only, tamper-evident audit log using a SHA-256 hash chain. Each entry records:

• User ID
• Operation type (register, deposit_credit, deposit_reorg, billing_charge, billing_refund, balance_adjustment)
• Amount (signed: +credit / -debit)
• Balance after the operation
• Transaction hash (for deposit/reorg operations)
• Timestamp

The audit log cannot be modified without breaking the hash chain. It is the authoritative record of all money movements.

2.4 Trial Email and Signup IP

The free trial requires an email address: the Service sends a six-digit verification code to it and enforces one trial key per email address and per requesting IP address. For trial keys only, the Service stores the email address and the signup IP address (both in plain text) in the account row, and keeps pending verification codes salted and hashed - never the code itself. Paid accounts created through POST /api/v1/register store neither an email address nor an IP address.

2.5 Request Metadata (Ephemeral)

Each API request is logged with the following metadata, which is sent to stdout (Docker logs) and not persisted in the database:

• API key hash (first 8 hex chars only)
• HTTP method and path
• HTTP status code
• HTTP latency in milliseconds

These service logs are rotated (max 10 MB, 3 files per service) and are used for operational debugging.

2.6 Web Server Access Logs

The web server in front of the Service writes a JSON access log per hostname: client IP address, method, path, status, bytes, latency and user agent. The logs are rotated weekly, keep about four weeks locally, and are included in the nightly off-site backup replication (section 3). They are used for operations, abuse prevention and capacity planning.

3. Data Storage

All persistent data is stored in a single SQLite database file on the operator's server, inside a container-managed storage volume. The database is not encrypted at rest - it is protected by server-level access controls (strict authentication, least-privilege users, host firewall).

Backups are taken daily on the primary server and replicated nightly to an off-site backup volume in the European Economic Area, over an authenticated and encrypted transport. The nightly replication includes the database dumps and the web server access logs (section 2.6).

4. Data Retention

Billing, payment and audit records are the ledger; deleting them early would destroy the money trail. Trial identifiers (email and signup IP) are the one category kept purely for abuse prevention and can be deleted on request once the trial key has expired.

5. Data Access

5.1 User Access

Users can access their own data via:

• GET /api/v1/balance - current credit balance and funding address
• GET /api/v1/account - key tier, expiry and usage totals (requests, characters, amounts charged, refunds)
• GET /api/v1/payments - recent payment history (last N deposits)

Users cannot access other users' data. API key authentication ensures that a user can only query their own account state.

5.2 Operator Access

The operator has full access to the database via direct server access. The operator does not have access to plaintext API keys (only hashes). The audit log records all manual operator interventions as balance_adjustment entries.

5.3 Third-Party Access

No third party has access to the database. The Service does not share data with advertising networks, analytics providers, or data brokers. On-chain transaction data (deposits to funding addresses) is inherently public on the Base blockchain.

The only customer personal data processed outside our own infrastructure is the trial email address: service email (verification codes) is delivered by an email delivery provider, and inbound mail to admin@nanotoll.dev is forwarded by an email forwarding service.

6. Data Security

• API keys are hashed with SHA-256 before storage
• Database and server access is restricted to the operator (strict authentication, least-privilege users)
• A host firewall restricts inbound access to web traffic and administrative updates only
• TLS 1.2+ is enforced; HSTS is enabled with preload
• The internal dashboard is not reachable from the public internet
• No plaintext API keys are stored or logged

7. Blockchain Transparency

Deposits are made via USDC transfers on the Base L2 blockchain. These transactions are publicly visible on any Base block explorer. The funding address returned at registration is derived from the user's internal ID and is unique per user - anyone who knows a funding address can see incoming transfers to it on-chain.

8. Changes to This Policy

The operator may update this Privacy Policy at any time. Changes are effective upon publication at this URL.

9. Contact

For privacy-related questions or data access requests, contact: admin@nanotoll.dev