Example FeeContract Interactions

In this section, we provide detailed, real-world scenarios that demonstrate how application fees are set, collected, and distributed using the FeeContract. These examples will give you a clearer understanding of how the contract functions in practical situations.

Example 1: Setting and Updating the Base Fee

Scenario: The Fee Oracle suggests a change in the base application fee due to market fluctuations.

  1. Initial Setting:

    • Initially, the base fee (_fee) is set to 10 tokens as per the Fee Oracle's directive.

    • Developers can set their service fees within a range determined by _minDevFeeMultiple = 1 and _maxDevFeeMultiple = 3.

  2. Updating the Fee:

    • The Fee Oracle updates its directive to 12 tokens due to changing network conditions.2

    • The updateFee() function is called, and _fee is now updated to 12 tokens.

    • Now, developers can charge a minimum of 12 tokens and a maximum of 36 tokens for their services.

Example 2: Developer Fee Setting

Scenario: A developer wants to set a fee for their new blockchain application.

  1. Determining the Fee:

    • The current base application fee (_fee) is 12 tokens.

    • The developer decides to set their service fee at 2.5 times the base fee.

  2. Calculating the Service Fee:

    • The service fee is calculated as 12Ɨ2.5=3012Ɨ2.5=30


    • This fee is within the allowed range set by the FeeContract (12 to 36 tokens), so it is a valid fee for the developer to charge.

Example 3: Distributing Collected Fees

Scenario: The FeeContract has collected fees and is ready to distribute them among different channels.

  1. Fee Accumulation:

    • Assume the FeeContract has collected a total of 1000 tokens in application fees over a period.

  2. Channel Setup:

    • There are three channels set up for fee distribution with the following weights: Channel A (weight = 1), Channel B (weight = 2), Channel C (weight = 3).

  3. Distribution Calculation:

    • Total weights combined: 1+2+3=61+2+3=6 shares.

    • Share of each channel:

      • Channel A: 1/6Ɨ1000=166.671/6Ɨ 1000 =166.67 tokens.

      • Channel B: 2/6Ɨ1000=333.332/6Ɨ1000=333.33 tokens.

      • Channel C: 3/6Ɨ1000=5003/6Ɨ1000=500 tokens.

  4. Executing the Distribution:

    • The distributeFees() function is called.

    • Each channel receives its respective share of the total collected fees based on its weight.

Example 4: Fee Updates and Grace Periods

Scenario: The base fee needs an update, but there is a grace period to accommodate users' adaptation to the new fee.

  1. Initial Fee Update:

    • The Fee Oracle suggests increasing the base fee from 12 to 15 tokens.

    • The updateFee() function is called, and _fee is set to 15 tokens.

  2. Grace Period Implementation:

    • A predefined grace period, such as 600 blocks or approximately 50 minutes, is established, allowing transactions to continue utilizing the old fee during this transition phase.

    • During this period, a contract interacting with the FeeContract can use the old fee (12 tokens) or the new fee (15 tokens), whichever is lower.

  3. Post-Grace Period:

    • After the grace period ends, all transactions must use the new fee (15 tokens).

These examples provide a snapshot of various functionalities within the FeeContract, illustrating the practical application of settings, updates, and processes related to managing application fees.

Last updated