Section 1 · Business Objective
Domain Business Objective — OR-03 Smart Contract Management
Ensure that all on-chain protocol logic governing token minting, burning, and supply management is deployed securely, operated within pre-approved parameters, and capable of being paused within 30 minutes of a confirmed critical vulnerability — and that any confirmed bug is remediated and redeployed within 8 hours. Protocol state must remain recoverable, every upgrade must be independently audited and governance-approved before execution, and all contract behaviour must be continuously monitored for invariant violations post-deployment.
Why Smart Contract OR carries Critical inherent risk: Unlike reserve or key management, a critical bug in the smart contract can affect every token holder simultaneously, is publicly visible on-chain the moment it is exploited, and cannot be reversed without a governance-approved upgrade cycle. The 30-minute pause ceiling is not aspirational — it is the maximum interval during which an active exploit can continue before the circuit-breaker halts further damage.
Section 2 · Process Lifecycle (SSDLC)
Smart Contract Secure Development Lifecycle
Nine-stage lifecycle from threat modelling through post-deployment monitoring. Each stage has a defined accountable function, gate criteria, and timing constraint. No stage may be bypassed for production deployments.
#
Stage
Accountable Function
Gate / Timing
01
Requirements & Threat Modelling
Functional requirements documented with explicit state-transition rules for mint, burn, pause, and upgrade. STRIDE threat model produced, identifying attack surfaces including reentrancy, integer overflow, front-running, and oracle manipulation. Security requirements baseline established before code is written. Output: signed-off requirements document and threat model register.
Protocol Engineers
Security Officer
CAB
Security Officer
CAB
Gate: requirements
sign-off before
dev commences
sign-off before
dev commences
02
Secure Development
Contract code written to approved security standards (Solidity best practices, OpenZeppelin library usage, no unchecked math, no delegatecall to untrusted contracts). Peer code review mandatory for each pull request. Static analysis (Slither, MythX or equivalent) run at each commit. Developer self-certification that threat model requirements are addressed. No direct commits to main branch.
Protocol Engineers
Peer Reviewer
Peer Reviewer
Continuous during
development sprint
development sprint
03
Internal Security Review
Security team (independent of development) conducts structured code review against the threat model. Manual review of access control logic, upgrade proxy configuration, pause function scope, and oracle dependency. Findings classified by severity (Critical / High / Medium / Low). All Critical and High findings must be resolved and re-reviewed before proceeding. Review report retained in immutable audit trail.
Internal Security
(independent of dev)
Security Officer
(independent of dev)
Security Officer
Gate: zero open
Critical/High before
external audit
Critical/High before
external audit
04
External Audit (Firm A)
First independent external audit by qualified smart contract security firm. Full scope: logic correctness, access control, upgrade safety, gas limits, front-running exposure, oracle integrity. Auditor receives full source, deployment scripts, and test suite. All Critical and High findings resolved and confirmed by auditor before Firm B audit commences. Audit report publicly disclosed or available on request.
External Audit Firm A
Protocol Engineers
(response only)
Protocol Engineers
(response only)
Gate: Firm A sign-off
before Firm B
engagement begins
before Firm B
engagement begins
05
External Audit (Firm B — Independent)
Second independent external audit by a different qualified firm with no prior engagement on this codebase. Firm B reviews the same scope independently and also reviews Firm A's findings and resolutions. Any new Critical or High findings restart the resolution cycle. Dual-audit requirement is a hard gate — no exception process exists for production deployment without both firms' sign-off. Combined audit evidence package assembled.
External Audit Firm B
Security Officer
Security Officer
Gate: both firms
signed off before
testnet deployment
signed off before
testnet deployment
06
Testnet & UAT Deployment
Contract deployed to testnet with production-equivalent configuration. Integration tests covering all mint/burn/pause/upgrade paths executed. Scenario test: pause triggered, upgrade executed, state validated post-upgrade. Load test at projected peak transaction volumes. Emergency response team performs tabletop exercise against the pause-and-patch scenario. UAT sign-off from Protocol Engineering and Security Officer required before CAB submission.
Protocol Engineers
ERT
Security Officer
ERT
Security Officer
Gate: UAT sign-off
before CAB
submission
before CAB
submission
07
Change Advisory Board Approval
CAB reviews complete evidence package: requirements sign-off, threat model, internal review report, dual external audit reports, testnet UAT results, and rollback/pause procedures. CAB vote is documented. Any board member may raise a blocking concern requiring resolution before approval. Approved deployment window and authorized deployer wallet address are specified in the CAB decision record. Emergency changes follow expedited CAB process (2-member quorum, documented rationale).
Change Advisory Board
Security Officer
Legal / Compliance
Security Officer
Legal / Compliance
Gate: CAB approval
record before any
mainnet action
record before any
mainnet action
08
Pre-Upgrade State Snapshot & Proxy-Governed Deployment
Immediately before deployment, a complete state snapshot is taken (total supply, holder balances, pending transactions, current proxy implementation address). Deployment executed via governance-approved multisig through the proxy's upgrade function. Timelock delay (minimum 24 hours for non-emergency upgrades) enforced on-chain. Deployment transaction hash recorded. Post-deployment invariant checks run immediately: supply unchanged, proxy points to new implementation, pause function operational.
On-chain Governance
Multisig (≥m-of-n)
Protocol Engineers
Multisig (≥m-of-n)
Protocol Engineers
Within CAB-approved
deployment window
(timelock enforced)
deployment window
(timelock enforced)
09
Post-Deploy Monitoring & Invariant Verification
Continuous automated monitoring of: (a) total supply vs. reserve record — any deviation triggers critical alert; (b) unexpected function calls — any call to restricted functions from non-authorized addresses triggers immediate alert; (c) gas consumption anomalies indicating potential exploit; (d) oracle price feed deviations beyond threshold. Monitoring dashboard reviewed by Security Officer daily. Alert-to-pause escalation path defined and tested quarterly.
Security Officer
ERT (on-call)
Protocol Engineers
ERT (on-call)
Protocol Engineers
Continuous;
daily review;
quarterly drill
daily review;
quarterly drill
Section 3 · Functions & Roles
Operational Roles & Accountabilities
Protocol Engineers
Authors of contract code. Responsible for threat model implementation, peer review participation, and resolution of audit findings. May not self-approve changes to production. No unilateral mainnet deployment authority.
Internal Security Team
Conducts internal code review independent of development. Maintains static analysis tooling. Owns the threat model register. Advises CAB on residual risk. Reports to Security Officer, not Protocol Engineering lead.
External Audit Firms (A & B)
Independent third-party security specialists engaged under contract. Each firm provides a written audit report with findings classified by severity. Both firms' sign-off is required before mainnet deployment — no exceptions.
Change Advisory Board (CAB)
Multi-member governance body with representation from Engineering, Security, Compliance, and Legal. Reviews complete evidence package before any mainnet deployment. Maintains deployment window records and blocking veto authority.
Emergency Response Team (ERT)
On-call 24/7 capability to execute the pause function within the 30-minute impact tolerance ceiling. Maintains pause playbook, pre-provisioned pause credentials, and escalation tree. Conducts quarterly tabletop and live drill exercises.
On-chain Governance Multisig
Holds upgrade authority for the proxy contract. Configured as an m-of-n multisig with signers distributed across jurisdictions and key custodians. Upgrade transactions require quorum. Key management governed by OR-02 Key Management program.
Section 4 · Risk Register
Identified Risks — Smart Contract Management Domain
| Risk ID | Risk Statement | Trigger / Source | Inherent Likelihood | Inherent Impact | Inherent Risk Rating |
|---|---|---|---|---|---|
| SC-R01 | Critical bug in production contract exploited before pause executes | Insufficient pre-deployment testing, novel attack vector post-audit | MEDIUM | CRITICAL | CRITICAL |
| SC-R02 | Unauthorized contract upgrade bypassing governance controls | Compromised upgrade key, insider threat, governance bypass vulnerability | LOW | CRITICAL | HIGH |
| SC-R03 | Emergency Response Team unable to execute pause within 30-minute ceiling | ERT unavailability, pause credential failure, on-call breakdown | LOW | CRITICAL | HIGH |
| SC-R04 | L1 network halt exceeding 6-hour impact tolerance ceiling | Ethereum consensus failure, prolonged fork, infrastructure outage | LOW | HIGH | HIGH |
| SC-R05 | Oracle price feed manipulation causing incorrect reserve valuation | Flash loan attack, thin liquidity, compromised oracle node | MEDIUM | HIGH | HIGH |
| SC-R06 | Contract state corruption during proxy upgrade | Storage collision in proxy pattern, incorrect initializer, upgrade script error | LOW | CRITICAL | HIGH |
| SC-R07 | Front-running attack during contract upgrade window | MEV bots, public mempool visibility of pending upgrade transaction | MEDIUM | MEDIUM | MEDIUM |
| SC-R08 | Production deployment without completing full SSDLC gate sequence | Time pressure, emergency change, governance process shortcut | LOW | HIGH | HIGH |
| SC-R09 | Post-deploy invariant violation undetected due to monitoring gap | Alert configuration error, monitoring system failure, novel exploit path | MEDIUM | HIGH | HIGH |
Section 5 · Control Framework
Controls — Smart Contract Management Domain
| Control ID | Control Name | Control Description | Risks Addressed | Regulatory Anchor |
|---|---|---|---|---|
| SC-C01 | Upgradeable Proxy Architecture (Transparent / UUPS) | Contract deployed behind OpenZeppelin Transparent or UUPS upgradeable proxy. Upgrade authority held exclusively by governance multisig. Implementation address change requires successful proxy upgrade call with full quorum. Storage layout compatibility enforced via upgrade scripts validated before deployment. Emergency non-proxy patch path does not exist — all changes must go through proxy governance. | SC-R02SC-R06 | GENIUS Act § 9 OCC NPR § 15.14 |
| SC-C02 | On-chain Governance Timelock (≥24 hr non-emergency) | All non-emergency upgrade transactions subject to a minimum 24-hour on-chain timelock enforced by the governance contract. Timelock provides a public observation window during which any anomaly in the proposed upgrade can be identified and the upgrade cancelled before execution. Emergency upgrades may bypass the timelock only with documented CAB quorum approval and Security Officer sign-off. Timelock bypass events are logged and reported to the Board within 24 hours. | SC-R02SC-R07 | GENIUS Act § 9 NIST CSF 2.0 GV.OC |
| SC-C03 | Emergency Pause Function with 30-Minute ERT Execution Ceiling | Contract includes an accessible pause function callable by pre-authorized ERT wallet addresses independent of the governance multisig. Pause credentials are pre-provisioned, tested quarterly, and stored in hardware-secured key management (governed under OR-02). ERT maintains a 24/7 on-call roster with a maximum 15-minute response-to-execution target (allowing 15 minutes of investigation before the 30-minute ceiling). Pause scope: halts all mint, burn, and transfer functions while leaving view functions operational for holder balance verification. | SC-R01SC-R03 | GENIUS Act § 113 OCC NPR § 15.14 |
| SC-C04 | Mandatory Dual External Audit — Hard Deployment Gate | No production deployment may proceed without written sign-off from two independent external audit firms with no shared engagement history on this codebase. Each audit covers full scope: logic correctness, access control, upgrade safety, oracle dependencies, and gas constraints. Finding resolution is verified by the originating auditor before sign-off is granted. The dual-audit requirement cannot be waived by any internal authority — only the Board may grant a documented exception, which is itself subject to external legal review. Exception history is disclosed in regulatory reporting. | SC-R01SC-R08 | GENIUS Act § 9 NIST SP 800-218 |
| SC-C05 | Pre-Upgrade State Snapshot & Post-Deploy Invariant Verification | Immediately before any upgrade execution, an automated state snapshot captures total supply, all holder balances, pending transaction queue, and current proxy implementation address. Immediately post-deployment, automated invariant checks verify: (a) total supply unchanged, (b) proxy implementation address matches approved new implementation, (c) pause function callable by ERT addresses, (d) no unexpected storage slot modifications. Any invariant failure triggers immediate pause and escalation. Snapshot and verification records stored in immutable audit log. | SC-R06SC-R09 | OCC NPR § 15.14 NIST CSF 2.0 RS |
| SC-C06 | Continuous Post-Deployment Invariant Monitoring & Alerting | Automated on-chain monitoring (Forta, OpenZeppelin Defender, or equivalent) runs continuously post-deployment. Monitored invariants: supply-reserve equality (deviation >0.01% triggers critical alert); unauthorized access attempts on restricted functions; gas consumption anomalies (>150% of baseline for similar transactions); oracle price feed deviations (>2% in a 60-second window). All critical alerts route to ERT on-call. Alert-to-pause escalation procedure documented and tested quarterly. Alert suppression or modification requires CAB approval. | SC-R01SC-R05SC-R09 | GENIUS Act § 113 NIST CSF 2.0 DE |
| SC-C07 | L1 Network Halt Contingency Plan | Documented contingency plan for L1 (Ethereum mainnet) halt scenarios. Plan includes: (a) communications protocol for holder notifications within 1 hour of confirmed L1 halt; (b) reserve and ledger state preservation procedures during L1 unavailability; (c) redemption queue management for the 6-hour impact tolerance ceiling; (d) coordination procedures with L1 validator community and infrastructure providers for status updates; (e) escalation triggers at T+2hr and T+4hr to senior management and regulators. Plan tested via tabletop exercise annually. L1 dependency on bridge or sidechain operations is separately governed. | SC-R04 | GENIUS Act § 113 OCC NPR § 15.14 |
| SC-C08 | Immutable SSDLC Audit Trail & SSDLC Gate Enforcement | All SSDLC gate artefacts (requirements sign-off, threat model, internal review report, both external audit reports, UAT results, CAB decision record, deployment transaction hash, post-deploy invariant verification results) are stored in an immutable, tamper-evident repository. The deployment pipeline enforces gate completion programmatically — production deployment credentials are withheld until all nine SSDLC stages are marked complete by authorized approvers. Any emergency exception to a gate is logged with full rationale, approver identities, and Board notification. SSDLC gate completion records are produced for regulatory examination on request. | SC-R02SC-R08 | GENIUS Act § 9 NIST SP 800-218 NIST CSF 2.0 GV |
Section 6 · Scenario Stress Test
SC-S01: Critical Production Bug / Active Exploit
SC-S01 — Critical Bug Identified in Production Contract
Scenario: Automated monitoring detects an anomalous supply increase not matched by a deposit event. Concurrent reports from holders of unexpected token behaviour. Security team confirms potential reentrancy exploit in the burn function. Impact tolerance ceilings: pause within 30 minutes; patch redeployed within 8 hours.
1
T+0 — Alert Detection & ERT Activation (0–5 min)
Automated monitoring system fires critical alert: supply-reserve deviation >0.01%. Alert routes simultaneously to ERT on-call, Security Officer, and CTO. ERT on-call acknowledges within 5 minutes per SLA. Incident declared. ERT activates pause pre-provisioned credentials from hardware key storage. Secondary ERT member placed on standby. All other scheduled upgrades or deployments suspended immediately.
2
T+15 min — Pause Execution & Exploit Containment (≤30 min ceiling)
ERT executes pause function via pre-provisioned credential. Pause transaction broadcast and confirmed on-chain. All mint, burn, and transfer functions halted. Post-pause invariant check runs automatically — confirms pause active, supply frozen. Holder-facing status page updated: "Maintenance pause in effect — funds are safe, withdrawals temporarily suspended." ERT confirms no additional exploit transactions in the mempool. Pause timestamp logged as the boundary event for impact measurement.
3
T+30 min–2 hr — Exploit Triage & Scope Determination
Protocol Engineering conducts rapid code review to confirm exploit vector and scope. Security Officer coordinates with Firm A (on retainer for emergency response) for expedited second opinion on exploit mechanism. State snapshot retrieved and compared against pre-pause on-chain state to quantify any supply discrepancy. Legal notified of potential holder impact. Regulator notification assessed under GENIUS Act § 113 notification requirement — preliminary notification drafted.
4
T+2–5 hr — Patch Development, Internal Review & Expedited Audit
Protocol Engineering develops targeted patch addressing confirmed exploit vector. Internal Security Team performs expedited review (compressed timeline — scope limited to changed lines and their interactions). Emergency CAB convened (2-member quorum sufficient under emergency CAB procedure). External Firm A conducts expedited audit of the specific patch — full codebase re-audit not required for targeted patch, but auditor scope covers all functions affected by the change. Firm A provides written emergency sign-off. Testnet deployment and automated invariant checks run against patched version.
5
T+5–8 hr — Patched Deployment & State Verification (≤8 hr ceiling)
CAB issues written emergency deployment approval with bypass of 24-hour timelock (documented exception logged to Board). Governance multisig executes proxy upgrade to patched implementation. Post-deploy invariant verification runs immediately. Automated monitoring confirms: supply integrity restored, pause lifted after Security Officer sign-off, all functions operational. Regulator formal notification transmitted. Holder communications updated with post-incident summary. Full dual-audit requirement (Firm B engagement) initiated within 5 business days for comprehensive post-incident review.
6
T+8 hr–30 days — Post-Incident Review & Root Cause Analysis
Full post-incident report produced within 10 business days. Root cause analysis identifies how exploit vector passed internal review and dual external audits. SSDLC improvements identified and implemented. Firm B completes comprehensive audit of the patched production codebase. Board receives post-incident report. Regulatory examination package assembled including timeline, all decision records, audit evidence, and corrective actions. Impact tolerance measurement documented: pause execution time vs. 30-min ceiling; patch deployment time vs. 8-hr ceiling.
30 min
Pause ceiling (CRITICAL)
8 hr
Patch RTO (HIGH)
6 hr
L1 halt ceiling (HIGH)
Section 7 · Structural Redundancy Architecture
Defence-in-Depth: Smart Contract Domain
Proxy Architecture & Upgrade Governance
Upgradeable proxy pattern (OpenZeppelin Transparent/UUPS) separates logic from state storage. Implementation can be replaced without migrating state. Upgrade authority restricted to governance multisig — no single signer can unilaterally upgrade. Timelock enforces public observation window. Storage layout compatibility enforced programmatically before any upgrade is executed.
Layered Audit Assurance (Internal + Dual External)
Three independent review layers — internal security team, external Firm A, and external Firm B — each operating independently with separate scope coverage. Firm B reviews Firm A's findings and resolutions. Any single layer catching a critical issue prevents deployment. Combined audit trail provides comprehensive pre-deployment assurance record for regulatory examination.
Pause Circuit-Breaker & ERT Redundancy
Emergency pause function callable by ERT credentials independent of governance multisig — ERT does not need multisig quorum to execute a pause. Primary and secondary ERT members maintain pre-provisioned credentials in separate hardware key stores. Quarterly live drills verify end-to-end pause execution under realistic conditions. Pause credential rotation governed under OR-02 Key Management program.
Continuous Monitoring & Automated Invariant Enforcement
On-chain monitoring operates independently of the contract itself — external bots and monitoring agents observe chain state and fire alerts before exploits can escalate. Monitored invariants include supply integrity, oracle feed health, and gas anomalies. Alert routing tested quarterly. Monitoring system itself is subject to annual security review to prevent monitoring-layer attacks.