Flashy Rails is a thin service over the estate’s append-only ledger that speaks Flashy Gold. It owns no keys and no storage rules: the ledger decides what a valid entry is, and Rails decides the product rules on top — issuance must be rule-bound, value moves only with consent, delegated spend is capped by a grant.
Endpoints
| Method · path | Does |
|---|---|
| GET /v1/health | Liveness — the service is up. |
| GET /v1/balance/:id | A holder’s Flashy Gold balance. |
| GET /v1/history/:id | A holder’s full, hash-chained entry history. |
| GET /v1/reconcile/:id | Proves the sealed chain settles to the stored balance — the record a stranger re-verifies. |
| GET /v1/migrated/:id | Whether a holder has cut over to this rail, derived from the record. |
| POST /v1/earn | Issue rewards. Rule-bound and idempotent; requires an issuer credential. |
| POST /v1/redeem/draft · /execute | Draft (pure), then move value against a holder’s consent. |
| POST /v1/transfer/draft · /execute | A transfer as two atomic entries, consent-gated. |
| POST /v1/grant/spend | Delegated spend under an attenuated, revocable grant. |
| GET /v1/openapi.json | The machine-readable contract itself (OpenAPI 3.1) — every row above, named, typed and versioned. Consume this, never the Rails source, per the estate’s contract-drift discipline. |
Consent, enforced
A redeem or transfer is drafted first and executed only against a consent bound to that exact draft and holder — verified as a flashyID-signed consent in production. Rails enforces the binding regardless of issuer; a validly-signed consent for the wrong holder is still refused.
This table is drift-tested against the real contract
The row above is this property’s own description of the rail, not the rail’s source — the rule every integrating venture is held to (consume the published GET /v1/openapi.json contract, never a direct import). test/rails-contract.test.mjs reads flashy-rails’ real route table, where a sibling checkout of it is present, and fails this page if an endpoint the rail serves is missing here, or one named here no longer exists on the rail.
Questions
Does the Rails API hold private keys?
No. Rails is off-chain custody of a balance on the shared ledger; on-chain signing is a separate, isolated service. No private key ever sits on the request path.
How are transfers kept consistent?
A transfer is two entries — a debit and a credit — that commit atomically on a transactional store, so peer-to-peer movement can never leave the books unbalanced.