Description

Develop a token with an integrated tax feature. This feature will collect tax in the destination-swapped token instead of the native token. This strategy is intended to mitigate distortion and selling pressure on the token while generating revenue.

We have previously developed a Crucible Contract that handles the token router functionality and custom fee logic; we have the Fiber Router that handles the DEX router logic. A combination of these two will result in Iron Tax contract listed below.

Diagram

graph TD;
    Token[Token Contract] --> TokenRouter[Token Router];
    TokenRouter -->|Wallet to Wallet Transfer| RegularTransfer[Regular Transfer];
    TokenRouter -->|Trade via DexRouter| TradeTransfer[Trade Transfer];
    
    RegularTransfer -->|Determine: Not a DexRouter Transfer| FeeLogic[Fee Logic for Regular Transfer];
    FeeLogic --> FeeInNative[Tax in Native Token];
    FeeInNative --> FeeCollector[Fee Collector];
    FeeLogic --> TransferAmount[Transfer Remaining Tokens];
    TransferAmount --> DesiredDestinationAddress[Desired Destination Transfer Address];
    
    TradeTransfer -->|Identify as DexRouter Transfer| DexRouterLogic[DexRouter Logic];
    DexRouterLogic --> SendToDexRouter[Send Tokens to DexRouter];
    SendToDexRouter --> DexPool[Dex Pool];
    DexPool --> BackToTokenRouter[Back to Token Router];
    BackToTokenRouter --> FeeInDestinationToken[Tax in Destination Token];
    FeeInDestinationToken --> FeeCollectionAddress[Fee Collection Address];
    BackToTokenRouter --> DestinationTokenPostFee[Post Fee Destination Token];
    DestinationTokenPostFee --> DesiredDestinationSwapAddress[Desired Destination Swap Address];

Explanation:

• Token to TokenRouter: The entry point where all transfers start.
• Wallet to Wallet vs. Trade Transfers: Branching logic based on whether the transfer is a regular wallet-to-wallet transfer or a trade via a DexRouter.
• Fee Logic for Regular Transfer:
  • Tax in Native Token: Shows the tax being taken in the native token and sent to the Fee Collector.
  • Transfer Remaining Tokens: The remaining balance post-fee is sent to the destination address.
• Trade Transfer Logic:
  • Identify as DexRouter Transfer: This step represents the token router identifying the transfer as a trade.
  • Send Tokens to DexRouter and Back: Illustrates the flow of tokens to the DexRouter, into the Dex Pool, and back to the Token Router.
  • Tax in Destination Token and Post Fee Destination Token: Similar to the regular transfer, but with the tax assessed in the destination token. It then splits into the fee being sent to the Fee Collection Address and the remaining destination tokens being sent to the swap address.

Multichain Token Standard

We will need to incorporate this with the Multichain token standard.

• Create master and client contract with tax logic
• Incorporate additional functionality such as pausable, mintable, burnable etc
• dexPool are configurable
• Fee addresses are configurable
  • In addition to dexPool addresses where fee is assessed, other addresses can be set where fees are removed or overwritten, for example no fee to stake, or no fee when using the token to pay platform fees etc.