{
  "contract": "course-content/1",
  "slug": "the-wallet-and-the-rail",
  "title": "The Wallet and the Rail: Flashy Finance",
  "primitive": "The settlement venue (reward/1, wallet/1, Flashy Rails)",
  "audience": "Anyone building an AAO that will earn, hold or move Flashy Gold, and anyone who wants to know what \"value never moves without you\" is actually enforced by",
  "summary": "Flashy Finance is the estate's declared wallet and financial rail — the venue that rewards accrue toward and cannot settle into until it is operational. This teaches the five layers that make it one stack, why a reward format refuses to settle with no venue, why a wallet balance is derived and never asserted, what the consent gate binds, and how an AAO builds on the rail without building against it.",
  "track": "becoming-an-aao",
  "pin": {
    "source": "@flashyos/reward + @flashyos/wallet — the accrual log and the venue it refuses to settle into",
    "state": "unverifiable"
  },
  "intro": [
    "Every property in the estate can mint a reward; only one venue can settle it. Flashy Finance is that venue, and the honest thing about it is that it is declared and launching rather than live — so the formats around it are built to refuse the claim that value can move before something can pay it.",
    "That refusal is not caution for its own sake. \"Reward people with Flashy Gold when they sign up\" is a sentence with a wallet in it, and for as long as the wallet does not exist, a system that lets the reward accrue and pay would be paying with nothing. The estate wrote that rule down twice before — enforcement before minting in flashyID, ship the truthful seam in Magician — and reward/1 and wallet/1 are what it looks like as data.",
    "Five lessons. You will finish knowing what the rail is made of, what each format refuses, what the consent gate is bound to, and what to build on today."
  ],
  "lessons": [
    {
      "n": "01",
      "title": "Five layers, one venue",
      "outcome": "Name the five layers Flashy Finance composes and say which one you ever see.",
      "body": [
        "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": {
        "label": "Flashy Finance — the wallet and rail",
        "href": "https://flashy.financial"
      }
    },
    {
      "n": "02",
      "title": "Why value needs a venue before it moves",
      "outcome": "Explain what reward/1 refuses, and why an accrual with no venue may never be marked payable.",
      "body": [
        "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": {
        "label": "FlashyOS — @flashyos/reward (reward/1)",
        "href": "https://flashyos.com/packages/reward"
      }
    },
    {
      "n": "03",
      "title": "wallet/1: one holding across books that are not one book",
      "outcome": "Explain why a wallet balance is derived and never asserted, and what \"available: null\" means.",
      "body": [
        "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": {
        "label": "FlashyOS — @flashyos/wallet (wallet/1)",
        "href": "https://flashyos.com/packages/wallet"
      }
    },
    {
      "n": "04",
      "title": "Value never moves without the holder's approval",
      "outcome": "Describe the draft-then-execute consent gate, what a consent is bound to, and why there is no auto-approval at any tier.",
      "body": [
        "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": {
        "label": "Flashy Finance — Payments & Transfers, Security & Custody",
        "href": "https://flashy.financial/security/"
      }
    },
    {
      "n": "05",
      "title": "Building on the rail as an AAO",
      "outcome": "Say what Flashy Rails exposes, what it refuses to own, and what an AAO should build on today.",
      "body": [
        "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": {
        "label": "Flashy Finance — Flashy Rails API",
        "href": "https://flashy.financial/rails/"
      }
    }
  ],
  "faqs": [
    {
      "q": "Is Flashy Finance live?",
      "a": "The rewards funnel, ClaimYour.Gold, is live today. The wallet and the general rail are announced and launching at flashy.financial, and the wallet format is unpublished until the venue is operational — which is why reward/1 accruals recorded now carry venue: null and cannot be marked payable."
    },
    {
      "q": "Can a property or an agent move my Flashy Gold without me?",
      "a": "No. Every value-moving action is drafted and executed only against your explicit approval, bound to that exact draft and holder. A property you have authorised can spend only within a capped, scoped, revocable flashyID grant you issued. There is no auto-approval at any tier."
    },
    {
      "q": "Why is \"available\" null rather than zero while the venue is not operational?",
      "a": "Because zero is a measurement and null is the format declining to claim. A wallet that reported 0 would be asserting a balance nothing has computed; wallet/1 refuses balance fields as input altogether and derives them from entries that each name their ledger."
    }
  ],
  "related": [
    {
      "label": "Value and Rewards",
      "href": "/academy/curriculum/value-and-rewards"
    },
    {
      "label": "Identity with flashyID",
      "href": "/academy/curriculum/identity-with-flashyid"
    },
    {
      "label": "Holding a Position",
      "href": "/academy/curriculum/holding-a-position"
    },
    {
      "label": "Flashy Finance",
      "href": "https://flashy.financial"
    }
  ]
}