money loop

normative integration spec for the cyber network money product:

1. show balance
2. send
3. receive (with notification)
4. reward after link (multi-payee)

implements the composition of tok (PLUMB), foculus (finality), bbg (state), zheng (proofs), and cyb (sigma + sense). soft3 only.

non-normative latency narrative: latency targets.
node modes: node-modes.
light path: light-money.

1. objects

Sigma (product term) = the set of Coin balances and Card bonds held by a neuron Card. not a separate ledger type.

2. clocks (normative names)

implementations MUST use these names in APIs and UI state machines so products do not collapse distinct times into one spinner.

pure send/receive uses A (+ C on light). attribution rewards use B. see latency targets for target durations; see foculus parameters for knobs.

3. certainty grades

rules:

• R1: MUST NOT mark received or allow respend below grade 2
• R2: on light mode, grade 2 REQUIRES grade 4 (tip from fold)
• R3: MUST NOT treat unauthenticated peer JSON as balance or receive
• R4: sense NOTIFY for money MUST fire only on grade ≥ 2 credits (or grade ≥ 3 for settle-only mints)

4. operations

4.1 balance

query: balances of neuron Card $N$ at tip $T = (\texttt{BBG\_root}, h)$.

response MUST include: (token_id, amount, tip_height, proof) where proof verifies against tip root (or empty proof only if mode is full node serving itself).

acceptance:

• opening verifies against tip OR local full apply matches root
• amount conservation holds for known mints/burns (PLUMB laws)

4.2 send

input: (from_neuron, to_holder, token, amount, optional memo/particle).

steps (normative order):

1. tip ready: grade 4 on light; full/cell tip current
2. select inputs / notes owned by from_neuron with witnesses at tip
3. build Intent: one or more PLUMB pay ops (change outputs allowed)
4. prove with zheng: auth, conservation, fresh nullifiers, well-formed links
5. seal to signal; gossip via radio / foculus
6. local UI → grade 1 on network-valid $\sigma$
7. on clock A final at tip → grade 2; update sigma; optional payer sense echo

rejection: any peer MUST drop signals failing $\sigma$ or nullifier already in $N$.

4.3 receive

no separate receive transaction.

1. watch tip for finalized signals whose payee set includes local neuron (or open balance/note deltas)
2. verify credit against tip (apply or Lens)
3. on grade 2: update sigma; emit sense event TransferIn
4. new outputs become spendable for subsequent send

acceptance: receiver can respend only after grade 2.

4.4 reward after link (multi-payee)

a link Intent MAY include any of:

implementations MUST support multi-payee: one Intent / one signal MAY credit more than one holder. MUST NOT hardcode a single exclusive policy (linker-only XOR owner-only).

events:

RewardCredited { to, amount, token, reason: signal_id | link_id, clock: A|B }
TransferIn     { to, from, amount, token, reason: signal_id }
TransferOut    { from, to, amount, token, reason: signal_id }

sense:

• every payee gets NOTIFY on their credit at the grade required by the leg
• payer MAY get outbox echo (optional, product)

5. state machine (client)

          compose
             │
             ▼
         [grade 0]
             │ broadcast
             ▼
         [grade 1 pending]
             │
        ┌────┴────┐
        │ final A │
        ▼         │
    [grade 2]     │ conflict lost → pruned / failed
        │
        │ if settle mint for me
        ▼
    [grade 3] after B

tip side-channel (light):

empty disk → download acc → decide → [grade 4]
grade 4 ──fold──► grade 4' (new height)

6. event bus (cyb)

minimum events the robot MUST expose to sense/sigma:

intent particle for notifications: intent/notify (see cyb-core). payload MUST bind reason to signal/link id.

7. latency acceptance (Earth hub typical)

normative acceptance bands for product tests (not security parameters):

sparse domains and conflict races MAY exceed hub bands; UI MUST not promise a single global SLA.

8. security requirements

9. non-goals

• investmint / grid energy product surfaces
• AMM / DEX
• full tri-kernel on light client
• social recovery / multisig (compose later via PLUMB hooks)

10. conformance checklist

• balance query returns tip-bound proof or full local apply
• send produces zheng-valid signal; invalid never accepted
• receive only at grade 2; sense NOTIFY only then
• multi-payee Intent credits both linker and counterparty when both present
• light mode refuses money-grade opens without grade 4
• UI labels distinguish clock A vs B
• no dependency on non-soft3 chains

see node-modes, light-money, component-ownership, latency targets, tok, foculus protocol, structural sync.

discover all concepts