Example FeeContract Interactions

Learn how to interact with Haven1’s fee contracts for decentralized applications.

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=30$

     tokens.

   • 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=6$ shares.

   • Share of each channel:

     • Channel A: $1/6× 1000 =166.67$ tokens.

     • Channel B: $2/6×1000=333.33$ tokens.

     • Channel C: $3/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.