01
Five layers, one venue
You should be able to: Name the five layers Flashy Finance composes and say which one you ever see.
Flashy Finance is one wallet carrying Flashy Gold, a flashyID handle and staking, over rails that settle on the estate's own ledger and record to the mesh. Each of those concerns is already owned by an estate layer, and the product is the decision to make them one stack: the wallet is the interface and the only layer a holder touches; flashyID is authorisation, issuing delegated and attenuated spend grants so a property gets an allowance and never your keys; flashy-ledger is settlement, the shared book of record every property writes to; Flashy Gold is the unit, one rewards asset across every property; and the FlashyOS mesh is the record, where every settlement seals to something a stranger can verify offline.
The loop a holder experiences runs across those layers: earn, through activity on any estate property; hold, in a wallet whose keys never leave the device; grow, by locking Gold for yield paid in Gold; claim, through the redemption product that already runs. The last step is the tell. ClaimYour.Gold, the rewards funnel, is live today; the wallet and the general rail are announced and launching at flashy.financial. This course will not blur that line, because the formats it teaches exist precisely to keep it sharp.
Read it as an AAO architect rather than as a customer. Each layer is a seam you will integrate once: identity through flashyID, settlement through the ledger, the record through the mesh. Flashy Finance is the composition, not a new set of rules — and the two lessons that follow are the rules that hold while the composition is still being finished.
Source: Flashy Finance — the wallet and rail
02
Why value needs a venue before it moves
You should be able to: Explain what reward/1 refuses, and why an accrual with no venue may never be marked payable.
reward/1 is an append-only accrual log for entitlements that cannot be paid yet. It records that a person is owed a reward, on what basis, in what unit — and it records nothing about being able to pay, because nothing can. The venue a reward would settle into is Flashy Finance's shared wallet, and until that venue is declared the format's settle() throws with the reason in the message. A fragment carrying a settled entry beside venue: null is invalid. Not a warning, not a flag: invalid.
The rule in one line is the one the estate holds itself to: never ship a way to accrue ahead of the thing that pays. It is uncomfortable on purpose. A property that wants to reward signups can record the accrual today, and a stranger reading the fragment can see exactly what is owed — but nobody can claim it is payable, because payable is a derived field the format refuses to accept as input. An emitter that could write it could claim something is payable when nothing can pay it, which is the single failure the format is built to prevent.
Two more refusals travel with the document rather than living in a service, because the document is what a stranger can check. One signup accrual per identity, against a basis a reader can open — a reward for signing up is a faucet, and a faucet on a network whose asset is who-knows-whom fills it with people who know nobody; a database constraint is something somebody can drop, so this one is in the format. And no currency at any depth: a fiat figure beside a rewards balance is a redemption promise whatever the surrounding copy says. Rewards are Flashy Gold, and the format will not let them be anything else.
Source: FlashyOS — @flashyos/reward (reward/1)
03
wallet/1: one holding across books that are not one book
You should be able to: Explain why a wallet balance is derived and never asserted, and what "available: null" means.
wallet/1 is the venue reward/1 refuses to settle into — the contract behind the name the reward format's own tests cite. Its shape follows from one fact about the estate: three properties run their own ledger store, so one wallet over three books is honest only if every entry says which book it came from. An entry naming no ledger is invalid. A holding is the sum of entries across books that are not one book, and the format will not let the seam between them be hidden.
A balance is derived, never asserted. balance, available, total, payable and spendable are refused as field names at any depth — a table of balances can be edited, a log can only be appended to, and a wallet whose balance is a stored number is a wallet whose balance somebody can type. Until the venue is operational and cites an invariant a stranger can open, available reads null rather than 0. That distinction is the whole discipline of this estate in one field: zero is a measurement, null is the format declining to claim.
Two more rules shape how value will move once it can. A transfer needs both parties, dated before the event — consent afterwards is ratification, and the format will not let the two be written as the same thing. And the format is unpublished until Flashy Finance is operational, for the reason the Value and Rewards course gave: a format published for value nobody can move yet teaches every reader that the estate's formats are decorative. You can read it; you cannot yet wire against it; and that is the honest state.
Source: FlashyOS — @flashyos/wallet (wallet/1)
04
Value never moves without the holder's approval
You should be able to: Describe the draft-then-execute consent gate, what a consent is bound to, and why there is no auto-approval at any tier.
The consent promise the brand rests on is a rule in code, not a line of copy. Every value-moving action is drafted first — a redeem, a transfer, a payment — and executed only against the holder's explicit approval, bound to that exact draft and that holder. An agent may draft a payment; only the holder approves it. There is no auto-approval at any tier, for any property, for any amount. Rails enforces the binding regardless of who issued the consent: a validly signed consent for the wrong holder is still refused.
Delegation exists, and it is attenuation rather than a key. When a holder authorises a property to spend on their behalf, they issue a flashyID grant that is capped, scoped to one purpose, and revocable the instant they say so — a property gets an allowance, never the keys. Enforcement runs before any grant is honoured, because identity that nothing checks is theatre. This is the same rule the Identity course taught, applied to the one action where getting it wrong costs somebody their Gold.
Agents suggest; humans consent — the estate's doctrine, on the channel where it matters most. A wallet that could move value on an agent's say-so would be the only thing in the estate you had to take on faith. The consent gate is why Flashy Finance can keep keys on the holder's device, run no bridge of its own, and still let a property build a whole economy on top: every movement is one a person approved, bound to what they approved.
Source: Flashy Finance — Payments & Transfers, Security & Custody
05
Building on the rail as an AAO
You should be able to: Say what Flashy Rails exposes, what it refuses to own, and what an AAO should build on today.
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. The surface is small on purpose. A holder's balance and hash-chained history; earn, which issues rewards idempotently so a retried award settles once and never twice, and only with an issuer credential; redeem and transfer, each as a pure draft followed by an execute against a bound consent; and a delegated spend under an attenuated, revocable grant.
A transfer is two atomic entries — a debit and a credit that both land or neither does — so peer-to-peer movement can never leave the books unbalanced. No private key sits on the request path; on-chain signing is a separate, isolated service. When you read the endpoint table, read it as the consent gate and the ledger made callable: nothing there lets a caller move value that a holder did not approve, and nothing there lets a caller assert a balance.
So the practical guidance for an AAO is unchanged from the Value and Rewards course, and now you know why: build on Flashy Gold and the ledger, which are live, record accruals in reward/1 with the venue honestly null, and design for the rail rather than against a specification that is being kept honest by staying unpublished. When Flashy Finance is operational, the venue is declared, available stops reading null, and the accruals you recorded settle — into the wallet, with consent, exactly as the formats already say they must.
Source: Flashy Finance — Flashy Rails API
