chronograph-evm

Project chronograph-evm explores design of a 10,000 Baht Digital Wallet by applying relevant Ethereum standards, including ERC-6372 and ERC-7818.

Important

This is not official source code of Digital Wallet Project form government.

Requirement

The system is governed by the following requirements. The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” are to be interpreted as described in RFC 2119 and RFC 8174.

• Digital money SHALL expire 6 months after the date of receipt.
• Digital money MUST only be spent at registered merchants participating in the program.
• Digital money MUST only be used within the recipient’s domicile district.
• Digital money MUST only be withdrawn or converted into cash after it has been circulated and spent at least 3 times.

Implementation Approaches

Two possible approaches are considered for managing the token life span

ERC-7818 : DigitalWalletToken.sol

• Supports per-user issuance, meaning each citizen’s 6-month validity period begins at the time of receipt.
• Suitable if on-boarding occurs at different times.

ERC-6372 : DigitalWalletTokenV2.sol

• Instead of expiring tokens, the token itself has no lifespan. Transferability is restricted within a defined period using time-based clocks.
• Ensures all citizens share the same start and end date for usability.

When citizen transfer Digital Token to merchant expirable token will be burned and minting Merchant Digital Token to merchant at index [0] balance of merchant

When merchants transfer tokens between each other, the circulation index increases to track spending cycles

Transfer Cycle 0: Burning Digital Token → Mint Merchant Digital Token
Transfer Cycle 1: Spender balance[0] → Receiver balance[1]
Transfer Cycle 2: Spender balance[1] → Receiver balance[2]  
Transfer Cycle 3: Spender balance[2] → Receiver balance[3]
Transfer Cycle 4+: Spender balance[3] → Receiver balance[3] (stays at final tier)

Deployment and Initialization Sequence

1. Deploy Contracts

   • Deploy AddressRegistry.
   • Deploy FrozenRegistry.
   • Deploy DigitalWalletToken, passing the addresses of AddressRegistry and FrozenRegistry to its constructor.
   • Deploy MerchantDigitalToken, passing the addresses of AddressRegistry and FrozenRegistry to its constructor.

2. Initialize Contracts

• Update the DigitalWalletToken contract with the deployed MerchantDigitalWalletToken contract address so DigitalWalletToken can call mint MerchantDigitalWalletToken.
• Update the MerchantDigitalWalletToken contract with the deployed DigitalWalletToken contract address as the issuer.

---

1. Merchant Registration to Exception List

• After registering a merchant in the AddressRegistry, the merchant must also be added to the exception list in the DigitalWalletToken (ERC7818Exception) contract.
• This can be done either manually or via an owner contract call executed in sequence.
  Note: This step is not required when using DigitalWalletTokenV2.

Additional Rules

• Tokens held by citizens MUST NOT be transferable from one citizen to another.
• Tokens held by merchants MUST NOT be transferable back to citizens.
• Tokens held by merchants MUST be non-expiring.
• Transfer MUST be validated to ensure that both the spender and the recipient are located within the same district.
• Circulation tracking (e.g., “spent at least 3 times before cash-out”) MUST be implemented.

Appendix

Other Possible Solutions

• ERC-1400: The Security Token Standard
• ERC-3643: T-REX - Token for Regulated EXchange
• ERC-7291: Purpose bound money

Copyright

chronograph-evm Copyright 2025 Sirawit Techavanitch. This repository release under the GPL-3.0 license