Fixed fee strategy

The fixed fee strategy simplifies the process for users by requiring a one-time purchase of a specific amount of tokens to access your dapp's features. This system is ideal for users who prefer a clear and easy-to-follow process.

When implementing the fixed fee strategy for account registration, users need to transfer a specific amount of tokens to a non-existent account. Once the non-existent account receives the tokens, the fixed fee is deducted from the transferred amount. The non-existent account represents an empty account that needs to be topped up with tokens.

For instance, if Bob wants to register an account, he must first have Alice send tokens to his account. After Alice sends the correct amount of tokens using the transfer function, Bob must complete the registration by performing the following operations:

• Bob needs to execute the evm_signatures operation if he wants to access the account using an EVM wallet.
• Bob needs to execute the ras_transfer_fee operation.
• Bob needs to execute the register_account operation.

Upon successful completion of these steps, the account is activated and ready for immediate use.

In the chromia.yml file, you must set two thresholds:

1. Set a minimum amount of tokens that a non-existent account expects to receive.
2. Set a fixed fee that users must pay to register a non-existent account.

For example, if the minimum amount is set to 9 tokens and the fixed fee is set to 5 tokens, Alice transfers a minimum amount of 9 CHR tokens to Bob to fulfill the first requirement. Then, Bob must pay 5 CHR tokens to register the account. The remaining balance after the account registration becomes four tokens.

Code example

To build your dapp from the template, refer to the code examples and corresponding tests.

You must add the following example configuration to your chromia.yml file:

lib.ft4.core.accounts.strategies.transfer:
  rules:
    - sender_blockchain: x"0000000000000000000000000000000000000000000000000000000000000000"
    sender: "*"
    recipient: "*"
    asset:
        - name: "MyTestAsset"
        min_amount: 100L
    timeout_days: 60
    strategy:
    - "fee"
lib.core.accounts.strategies.transfer.fee:
  asset:
    - name: "MyTestAsset" # issued by current blockchain
    amount: 40L

You can divide the configuration into two parts:

Account registration process: This configuration defines the process for registering an account (lib.ft4.core.accounts.strategies.transfer).

Property	Description
sender_blockchain	The property sender_blockchain is set to receive tokens from the blockchain with the BRID: x"0000000000000000000000000000000000000000000000000000000000000000". To receive tokens from all chains in the Chromia network, use the asterisk sign "*" as the value.
sender	The sender property defines who can send tokens to the dapp. The value "*" allows everyone to send tokens.
recipient	The recipient property defines who can receive tokens in the dapp. The value "*" indicates that everyone can receive tokens.
name	The name property represents the name of the asset required for account registration.
min_amount	The min_amount property sets a minimum threshold for the transfer to a non-existent account for registration purposes.
timeout_days	The timeout_days property specifies the period in days during which a user can claim a non-existing account with a balance.
strategy	The strategy configures the strategy type used for the registration process.

Fixed fee rules: This configuration specifies the rules for fixed fee (lib.core.accounts.strategies.transfer.fee).

Property	Description
name	The name represents the name of the asset used to pay a fixed fee.
amount	The amount allows setting a minimum threshold that a user must pay for account activation.

note

Please refer to the tests for testing the above configuration.

Example: Fixed fee dapp business logic

The following business logic enables the development of a basic medical application. This application allows users to register an account with a hospital, which enables them to book consultations and other services. It uses a fixed fee strategy for creating an account in the application. Users may need to make additional payments for booking other hospital services, such as consultations and examinations, as the account registration strategy does not handle these transactions.

1. Create the User module.
2. Within the module, create the User entity with two distinct roles: doctor and patient.
3. Utilize the register_account operation for users to register an account with the dapp. Registration should be conducted using the fixed fee strategy. Refer to the code example demonstrating the registration operation, which relies on the FT4 token standard.
4. Create the Appointment module.
5. Within the Appointment module, create the Appointment entity. It should include the following data: patient, doctor, and timestamp.
6. Implement the create_appointment operation with the following expected arguments: patient account id, doctor account id, and timestamp.