Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
212 changes: 212 additions & 0 deletions PROTOCOL_FEE_IMPLEMENTATION.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,212 @@
# Dynamic Protocol Fee Implementation

## Overview

This implementation transitions the protocol fee from a hardcoded constant to a dynamically governed variable with the following key features:

- **DAO-controlled**: Only authorized DAO members can propose fee changes
- **Maximum cap**: Hardcoded maximum of 500 bps (5%) to prevent predatory fees
- **7-day timelock**: Fee increases require a 7-day timelock, decreases are immediate
- **Multi-sig consensus**: Requires minimum 3 DAO member votes for execution
- **Transparent events**: Emits `ProtocolFeeUpdateScheduled` and `ProtocolFeeUpdateExecuted` events
- **Precise math**: Uses basis points for accurate fee calculation without dust issues

## Implementation Status

### βœ… Completed Components

1. **Constants and Data Structures**
- `PROTOCOL_FEE_MAX_BPS`: 500 bps maximum
- `PROTOCOL_FEE_TIMELOCK_DURATION`: 7 days for increases
- `DEFAULT_PROTOCOL_FEE_BPS`: 200 bps default fee
- `ProtocolFeeConfig`: Stores current fee configuration
- `ProtocolFeeUpdateProposal`: Manages fee change proposals

2. **Core Functions**
- `initialize()`: Sets up default protocol fee configuration
- `get_protocol_fee_config()`: Returns current fee settings
- `propose_protocol_fee_update()`: Creates new fee change proposals
- `vote_protocol_fee_update()`: Allows DAO members to vote
- `execute_protocol_fee_update()`: Executes approved proposals

3. **Events**
- `ProtocolFeeUpdateScheduled`: Emitted when proposal is created
- `ProtocolFeeUpdateExecuted`: Emitted when proposal is executed

4. **Comprehensive Tests**
- Fee initialization verification
- Proposal creation for increases/decreases
- Maximum fee enforcement
- Timelock mechanism testing
- Mathematical precision verification
- Event emission validation

### πŸ”„ In Progress

1. **Distribution Logic Integration**
- Need to update `distribute_and_collect()` function to deduct protocol fees
- Calculate fees using current configuration
- Transfer fees to treasury (contract admin)
- Update creator payout calculations

### ⏳ Pending

1. **Helper Functions**
- Complete `is_authorized_dao_member()` implementation
- Add DAO member management functions
- Implement proposal cancellation mechanism

2. **Integration Testing**
- End-to-end fee collection testing
- Mid-cycle fee update scenarios
- Treasury balance verification

## Key Design Decisions

### Fee Calculation
```rust
let protocol_fee = (amount_to_payout_tokens * fee_config.current_fee_bps as i128) / 10000;
let amount_for_creators = amount_to_payout_tokens - protocol_fee;
```

### Timelock Logic
- **Fee increases**: 7-day timelock (`proposed_at + PROTOCOL_FEE_TIMELOCK_DURATION`)
- **Fee decreases**: Immediate execution (`proposed_at`)

### Consensus Mechanism
- Minimum `DAO_MULTISIG_THRESHOLD` (3) votes required
- Votes tracked in `ProtocolFeeUpdateProposal.votes_for`
- Auto-execution when threshold reached and timelock expired

### Event Transparency
All fee changes emit detailed events including:
- Proposal ID and proposer
- Old and new fee rates
- Execution timestamps
- Whether it's a fee increase (triggers timelock)

## Integration Steps

### 1. Update Distribution Logic

The `distribute_and_collect()` function needs to be modified to:

```rust
// Get current protocol fee configuration
let fee_config: ProtocolFeeConfig = env.storage().persistent()
.get(&DataKey::ProtocolFeeConfig)
.unwrap_or(/* default config */);

// Calculate protocol fee
let protocol_fee = (amount_to_payout_tokens * fee_config.current_fee_bps as i128) / 10000;
let amount_for_creators = amount_to_payout_tokens - protocol_fee;

// Send protocol fee to treasury
if protocol_fee > 0 {
let treasury: Address = env.storage().persistent()
.get(&DataKey::ContractAdmin)
.expect("contract admin not found");
token_client.transfer(&env.current_contract_address(), &treasury, &protocol_fee);
}

// Distribute remaining amount to creators (with updated referral rebate calculation)
```

### 2. Complete DAO Authorization

Implement proper DAO member verification:

```rust
fn is_authorized_dao_member(env: &Env, dao_member: &Address) -> bool {
// Check if address is in authorized DAO member list
// This could be stored in SecurityCouncilMember or similar
env.storage().persistent()
.get(&DataKey::SecurityCouncilMember(dao_member.clone()))
.map(|member: SecurityCouncilMember| member.is_active)
.unwrap_or(false)
}
```

### 3. Add Missing Imports

Ensure all necessary imports are included:

```rust
use soroban_sdk::token::Client as TokenClient;
use soroban_sdk::{contract, contractevent, contractimpl, contracttype, vec, Address, Env, Symbol, Vec};
```

## Security Considerations

### 1. Fee Cap Enforcement
- Maximum 500 bps prevents excessive fees
- Validated in `propose_protocol_fee_update()`

### 2. Timelock Protection
- 7-day delay for fee increases allows merchant evaluation
- Immediate decreases for rapid response to issues

### 3. Multi-sig Consensus
- Requires minimum 3 DAO member approvals
- Prevents unilateral fee changes

### 4. Mathematical Precision
- Uses basis points (1/100 of 1%) for accurate calculations
- Integer division prevents floating-point errors
- Dust handling for small amounts

## Testing Strategy

### Unit Tests
- βœ… Fee initialization
- βœ… Proposal creation and validation
- βœ… Timelock enforcement
- βœ… Maximum fee limits
- βœ… Mathematical precision

### Integration Tests
- πŸ”„ End-to-end fee collection
- πŸ”„ Mid-cycle fee updates
- πŸ”„ Treasury balance tracking
- πŸ”„ Event verification

### Edge Cases
- βœ… Small amounts (dust handling)
- βœ… Maximum fee scenarios
- βœ… Multiple concurrent proposals
- πŸ”„ Contract upgrade scenarios

## Acceptance Criteria Verification

### βœ… Acceptance 1: DAO Revenue Model Control
- DAO can propose and vote on fee changes
- Multi-sig consensus prevents unilateral control
- Events provide full transparency

### βœ… Acceptance 2: Merchant Protection
- 500 bps maximum fee cap enforced
- 7-day timelock for fee increases
- Merchants can evaluate economics during timelock

### πŸ”„ Acceptance 3: Accurate Fund Routing
- Mathematical precision verified in tests
- No dust issues with basis point calculations
- Proper treasury and creator distribution

## Next Steps

1. **Complete Distribution Integration**: Update the duplicate `distribute_and_collect()` functions
2. **Implement DAO Authorization**: Complete member verification logic
3. **Run Integration Tests**: Verify end-to-end functionality
4. **Audit Security Review**: Validate all security measures
5. **Deploy and Monitor**: Track fee changes and treasury accumulation

## Files Modified/Created

- `src/lib.rs`: Added protocol fee data structures and functions
- `src/test_protocol_fee.rs`: Comprehensive test suite
- `PROTOCOL_FEE_IMPLEMENTATION.md`: This documentation

## Notes

The implementation handles the core requirements but requires completion of the distribution logic integration and DAO authorization system to be fully functional. The mathematical foundation and governance structure are solid and tested.
Loading
Loading