Service Revenue Sharing Contract

1. Overview

The Service Revenue Sharing Contract enables a DAO to:

• Collect service revenue on-chain
• Record payments transparently
• Allocate revenue between stakeholder groups
• Distribute revenue automatically via smart contract
• Allow beneficiaries to claim revenue directly

This module is designed for DAOs that generate recurring or transactional revenue, such as subscription services, service packages, or marketplace activities.

Revenue can be distributed to:

• LP Holders (Liquidity Providers holding DAO LP tokens)
• Order Handlers (contributors supporting sales and service execution)

2. Business Logic

The Service Revenue Sharing mechanism operates as follows:

1. A DAO provides services and collects service fees from users.
2. Users pay using predefined supported tokens.
3. Each payment is recorded on-chain via the smart contract.
4. Revenue is periodically calculated.
5. Withdrawable allocations are computed for:
   • LP Holders (based on LP ownership ratio)
   • Order Handlers (based on supported orders)
6. Eligible wallets claim their revenue directly from the contract.

All revenue calculations are recorded on-chain for transparency.

3. Contract Architecture

The module consists of two smart contracts:

• ServiceRevenueSharing
• RevenueCalculator

The RevenueCalculator contract handles token conversion and distribution calculations.

4. Deployment Parameters

When deploying the Service Revenue Sharing contract, the following parameters must be provided:

xdaoAddress

The DAO’s XDAO contract address.

currencyAddresses

An array of supported token addresses accepted for service payments.

orderHandlerPercentage

The percentage of total revenue allocated to Order Handlers.

LPHolderPercentage

The percentage of total revenue allocated to LP Holders.

revenueCalculatorAddress

The address of the deployed RevenueCalculator contract.

Important constraint:

orderHandlerPercentage + LPHolderPercentage must be less than 100%.

5. Core Smart Contract Functions

5.1 Buy Subscription Function

Purpose: Records service revenue when a user purchases a DAO service.

Behavior:

• Payment is transferred directly to the DAO treasury.
• Revenue is recorded in the smart contract.
• Transaction data remains on-chain for auditability.

5.2 Calculate Revenue Share Function

Purpose: Calculates withdrawable revenue for each LP Holder and Order Handler.

The calculation considers:

• Total revenue collected
• Token conversion rates
• LP balances and total LP supply
• Order-handler mappings
• Predefined revenue percentages

Simplified calculation flow:

1. Convert all token revenues into base token (e.g., USDT equivalent).
2. Compute revenue pool for LP Holders.
3. Compute revenue pool for Order Handlers.
4. Allocate revenue proportionally.
5. Determine withdrawable amounts per token based on DAO treasury composition.

All calculations are stored on-chain.

5.3 Claim Function

Purpose: Allows LP Holders and Order Handlers to claim allocated revenue.

Process:

1. Connect wallet.
2. Call claim function.
3. Confirm transaction.
4. Revenue is transferred to wallet.

Claim events are recorded on-chain.

6. DAO Role Workflows

This section focuses only on DAO roles (no internal admin flows).

6.1 DAO Organizer Workflow

The DAO Organizer (or authorized executor) is responsible for:

• Deploying the contract
• Adding the contract to DAO permitted list
• Configuring supported currencies
• Configuring Order Handler addresses
• Executing revenue calculation periodically

Monthly revenue process:

1. Retrieve LP holder list from chain explorer.
2. Upload LP list to DAO interface.
3. Input token exchange rates.
4. Execute “Calculate Revenue Share”.
5. Confirm transaction.

6.2 LP Holder Workflow

1. Connect wallet to Kambria platform.
2. Navigate to selected DAO.
3. Open Service Revenue Sharing tab.
4. Click Claim Revenue.
5. Confirm transaction.

Revenue is transferred directly to the connected wallet.

 

6.3 Order Handler Workflow

Order Handlers:

• Are pre-approved addresses configured by DAO.
• Earn revenue percentage based on supported orders.
• Claim revenue via the same interface as LP Holders.

 

7. Revenue Conversion Model

To ensure fair multi-token distribution:

• All revenue is normalized to a base token (e.g., USDT).
• DAO treasury token composition is considered.
• Withdrawable amounts are distributed proportionally.

Example:

If DAO treasury holds:

• 60% USDT
• 40% KAT

Then LP allocation is distributed:

• 60% in USDT
• 40% in KAT

Exchange rates are provided during revenue calculation execution.

8. Governance and Permissions

The Service Revenue Sharing contract:

• Must be added to the DAO permitted contract list.
• Operates under DAO governance framework.
• Should transfer ownership from deploy wallet to DAO-controlled address.
• Does not custody funds outside the DAO treasury.

9. Testing

The module has been tested via:

• Unit testing
• Manual testing
• Multi-token scenarios
• Revenue distribution edge cases

 

10. Design Intent

This contract demonstrates:

• Transparent on-chain revenue tracking
• Automated distribution logic
• Incentive alignment between LP holders and contributors
• DAO-native monetization infrastructure

It forms a core component of Kambria DAOs’ product and service monetization framework.