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 NumberGeneric CategoryAccount Type
400Application RewardsRevenue
401Super Validator RewardsRevenue
402Validator RewardsRevenue
403Revenue Share RewardRevenue
500Canton Coin FeesExpense
501Canton Coin Reward FeeExpense
502Subscription FeeExpense

Standard Specific Chart of Accounts

Account NumberSpecific CategoryAccount Type
400Application Interaction RewardsRevenue
401Super Validator RewardsRevenue
402Transaction Validation RewardsRevenue
403Validator RewardsRevenue
404Revenue Share RewardRevenue
500Coin Locking FeeExpense
501Contract Record Creation FeeExpense
502Fixed Transfer Processing FeeExpense
503Idle Coin Transfer FeeExpense
504Idle Coin Usage FeeExpense
505Locked Coin Transfer FeeExpense
506Network Service Purchase FeeExpense
507Reward Claim Balance Adjustment FeeExpense
508Tiered Transfer FeeExpense
509Transfer Balance Adjustment FeeExpense
510Variable Transfer Processing FeeExpense
511Subscription FeeExpense

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 PatternDescriptionGeneric CategorySpecific CategoryInteracting Address
FeeType: receiver_lock_holding_feeThis 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 FeesCoin Locking Fee0x0
FeeType: receiver_base_transfer_feeThis 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 FeesContract Record Creation Fee0x0
FeeType: receiver_transfer_feeThis 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 FeesTiered Transfer Fee0x0
FeeType: sender_base_transfer_feeA standard fixed fee paid by the sender during a coin transfer. It helps cover basic network processing costs for executing the transaction.Canton Coin FeesFixed Transfer Processing Fee0x0
FeeType: sender_lock_holding_feeA 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 FeesLocked Coin Transfer Fee0x0
FeeType: holding_feesA 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 FeesIdle Coin Transfer Fee0x0
FeeType: sender_feeA 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 FeesNetwork Service Purchase Fee0x0
FeeType: sender_change_feeFee for recording the change to a senders balance resulting from a transfer of canton coinsCanton Coin FeesTransfer Balance Adjustment Fee0x0
FeeType: sender_transfer_feeA 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 FeesVariable Transfer Processing Fee0x0
RewardFeeType: sender_change_feeA 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 FeeReward Claim Balance Adjustment Fee0x0
RewardType: input_app_reward_amountA 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 RewardsApplication Interaction Rewards0x0
RewardType: input_sv_reward_amountA 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 RewardsSuper Validator Rewards0x0
RewardType: input_validator_reward_amountA reward given to a validator for participating in the validation of a network traffic purchase.Validator RewardsValidator Rewards0x0

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 PatternDescriptionGeneric CategorySpecific CategoryInteracting Address
TransactionType: Amulet_Rules TransferA 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 RewardRevenue Share RewardVendor (i.e. Bitwave, TheTie, Cumberland)
TransactionType: Amulet_Rules TransferAn 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 FeeSubscription FeeVendor (i.e. Bitwave, TheTie, Cumberland)

Internal Transfer Rules

🚧

Section under construction