Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

💵 Specify the tax distribution mechanism #369

Open
bdeneux opened this issue Sep 22, 2023 · 0 comments
Open

💵 Specify the tax distribution mechanism #369

bdeneux opened this issue Sep 22, 2023 · 0 comments
Assignees

Comments

@bdeneux
Copy link
Contributor

bdeneux commented Sep 22, 2023

📄 Purpose

NOTE: I first started by creating a branch with it's associated PR with a smart contract intended for the distribution of the tax according to the planned token model defined in whitepaper, but I finally decided to create an issue to initiate a discussion on the architecture of it.

Based on the token model specified in whitepaper and discussion on this issue, we will need a mechanism to distribute the tax collected from the workflow execution to a list of recipients including the possibility to burn a part of this tax.

🧮 Proposed solution

To dispatch the responsibility from the workflow contract execution, I propose to create a smart contract that will take care of the tax distribution. A smart contract that can be only instantiated and updated by governance vote (for our needs), and allowing to configure and update the list of recipients and burn amount.

To resolve rounding and accuracy issue, I propose to set a default recipient and a list of recipient with their corresponding token distribution ratio, after distribution of total token on all destination, the remaining token will be transfer to the default recipient. It's allow also to add or remove recipient without send the whole list of recipient and ratio, unless necessary.

For exemple, based on the this figure, when workflow is executed, 3% tax of the total cost will be transferred to the tax distribution contract. Contract is configured with one destination: burn, set to 66.6%, and the community pool as a default recipient. Once 66.6% of token has been burnt, the remaining token is sent to the default recipient (set to the community pool). We can also configure recipient with a wallet address.

🔎 Example

Contract schema definition example
use cosmwasm_schema::{cw_serde, QueryResponses};
use cosmwasm_std::Decimal;

/// InstantiateMsg is the default config used for the tax distribution contract.
///
/// This contract is intended to be stored with `--instantiate-nobody ` args to prevent only the
/// governance that is allowed to configure and instantiate this contract and be set as the contract
/// admin.
#[cw_serde]
pub struct InstantiateMsg {
    /// Configure the destination of the remaining tokens after distribution to other recipients
    /// (defined in `destinations`).
    default_recipient: Recipient,
    /// Define the distribution rate of tokens to the intended recipients.
    /// The total rate sum should not exceed 1.
    destinations: Vec<Destination>,
}

#[cw_serde]
pub enum Recipient {
    /// Send token to the community pool.
    CommunityPool,
    /// Burn token.
    Burn,
    /// Send token to a specific wallet address.
    Address(String),
}

#[cw_serde]
pub struct Destination {
    /// Recipient of tokens
    recipient: Recipient,
    /// Set the token rate to receive for this recipient.
    /// Value should be between zero exclusive and one exclusive.
    ratio: Decimal,
}

/// Execute messages
#[cw_serde]
pub enum ExecuteMsg {
    /// # Distribute
    /// Distributes the tokens received from the transaction to the recipients following
    /// the configured apportionment.
    Distribute,

    /// # UpdateDefaultRecipient
    /// Change the default recipient used for distribute remaining token.
    ///
    /// Only contract admin can update the default recipient.
    UpdateDefaultRecipient { recipient: Recipient },

    /// # UpsertDestinations
    /// Add new recipients for receiving token with it's corresponding ratio.
    /// If one of recipient already exist and configured, the ratio is updated.
    /// Don't forget that the total ratio already configured shouldn't exceed 1, but can be less 
    /// than 1, since the remaining token will be transfer to the default recipient.
    ///
    /// Only contract admin can add or update destinations.
    UpsertDestinations { destinations: Vec<Destination> },

    /// # RemoveRecipients
    /// Remove recipients from the tax distribution.
    ///
    /// Only contract admin can remove recipients.
    RemoveRecipients { recipients: Vec<Recipient> },
}

/// Query messages
#[cw_serde]
#[derive(QueryResponses)]
pub enum QueryMsg {
    /// # Destinations
    /// Returns the current configuration for all tax distribution destinations with their
    /// corresponding ratio.
    #[returns(DestinationsResponse)]
    Destinations,
}

/// # DestinationsResponse
#[cw_serde]
pub struct DestinationsResponse {
    /// The current configured default recipient for remaining token after distribution.
    pub default_recipient: Recipient,
    /// All recipients with their corresponding token ratio.
    pub destinations: Vec<Destination>,
}

❓ Remarks & Questions

This is only a preliminary contract definition but maybe it doesn't cover all ours needs, I'm waiting your feedback to see if is missing some needed features.

Other solution is possible for the tax distribution :

  • Included in the workflow contract, avoiding create another contract but increase responsibility of this one.
  • Contract like this one proposed but, to limit gas fees, implement a withdraw feature for address recipient, this avoid transfer token in a one transaction and do the same like is done with the distribution module allowing recipient to withdraw their token. Is not possible to do the same either for the burn and the community pool, since no one can withdraw the community pool except the governance (maybe a solution).
  • Namely that the execution of a workflow will remunerate all the actors who are allowed to provide the data to the workflow, it would perhaps be wise to integrate the distribution of the tax at the same level as the remuneration distribution.
@AnjaMis AnjaMis moved this to 📋 Backlog in 💻 Development Sep 29, 2023
@ccamel ccamel moved this from 📋 Backlog to 📆 To do in 💻 Development Nov 16, 2023
@github-project-automation github-project-automation bot moved this to 📋 Backlog in 💻 Development May 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: 📋 Backlog
Development

No branches or pull requests

4 participants