Namibia 30 Index (NAX30)
Version 2.0 – Institutional Change Governance Standard
Effective Date: February 2026
This Change Control Policy establishes the formal framework governing modifications to the Namibia 30 Index (NAX30) smart contracts, governance configuration, oracle framework, and documentation.
The objective is to ensure:
- Predictable governance execution
- Transparent modification procedures
- Controlled upgrade discipline
- Institutional-grade change traceability
- Risk-aware protocol evolution
This policy applies to changes involving:
- Smart contract upgrades (Proxy / Implementation)
- Registry updates (weights / constituents)
- Governance parameter adjustments
- Oracle configuration changes
- Mint authorization and supply actions
- Timelock configuration modifications
- Governance signer changes
- Documentation updates affecting benchmark methodology
Frontend applications and external exchange infrastructure are outside the scope of this document unless explicitly integrated into governance processes.
Changes are categorized as:
Changes that may materially affect:
- Token logic
- Access controls
- Supply mechanics
- Governance structure
- Oracle quorum rules
- Calculation methodology
Major changes require:
- Governance proposal
- Multi-signature Safe approval
- Timelock scheduling
- Public on-chain execution
- Public documentation update
External audit review may be required prior to execution.
Changes involving:
- Registry weight updates
- Constituent modifications
- Oracle address rotation
- Governance signer rotation
Moderate changes require:
- Governance proposal
- Timelock scheduling
- Public documentation update
Audit review may be recommended depending on impact.
Changes involving:
- Non-structural documentation updates
- Clarification language
- Formatting adjustments
Minor changes do not require governance execution but must be version-controlled and documented.
All on-chain structural changes must follow:
- Proposal creation via Multi-Signature Safe
- Safe approval meeting threshold
- TimelockController scheduling
- Mandatory delay expiration
- On-chain execution
No change may bypass the timelock.
For Major Changes:
- Code freeze must be declared prior to governance scheduling.
- Relevant commit hash must be tagged.
- Upgrade bytecode must be verified.
Changes during active audit invalidate audit coverage unless re-reviewed.
All Major and Moderate changes must include:
- Updated documentation (Whitepaper, Methodology, Technical Architecture where applicable)
- Version increment
- Public repository commit
- Clear summary of change rationale
Transparency is mandatory.
For Major Changes:
- Risk Committee review is required.
- External audit may be recommended.
- Regulatory implications must be evaluated.
Change execution may be delayed if material risk is identified.
In the event of critical vulnerability:
- Emergency governance proposal may be initiated.
- Timelock delay remains enforceable unless emergency override mechanism is formally defined and disclosed.
- Public disclosure must follow execution.
No undocumented emergency powers exist.
The following constraints are structurally enforced unless modified through governance-approved upgrade:
- Maximum supply cap (10,000,000,000 NAX30)
- ERC-20 token standard compliance
- Governance-based mint control
- Registry normalization to 10,000 basis points
Historical transaction records cannot be modified.
All changes must:
- Increment version number
- Be archived in repository history
- Maintain prior versions for audit traceability
No prior documentation may be deleted without archival preservation.
Major changes may trigger:
- External audit engagement
- Targeted security review
- Remediation cycle prior to activation
Audit findings must be addressed according to EXTERNAL_AUDIT_PLAN.md.
Material changes must assess potential impact on:
- Securities classification
- MiCA or equivalent digital asset frameworks
- Benchmark regulatory positioning
- AML or compliance implications
Legal review may be obtained prior to execution.
All structural changes are:
- Publicly visible on-chain
- Publicly documented in repository
- Subject to governance auditability
Commercial considerations must not override benchmark integrity.
The following actions are prohibited without full governance pathway:
- Unilateral minting
- Direct registry manipulation
- Bypassing timelock delay
- Altering historical blockchain data
- Introducing hidden access control roles
This Change Control Policy shall be reviewed annually.
Amendments require governance approval and documentation update.
All Major Changes must include a documented Change Impact Assessment covering:
- Technical impact
- Backward compatibility assessment
- Security implications
- Oracle dependency implications
- Liquidity and market impact
- Legal and regulatory impact
- Governance impact
The CIA must be archived in repository history.
Change approval requirements are as follows:
- Major Change → Multi-Signature + Timelock + Risk Committee Review
- Moderate Change → Multi-Signature + Timelock
- Minor Change → Documentation control only
Where ambiguity exists, the higher classification applies.
If an upgrade introduces unintended consequences:
- A rollback proposal may be initiated through governance.
- Rollback follows identical governance pathway (Safe + Timelock).
- Rollback may not reverse historical blockchain state.
- Only implementation logic may be reverted.
Rollback feasibility depends on proxy upgrade architecture constraints.
Where practicable:
- Proposal initiators should not be sole approvers.
- Governance signers should not directly control oracle submission.
- Operational roles must remain segregated from governance approval authority.
Conflict management is governed by CONFLICT_OF_INTEREST_POLICY.md.
For Major Changes:
- Public notice must be issued prior to timelock execution.
- Notice should include summary, impact classification, and execution timeline.
- On-chain transaction hash must be published post-execution.
Transparency precedes activation.
Changes involving:
- Solidity compiler version
- OpenZeppelin dependency versions
- Safe contract upgrades
- Timelock contract modifications
Must be classified as Major Changes and may require external audit review.
Any modification to:
- Timelock delay duration
- Timelock proposer role
- Timelock executor role
Must be classified as Major Change.
Reduction of delay period requires explicit public justification.
Official communication channels may include:
- Repository publication
- Website notice
- Exchange notification (if listed)
- Public governance announcement
Change communication must occur prior to execution for Major Changes.
All executed changes must include:
- Governance proposal reference
- Timelock operation ID
- Execution transaction hash
- Parameter before/after summary
- Documentation version reference
A structured change log must be maintained.
Following Major Changes:
- A monitoring period must be observed.
- Index calculation integrity must be verified.
- Oracle submission consistency must be reviewed.
- Governance state must be validated.
A post-implementation review summary may be published.
End of Change Control Policy.