The Digital Zimbabwe Gold (dZWG) system is a blockchain-based digital settlement infrastructure deployed on BNB Smart Chain (BSC). It is designed to represent Zimbabwe Gold (ZiG; ISO code: ZWG) in a programmable, auditable, and transferable on-chain form.
The system is not designed as a speculative asset or investment instrument. It is architected as a controlled issuance and settlement layer that integrates blockchain execution with off-chain financial infrastructure, including banking systems, reserve custody, and compliance processes.
The architecture reflects a hybrid model where:
- transactional state and execution are maintained on-chain
- financial backing, compliance, and settlement are managed off-chain
This separation is intentional and fundamental to the system design.
The system architecture is designed to solve three primary constraints:
- Blockchain provides deterministic execution but cannot natively custody fiat or sovereign reserve assets.
- Financial systems require compliance, identity, and legal enforcement that cannot be fully encoded on-chain.
- Upgradeability is required to maintain long-term system relevance and security.
To address these constraints, the architecture is built on:
- proxy-based upgradeability
- strict role-based governance
- off-chain reserve custody with on-chain attestation
- controlled interaction points between financial systems and smart contracts
The system uses the UUPS (Universal Upgradeable Proxy Standard) pattern, based on ERC-1967 storage slots.
This design is selected over non-upgradeable contracts to allow:
- security patches
- feature extensions
- regulatory adaptations
without changing the primary contract address.
The architecture separates execution and storage:
-
Proxy contract:
- stores balances, allowances, roles, and all persistent state
- acts as the canonical user-facing contract
-
Implementation contract:
- contains executable logic
- defines all system behavior
All user interactions are routed through the proxy:
User → Proxy → delegatecall → Implementation → Execution → Proxy storage updated
The proxy never executes logic directly. It forwards execution context to the implementation contract using delegatecall, ensuring that all state mutations occur within proxy storage.
The upgrade process is controlled and multi-stage:
- A new implementation contract is developed and deployed.
- The implementation contract is verified on-chain.
- A governance-controlled upgrade request is submitted.
- The implementation is stored as a pending upgrade.
- A timelock period is enforced.
- After the timelock expires, the upgrade is executed by an authorized role.
- The proxy updates its implementation reference.
This prevents immediate or arbitrary upgrades and introduces a review window.
Upgradeable contracts cannot use constructors because the proxy delegates execution and does not run constructor logic.
Instead, initialization is performed via an initialize(...) function.
This function sets:
- token name and symbol
- administrative roles
- governance addresses
- fee parameters
- compliance configuration
- operational thresholds
The initializer is protected by a guard that ensures:
- it can only be executed once
- re-initialization is prevented
If initialization is skipped or incorrectly executed, the system may remain unconfigured or vulnerable. Therefore, initialization is considered part of the deployment lifecycle and must be executed atomically with proxy deployment.
The system enforces strict separation of authority using role-based access control. Each role is assigned a narrowly defined scope to reduce risk concentration.
This role represents the highest authority within the system.
Responsibilities include:
- assigning and revoking roles
- managing governance structure
- controlling role hierarchy
This role is expected to be held by a multisignature governance wallet, not a single externally owned account.
This role controls contract upgradeability.
Responsibilities include:
- initiating upgrades
- executing upgrade transactions
This role must be isolated from operational roles to prevent unauthorized logic changes.
This role controls token supply expansion.
Responsibilities include:
- minting tokens in response to reserve inflows
This role is tied to financial operations and must be tightly controlled.
This role controls supply reduction.
Responsibilities include:
- burning tokens during redemption
- removing tokens from circulation
This role enforces compliance controls.
Responsibilities include:
- freezing accounts
- restricting transfers
- managing sanctioned addresses
This role manages economic parameters.
Responsibilities include:
- setting fee rates
- updating fee collector addresses
Reserves cannot be held on-chain because Zimbabwe Gold (ZWG) exists within traditional financial systems.
The system uses an attestation model:
- reserves are held off-chain
- reserve data is signed by an authorized signer
- signed data is submitted on-chain
- Reserve balances are calculated off-chain.
- A structured payload is created containing:
- reserve amount
- nonce
- timestamp or deadline
- The payload is signed by an authorized reserve signer.
- The signed payload is submitted to the contract.
- The contract verifies:
- signature authenticity
- nonce uniqueness
- deadline validity
- Valid updates are recorded on-chain.
- nonce prevents replay attacks
- deadlines prevent stale updates
- signer authority ensures data authenticity
Minting is not arbitrary. It is tied to reserve inflows.
- reserves are deposited off-chain
- reserve verification occurs
- issuer role executes mint
- tokens are created and assigned
Minting must remain aligned with reserves to preserve system integrity.
Fees are used to support operational sustainability and infrastructure costs.
- fee is defined in basis points
- applied at transfer execution
- transfer amount is submitted
- fee is calculated
- fee portion is redirected to fee collector
- remaining amount is transferred
- fee rate is adjustable
- fee exemptions may be configured
- fee collector address is configurable
The system must support compliance obligations such as AML and sanctions enforcement.
Compliance checks are executed before transfer finalization.
- account freeze
- blacklist enforcement
- sanctions restrictions
- restricted accounts cannot send or receive tokens
- compliance decisions originate off-chain
- enforcement occurs on-chain
Redemption is a hybrid process involving on-chain and off-chain execution.
- user submits redemption request
- tokens are transferred for redemption
- tokens are burned on-chain
- redemption event is recorded
- off-chain processing is initiated
- fiat or ZWG equivalent is settled
- redemption is not instantaneous
- subject to operational processing
- fully auditable through on-chain records
Pause functionality exists to respond to:
- security incidents
- governance compromise
- regulatory directives
When paused:
- transfers are halted
- minting and burning may be restricted
- system enters controlled state
Authorized governance restores normal operation after issue resolution.
- token balances
- transfer execution
- access control
- fee logic
- reserve attestation records
- upgrade control
- event emission
- reserve custody
- compliance decision-making
- banking operations
- redemption settlement
- signer management
Certain functions cannot be implemented on-chain due to legal, financial, and operational constraints.
All critical actions emit events.
- mint
- burn
- transfer
- reserve updates
- compliance changes
- fee updates
- redemption events
- upgrades
Events enable:
- auditability
- monitoring
- forensic analysis
- regulatory reporting
- minting is halted
- governance intervention required
- system may be paused
- roles reassigned
- transactions delayed
- state remains consistent
- system continues on previous implementation
- hold and transfer tokens
- interact via wallets
- integrate for payments and settlement
- manages supply
- controls upgrades and parameters
- submits reserve attestations
- integrate for trading and liquidity
The dZWG system architecture is designed to provide a controlled, auditable, and upgradeable digital settlement infrastructure that bridges blockchain execution with traditional financial systems.
The architecture prioritizes:
- governance control
- operational alignment
- auditability
- security
- regulatory compatibility
End of Document