SolidPeer
Get started

Authentication

Two authentication mechanisms, one per surface:

  • Gateway tokens for RPC traffic (bchn / fulcrum / chaingraph) — the token is part of the URL path.
  • Signed-message headers for billing-service mutations (token mint, account update, payment management) — the dashboard signs each request with your browser-held private key.

Gateway tokens

Each token is 64 hex characters minted by the billing-service when you click Mint a token. The full URL shape is:

https://solidpeer.io/<system>/<network>/<token>

The token is a bearer credential — anyone with the URL can call the gateway on your account's behalf, up to the limits you set when you minted it.

Per-token scoping

When you mint a token you can narrow its blast radius:

  • Systems: any subset of bchn / fulcrum / chaingraph.
  • Networks: any subset of mainnet / chipnet / testnet4 / regtest.
  • Method allowlist (Build tier and above): restrict to specific methods. Useful for read-only credentials.
  • Origin allowlist (Build tier and above): the gateway checks the Origin header against your list and rejects mismatches. Use this for browser-deployed credentials so a leaked token can't be used from another site.
  • RPS cap: per-token sustained rate. Bounded by the tier's RPS ceiling.
  • Burst cap: token-bucket size for short spikes. Bounded by the tier's burst ceiling.
  • CC budget (Build tier and above): one-time spend cap. Once the token has burned this many CC, it stops working — independent of the account's overall balance.
  • Expiry: optional absolute deadline.

A narrower token costs the same to mint and run; it just limits the damage if the URL leaks.

Subdomain aliases

You can hide the URL path by creating a subdomain alias:

https://<server-minted-slug>.solidpeer.io/

Aliases bind one slug to one (token, system, network) triple. Slugs are 5 random words from the EFF wordlist — unguessable in practice. Create and delete them from the dashboard.

Revocation

A token can be revoked any time from the dashboard. Revocations propagate to the gateway's request-path within one cache TTL (≤30 s). After that, calls return 401 invalid_token.

Signed-message headers

Mutating billing-service endpoints (mint / revoke / abandon-payment / account-settings) require three headers:

X-Solidpeer-Account     base58(SEC1-compressed pubkey)   == your account ID
X-Solidpeer-Timestamp   unix seconds (±300 s window)
X-Solidpeer-Signature   base64(65-byte recoverable BCH signed-message signature)

The signed payload is:

<method>\n<path>\n<timestamp>\n<sha256-hex(body)>

Hashed using the BCH-wallet signed-message convention (dsha256("\x18Bitcoin Signed Message:\n" || varint(len) || msg)). The server recovers the pubkey from the signature and compares it to the X-Solidpeer-Account header.

The dashboard handles this automatically. If you write a custom client, the algorithm is identical to the BCH "Sign Message" feature available in most BCH wallet libraries.

Replay protection

Each signature is single-use within its 300-second timestamp window. The gateway stores recently-seen signatures in Redis with a 600-second TTL; a replayed request returns 401 replay_detected.

What's public

Read-only billing-service endpoints (GET /payment-request/:id, GET /web-push/config) are unauthenticated — the resource identifier is the credential. Account-scoped reads (usage, activity, list tokens) require the signed-message headers.

Losing access

If you lose your browser keypair, the account is unrecoverable — there's no email reset or operator override. Back up the key (dashboard → Export identity) and store it somewhere you can find it.