🤑 Implements Token model

[amimart]

Purpose

Since the publication of the new Token model, we need to implement it in the software.

Considerations

Here are some ideas that should be considered regarding the implementation, and that of course can/must be discussed:

x/mint module

Since this module name is first a standard cosmos sdk module, block explorers and other UIs apps rely on the specification coming from the cosmos sdk, which is conflicting with ours. So it may be relevant to implement inflation mechanisms in a different module name, for example: x/inflation. This way, block explorers won't be able to display wrong informations.

Please don't hesitate to mention any considerations you would be regarding implementation.

[bdeneux]

📝 Module implementation

Concerning @amimart remark about the x/mint module, I was initially agree with that but after reflection I think the main information used by explorer about the mint module is the yearly inflation rate. Since this information can be calculated, I think we could keep it accessible and use the mint module like today. But let's discuss about it ;).

Considering we don't know now the name of the module I will use x/mint naming.

x/mint

Here the params and minter configuration that can be configured :

- Params
    - inflationCoef : 0.02
    - boundingAdjustment: 2.5
    - targetBoundingRatio : 0.66
    - blocksPerEpoch : 17280 **Considering 5s per / block **
- Minter :
    - inflation
    - epochStakingRewardTarget

At each epoch, minted token + tax pool is added to the fee collector and is distributed throw the x/distribution module. Validator must withdraw their tokens.

x/tax

I purpose to add a new module to manage the tax pool with a minimum responsibility. This is only a module to hold the tax pool and allow other module to get all or a part of this pool. The responsibility of the distribution and burning should be the part of the x/mint module.

It's allow the x/mint module, at the end of epoch to calculate the minting amount depending on the tax pool and allowing distribute to the validator and delegator or burn.

x/tax module has only one transaction allowing receive token to be added to the tax pool. I think it's the orchestration service that will have the responsibility to calculate the amount of tax to be send to the tax module inside a smart contract.

💡 Other idea

Semi-Smart-Contract

Keep the minting module like explain above but instead of adding a new tax module, manage the tax pool throw a dedicated smart-contract. That implies to know inside the x/mint module the instance address of tax pool contract and the interface to communicate with it. We will need to execute transaction to transfer token from contract to the mint module / fee collector. I don't know how that can be work inside the x/mint module.

Full Smart-contract

Implement the mint calculation inside a set of smart contract (one for the tax and one for the mint), but since smart contract cannot be executed at each block (or I don't know how to do this), we will need to call corresponding smart contract throw a module (knowing instance address and interface also).

Let's discuss about that :).

[tpelliet]

Implementation alternative

Following a discussion with @bdeneux, it seems there's another way to implement the Token model.

Current mechanism

If we think in stages, at the end of each daily epoch you should have:

1. Calculation of SRT (based on bonding)
2. Distribution of the tax pool, supplemented by the mint to reach the SRT if tax pool < SRT. In this case SRT = tax pool + mint.
3. If tax pool > SRT then SRT is distributed from the tax pool and the excess remaining after distribution (= tax pool - SRT) is burnt.

Alternative

The alternative removes the tax pool by:

• Burning all taxes
• Minting all staking rewards

This provides a similar end result.
If for exemple during a day there is 2 tokens collected as tax and the staking reward should be 10, it is almost the same to:

• Redistribute 2 and mint 8, or
• Burn 2 and mint 10

We have the same end-result, with additional benefits:

• No need to manage daily epochs, everything is on a per-block basis. Each workflow includes a tax that is burnt.
• There is no need for a pool of tokens to be collected and redistributed.
• We can use the cosmos x/mint "almost" as it is. The minting only depends on two variables: total supply & bonding ratio.
• It may also be a good legal argument in case tokens holders are accused to get some revenue from illegal activity that may happen in the network. With a burn/mint mechanism this argument is harder to make than with a redistribution mechanism.

Regarding the params it's pretty similar, everything is simply converted on a per year basis instead of daily:

- Params
    - inflationCoef : 7.3
    - boundingAdjustment: 2.5
    - targetBoundingRatio : 0.66
    - blocksPerYear : 6307200 **Considering 5s per / block ** (or 6311520 if 365.25 days per year..)
- Minter :
    - inflation

Last note, the implementation should consider the ability to define multiple taxes, with different destinations: burn, address or community pool.

Proposed workflow tax parameters for mainnet launch:

• 2% burnt
• 0.5% for association treasury
• 0.5% for community pool

[ccamel]

I broadly agree with the alternative approach of a block calculation proposed by @tpelliet. However shifting from a daily basis mechanism to a per-block basis is not a mere change in frequency; it introduces slightly differences in how values compound and adjust over time. Indeed, with a per-block mechanism, any changes (like rewards, burns, or mints) are compounded every block. Over the course of a day, these small changes can accumulate and diverge from a single daily adjustment. If rewards are distributed on a block-by-block basis, this can lead to specific behaviors that are different from daily distributions. Before going any further with the implementation, I'd like to see this frozen in the whitepaper on approval. So let it be written so let it be done.

Last note, the implementation should consider the ability to define multiple taxes, with different destinations: burn, address or community pool.

Yes. So relevant. 😌

[ccamel]

I think it's the orchestration service that will have the responsibility to calculate the amount of tax to be send to the tax module inside a smart contract.

Instead of "calculate", it's more about "provisioning" for the execution.

Here are some thoughts:

Upon the completion of a workflow, we determine its real execution cost. At this point, we first evaluate the taxes tied to the workflow, leading to the burning of some tokens and distributing others to the association treasury and community pool based on tax policies. Subsequently, rewards are allocated to all involved parties, including service and data providers. I believe here that every economic player, be it providers or the entity collecting taxes, should considered the same.

To elaborate:

• Prior to launching the workflow, users are required to deposit a specified token amount into an escrow smart contract. This deposit is expected to cover the workflow execution costs and any potential additional taxes.
• After the workflow's conclusion, the escrow determines both the real execution cost and the relevant taxes.

Hence, given that the Pactum smart contract is presently seen as the enforcer of a contract's effects, binding the user to all stakeholders during the workflow execution, it seems fitting for it to also oversee taxation. However, while calculation and distribution strategies might vary across Zones, the tax policy should remain consistent throughout all Zones, given its superior nature. Something to think about...

[ccamel]

What's great about the mint & burn approach is that the 2 contracts (or modules) can be fully dissociated, so you can develop one before the other, especially the mint.

[tpelliet]

Let us recap and agree collectively on the approach before editing the whitepaper.

We have 3 types of actions regarding tokens: transfer mint burn
And we have 2 different taxes to be enforced on the Pactum side:

• A 2% tax to compensate for inflation, this one will be burnt
• A 1% tax for the commuity pool, this one will be transfered (the transfer destination address and tax value should be editable through governance)

When a workflow is initiated, X provisionned tokens are transfered from the consumer to the escrow.
Then, the execution price Y is determined:

• (X-Y) is transfered back to the consumer
• Y*0.97 is transfered to the providers
• Y*0.02 is burnt
• Y*0.01 is transfered to the community pool

The mint is calculated on a per-block basis and is completely independant from any workflow that may or may not occur. Taxes don't influence the mint. The only variable on the mint side is the bonding ratio. The rest are fixed parameters that can only be changed by governance.

Do you agree @ccamel? Do you need anything else to go forward on the implementation @bdeneux?

[bdeneux]

Thanks @tpelliet for this clarification. So at this moment, the mint module's PR (#439) is ready for review since, like you say, it's completely independent from workflow and taxes.

I'm just wondering about the accuracy of the transfer, depending on the workflow cost, taking a small percentage of tokens (2% for burn and 1% for the community pool) on the cost of the workflow can cause trouble if the precision of uknow is not enough, we would be forced to either have a minimum or zero amount to distribute or burn. But it depend of the average workflow cost, I think we need to consider this.

[tpelliet]

Interesting, yes it needs to be considered.

Let's do a quick worst case scenario:

1. Token value get very high, let say 5 billion valuation: $25 per token.
2. A very small workflow with a $0.01 value is initiated: 0.01/25=0.0004 KNOW (400 uknow).
3. The 1% tax is then 4 uKNOW

Even with such extremes, the tax doesn't go to zero.
It seems that if the result of the tax calculation is not an integer it can be truncated without significative impact on the tax burnt/collected.