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/balance/:id | A holder’s Flashy Gold balance. |
| GET /v1/history/:id | A holder’s full, hash-chained entry history. |
| 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. |
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.
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.