Saltar al contenido principal

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-05-18 to match the AS.F.MATH.M7 release (math-derived grants + tier multipliers + bandwidth).

1. The five tiers​

TierMultiplierDaily Promo Credits
Free1143 ZEQ
Starter91,290 ZEQ
Builder152,150 ZEQ
Advanced243,440 ZEQ
Architect385,446 ZEQ

The multiplier column is what the math layer reads. The amounts are derived from multiplier × base_daily_grant, where base_daily_grant = 143 ZEQ/day for the framework's federated chains. (Sovereign chains can configure their own base.) Numbers match the values written to network_snapshots.daily_promo_total_zqt every Zeqond.

2. Why these multipliers​

The tier multipliers are not arbitrary. They are taken from the golden-ratio Fibonacci sequence:

F:  1, 2, 3, 5, 8, 13, 21, 34, 55, ...
Φ-rounded series picked for tiers:
    1,  9,  15,  24,  38

Why this family:

  • Φ-derived scaling keeps each step a roughly constant ratio (≈ 1.6×) above the previous one. A user moving Free → Starter feels the same relative jump as Builder → Advanced.
  • Integer multipliers keep the math cheap (one multiply by an integer constant, no logarithms in the hot path).
  • The series sums to 1 + 9 + 15 + 24 + 38 = 87 — the framework's HulyaPulse signature 87 (from 100 × (f − 1) ≈ 0.287, i.e. 28.7… rounded to its memorable mantissa). One more alignment with the kernel constants.

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 multiplier × base_daily_grant Zeqali 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:

  1. Daily Promo Credits balance (the grant for the current Zeqond-day) — drawn down first.
  2. 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 = α × log₂(1 + 100,000) ≈ 1.29e-3 × 16.61 ≈ 0.02143
  • 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:

KnobFederated defaultSovereign range
base_daily_grant143 ZEQ0 … unlimited
Tier multipliers1 / 9 / 15 / 24 / 38any non-decreasing integer series
Grant cadenceZeqond-dayZeqond-day or Zeqond-week
Roll-over policyReset to zeroReset / 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 $9.95/month actually buy?​

At the Starter tier ($9.95/mo, multiplier = 9):

  • daily allowance: 1,290 ZEQ
  • monthly allowance: 1,290 × 30 = 38,700 ZEQ
  • list price reference: 38,700 × $0.01 = $387 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,290 / 0.001 = 1,290,000 calls/day
  • monthly: ~38.7 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 per-tier daily_promo_total network-wide. 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 Fibonacci-derived tier steps, auto-granted every Zeqond-day, spent before standing balance, and fully on the entangled state. The numbers (143 / 1,290 / 2,150 / 3,440 / 5,446) are math-derived from a single base, not hand-picked.