Daily Promo Credits
A predictable allowance instead of a metered surprise. Daily Promo Credits are a ZEQ grant the framework auto-mints into the wallet of every machine on a paid tier, once per Zeqond-day. The credits are spent transparently on the next state-contract executions; only after they're exhausted does the wallet draw on its own balance.
Updated 2026-06-13 to match the running code (P18.1 fixed the Free
claim at 777 and the paid grants at ⌊α × multiplier × Z_per_day⌋;
getTierEntitlements() in economyConfig.ts is the source of truth).
1. The five tiers
| Tier | Multiplier | Daily Promo Credits |
|---|---|---|
| Free | 1 | 777 ZEQ |
| Starter | 9 | 1,000 ZEQ |
| Builder | 15 | 1,667 ZEQ |
| Advanced | 24 | 2,668 ZEQ |
| Architect | 38 | 4,225 ZEQ |
The multiplier column is what the math layer reads. For the paid tiers
the grant is ⌊α × multiplier × Z_per_day⌋, where α = 10⁻³ (the
kernel modulation constant) and Z_per_day = 86,400 / 0.777 ≈ 111,197
Zeqonds. So Starter = ⌊0.001 × 9 × 111,197⌋ = 1,000, Architect =
⌊0.001 × 38 × 111,197⌋ = 4,225. The Free tier is the one
exception: its daily claim is fixed at 777 — the Zeqond constant
(0.777 s → 777 credits/day) — decoupled from the α formula since
P18.1. The source of truth is getTierEntitlements() in
shared/api-core/src/lib/economyConfig.ts. The network-wide total is
written to network_snapshots.v2_daily_promo_total every Zeqond;
verify it against the per-wallet sum on
/transparency/.
2. Why these multipliers
The tier multipliers are a monotone integer series picked so each step is a roughly constant ratio above the previous one:
tier multipliers: 1, 9, 15, 24, 38
step ratios: 9.0 1.67 1.6 1.58
Why this family:
- Roughly-constant ratio scaling (≈ 1.6× per paid step above Starter) keeps the relative jump even — a user moving Builder → Advanced feels the same proportional bump as Advanced → Architect.
- Integer multipliers keep the math cheap (one multiply by an integer constant, no logarithms in the hot path).
The multipliers live in TIER_MULTIPLIER in economyConfig.ts; the
same constants feed appSlotCredit and the price discount.
3. The daily grant cycle
The grant is timed to the Zeqond-day, not the wall-clock day:
1 Zeqond = 0.777 s
1 Zeqond-day = 111,197 Zeqonds = 86,400 s = 1 wall-clock day
Once per Zeqond-day (specifically, at the same phase of the entangled state's
genesis-aligned Zeqond counter), tallyAutoMint checks whether each
machine on a paid tier has already received its grant for the
current Zeqond-day. If not, it mints the tier's grant —
⌊α × multiplier × Z_per_day⌋ for paid tiers, the fixed 777 for Free —
into the wallet, marks the grant ID against the entangled state's
promo_grants table, and emits a promo.granted audit row.
The grant is non-cumulative. Unspent credits at the next Zeqond-day boundary are absorbed back into the foundation pot via the standard keep-ratio mechanism; they do not roll over.
4. Spend order
When a state-contract execution charges a wallet, the charge is satisfied in this order:
- Daily Promo Credits balance (the grant for the current Zeqond-day) — drawn down first.
- Standing balance — drawn next, only after promo is zero.
Both draws are atomic and write separate audit rows
(promo.spent vs balance.spent) so the breakdown is forensic.
A wallet's visible balance in the UI is the sum of both pools;
the API exposes them separately via the wallet.balance_breakdown
field.
5. Spend split applies to promo too
Promo Credits are real ZEQ; they are subject to the same compute split. A 0.001 ZEQ call from a Builder-tier wallet at network-size N = 100,000:
- charge total: 0.001 ZEQ = 10¹⁵ Zeqali
f = b = α_econ × log₂(1 + 100,000) ≈ 1.29e-3 × 16.61 ≈ 0.02143(α_econ is the economy modulation parameter, distinct from the kernel α = 10⁻³ in the grant formula above)- foundation: 0.001 × 0.02143 ≈ 0.0000214 ZEQ
- burn (sovereign default, federated overrides apply): ~0.0000214 ZEQ
- owner rebate: residual (~0.000957 ZEQ) → machine owner's wallet
The fact that the source was the promo pool doesn't change the
split. From the entangled state's point of view, the only thing different is
which audit-row variant fires (promo.spent vs balance.spent).
6. Sovereign tuning
A sovereign entangled state operator can override:
| Knob | Federated default | Sovereign range |
|---|---|---|
| Free-tier daily claim | 777 ZEQ (fixed) | 0 … unlimited |
| α (paid-grant scale) | 10⁻³ | any positive scale |
| Tier multipliers | 1 / 9 / 15 / 24 / 38 | any non-decreasing integer series |
| Grant cadence | Zeqond-day | Zeqond-day or Zeqond-week |
| Roll-over policy | Reset to zero | Reset / accumulate / capped accumulate |
All four are set at chain genesis and locked by the same trigger that locks the spend split. Reaching a new policy requires an explicit migration window.
7. Worked example — what does $29/month actually buy?
At the Starter tier ($29/mo, multiplier = 9):
- daily allowance: 1,000 ZEQ
- monthly allowance: 1,000 × 30 = 30,000 ZEQ
- list price reference: 30,000 × $0.01 = $300 worth of compute at retail rates
Or, in terms of how many state-contract executions you can fire, assuming an average 0.001 ZEQ/call:
- daily: 1,000 / 0.001 = 1,000,000 calls/day
- monthly: ~30 million calls
This is why the framework can call the tier "Starter" with a straight face. It's the entry tier and it still gives you a mid-five-figures budget every month.
8. Surfaces
Three places surface the credit state:
/portal/wallet/— shows today's promo grant, today's spend against it, and the standing balance, all in one card./state/admin/(machine-owner) — the Economy tab shows the grant amount, the next-grant Zeqond, and a sparkline of the last 30 Zeqond-days of promo spend./transparency/— surfaces the network-widenetwork_snapshots.v2_daily_promo_total. Useful for verifying the sum of all wallets matches what the foundation released.
Bottom line. Daily Promo Credits turn a subscription into a
predictable compute allowance with integer-multiplier tier steps,
auto-granted every Zeqond-day, spent before standing balance, and
fully on the entangled state. The numbers (777 / 1,000 / 1,667 /
2,668 / 4,225) are math-derived — α × multiplier × Z_per_day for the
paid tiers, the fixed 777-credit claim for Free — not hand-picked.