# 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** <a href="#example-1-setting-and-updating-the-base-fee" id="example-1-setting-and-updating-the-base-fee"></a>

**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** <a href="#example-2-developer-fee-setting" id="example-2-developer-fee-setting"></a>

**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$$

     &#x20;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** <a href="#example-3-distributing-collected-fees" id="example-3-distributing-collected-fees"></a>

**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.