Title
[BFT-A][R4] Rework genesis to initialize zero-state CBE curve economics
Category
Authoritative Inputs
CBE Bonding Curve — Rust Implementation Specification sections 2 and 3
- Team decision:
GRAD_THRESHOLD = 2_745_966 * SCALE
- Team decision: band storage uses
p_start, not signed intercept b
Problem
The current issue assumes genesis must initialize a broader native economics stack. The new docs narrow this to the curve protocol and its immutable band/config state.
Current Behavior
Genesis/runtime still rely on legacy CBE bootstrapping patterns instead of initializing the documented curve state directly.
Required Behavior
Genesis must initialize the curve protocol with:
s_c = 0
reserve_balance = 0
treasury_balance = 0
graduated = false
sell_enabled = false
- immutable band table loaded at genesis/config
- band 0
p_start configured explicitly
- later band
p_start values derived by continuity at initialization
- curve constants (
SCALE, RHO, ALPHA, P0_GENESIS, S_MAX, fee constants)
GRAD_THRESHOLD = 2_745_966 * SCALE
This issue is not about zero-state s_sov or approved-asset/oracle bootstrapping.
Safety Impact
If genesis loads the wrong state/config shape, every later curve transaction runs against the wrong economics model.
Proposed Fix
Extend genesis config and initialization so the documented curve state and immutable configuration become the authoritative starting point.
Dependencies
Acceptance Criteria
Test Plan
- Identical genesis bytes produce identical curve state
- Startup validation for band/config invariants
- Continuity derivation tests for post-band-0
p_start values
- Genesis hash includes the curve economics config
Cleanup After
- Remove legacy genesis assumptions that conflict with
s_c = 0, zero balances, genesis-loaded band configuration, or signed intercept storage
Title
[BFT-A][R4] Rework genesis to initialize zero-state CBE curve economics
Category
Authoritative Inputs
CBE Bonding Curve — Rust Implementation Specificationsections 2 and 3GRAD_THRESHOLD = 2_745_966 * SCALEp_start, not signed interceptbProblem
The current issue assumes genesis must initialize a broader native economics stack. The new docs narrow this to the curve protocol and its immutable band/config state.
Current Behavior
Genesis/runtime still rely on legacy CBE bootstrapping patterns instead of initializing the documented curve state directly.
Required Behavior
Genesis must initialize the curve protocol with:
s_c = 0reserve_balance = 0treasury_balance = 0graduated = falsesell_enabled = falsep_startconfigured explicitlyp_startvalues derived by continuity at initializationSCALE,RHO,ALPHA,P0_GENESIS,S_MAX, fee constants)GRAD_THRESHOLD = 2_745_966 * SCALEThis issue is not about zero-state
s_sovor approved-asset/oracle bootstrapping.Safety Impact
If genesis loads the wrong state/config shape, every later curve transaction runs against the wrong economics model.
Proposed Fix
Extend genesis config and initialization so the documented curve state and immutable configuration become the authoritative starting point.
Dependencies
Acceptance Criteria
p_startis config-driven and later bandp_startvalues are derived by continuity at initializationsell_enabledis initialized tofalseGRAD_THRESHOLDis wired as2_745_966 * SCALETest Plan
p_startvaluesCleanup After
s_c = 0, zero balances, genesis-loaded band configuration, or signed intercept storage