Metadata Based Rule Categorization
📚 Manual Chart of Accounts Configuration
In alignment with Global Synchronizer Foundation (GSF) metadata standards, Bitwave offers two predefined account schema configurations for transaction categorization on the Canton network:
- Standard Chart of Accounts: A streamlined, metadata-based schema designed for straightforward transaction rule application.
- Standard Specific Chart of Accounts: An extended schema that provides fine-grained metadata labels for scenarios requiring enhanced categorization precision.
For a step-by-step guide to creating this manual Chart of Accounts in Bitwave, please refer to the "Create Categories & Contacts" section.
Standard Chart of Accounts
| Account Number | Generic Category | Account Type |
|---|---|---|
| 400 | Application Rewards | Revenue |
| 401 | Super Validator Rewards | Revenue |
| 402 | Validator Rewards | Revenue |
| 403 | Revenue Share Reward | Revenue |
| 500 | Canton Coin Fees | Expense |
| 501 | Canton Coin Reward Fee | Expense |
| 502 | Subscription Fee | Expense |
Standard Specific Chart of Accounts
| Account Number | Specific Category | Account Type |
|---|---|---|
| 400 | Application Interaction Rewards | Revenue |
| 401 | Super Validator Rewards | Revenue |
| 402 | Transaction Validation Rewards | Revenue |
| 403 | Validator Rewards | Revenue |
| 404 | Revenue Share Reward | Revenue |
| 500 | Coin Locking Fee | Expense |
| 501 | Contract Record Creation Fee | Expense |
| 502 | Fixed Transfer Processing Fee | Expense |
| 503 | Idle Coin Transfer Fee | Expense |
| 504 | Idle Coin Usage Fee | Expense |
| 505 | Locked Coin Transfer Fee | Expense |
| 506 | Network Service Purchase Fee | Expense |
| 507 | Reward Claim Balance Adjustment Fee | Expense |
| 508 | Tiered Transfer Fee | Expense |
| 509 | Transfer Balance Adjustment Fee | Expense |
| 510 | Variable Transfer Processing Fee | Expense |
| 511 | Subscription Fee | Expense |
Alternatively, if you prefer to define a customer Chart of Accounts or synchronize your existing ERP ledger structure, follow our Connect General Ledger Software guide. After configuring either a manually defined or ERP-synced Chart of Accounts, proceed to the next section to create metadata-driven transaction rules.
🏷️ Metadata-Based Rules Configuration
General Rules
| Metadata Pattern | Description | Generic Category | Specific Category | Interacting Address |
|---|---|---|---|---|
| FeeType: receiver_lock_holding_fee | This fee is charged when a coin is "locked" with specific conditions or restrictions. These locks may require multiple parties to authorize future transfers. | Canton Coin Fees | Coin Locking Fee | 0x0 |
| FeeType: receiver_base_transfer_fee | This base fee is applied when new coin contract records are created during a transfer. Typical transfers involve at least two such records—one for the recipient and one for the change returned to the sender. | Canton Coin Fees | Contract Record Creation Fee | 0x0 |
| FeeType: receiver_transfer_fee | This fee is incurred when a Canton Coin is transferred to a recipient different from the sender. The amount of the fee is calculated based on a tiered structure that depends on the value of the transaction: | Canton Coin Fees | Tiered Transfer Fee | 0x0 |
| FeeType: sender_base_transfer_fee | A standard fixed fee paid by the sender during a coin transfer. It helps cover basic network processing costs for executing the transaction. | Canton Coin Fees | Fixed Transfer Processing Fee | 0x0 |
| FeeType: sender_lock_holding_fee | A fee paid by the sender for transferring locked Canton Coins. It covers the added network overhead associated with managing and validating the locked state during the transaction. | Canton Coin Fees | Locked Coin Transfer Fee | 0x0 |
| FeeType: holding_fees | A holding fee applied when previously idle Canton Coins were used to purchase network traffic or services. This fee discourages inactivity by penalizing delayed coin usage in utility transactions. | Canton Coin Fees | Idle Coin Transfer Fee | 0x0 |
| FeeType: sender_fee | A general fee paid by the sender during the purchase of network traffic or services. This fee supports the cost of processing the transaction on the Canton Network. | Canton Coin Fees | Network Service Purchase Fee | 0x0 |
| FeeType: sender_change_fee | Fee for recording the change to a senders balance resulting from a transfer of canton coins | Canton Coin Fees | Transfer Balance Adjustment Fee | 0x0 |
| FeeType: sender_transfer_fee | A fee paid by the sender during a coin transfer. This fee is a variable portion of the overall transfer cost and helps cover the network's processing of the transaction. | Canton Coin Fees | Variable Transfer Processing Fee | 0x0 |
| RewardFeeType: sender_change_fee | A fee applied to adjust the sender’s balance after a transfer, specifically when rewards are being claimed in the same transaction. This fee captures the network cost of recording the updated balance (change) due to both the transfer and reward claiming process. | Canton Coin Reward Fee | Reward Claim Balance Adjustment Fee | 0x0 |
| RewardType: input_app_reward_amount | A reward granted for interacting with an application on the Canton Network. It was recorded during a standard coin transfer, recognizing user engagement or participation in app-related activity. | Application Rewards | Application Interaction Rewards | 0x0 |
| RewardType: input_sv_reward_amount | A reward given to a supervalidator for helping validate the transaction. It was included in a standard transfer to compensate their role in maintaining network integrity. | Super Validator Rewards | Super Validator Rewards | 0x0 |
| RewardType: input_validator_reward_amount | A reward given to a validator for participating in the validation of a network traffic purchase. | Validator Rewards | Validator Rewards | 0x0 |
Step 1 - Navigate to Transactions section and then select "Rules"
Step 2 - Select "Create Rule"
Step 3 - Navigate to Conditions > Add Condition and use the dropdown to select the "Metadata Filter" condition.
Step 4 - Specify which metadata type you would like to use for your rule.
Refer to the table above to map your rules based on the Fee Type, Reward Type, Reward Fee Type, and Transaction Type.
Vendor Specific Rules
After defining the general rules above, you’ll see transactions tagged only with the TransactionType metadata—customize these by assigning each to the correct vendor address.
| Metadata Pattern | Description | Generic Category | Specific Category | Interacting Address |
|---|---|---|---|---|
| TransactionType: Amulet_Rules Transfer | A reward earned by interacting with featured apps—featured app operators allocate a share based on app usage and then return a portion of those rewards back to the users as on-chain payouts. | Revenue Share Reward | Revenue Share Reward | Vendor (i.e. Bitwave, TheTie, Cumberland) |
| TransactionType: Amulet_Rules Transfer | An annual fee is escrowed via a time-locked smart contract in a designated restricted wallet, after which the utility app's payment-streaming module enforces automated, pro-rata disbursements at each network round (approximately every 10 minutes). | Subscription Fee | Subscription Fee | Vendor (i.e. Bitwave, TheTie, Cumberland) |
Internal Transfer Rules
Section under construction
Updated about 8 hours ago