Locking value of TFT is technically hard, because every TFT could be locked against a different value. This means the lock price becomes part of these new tokens, thus turning them into NFT’s, something which is very hard to scale.
I’ve been pondering about making deployment payments more accessible, in a slightly different way, but it is also applicable here. The idea is as follows:
We start by introducing “assets” on chain. An asset is a token anyone can create, with some metadata (e.g. digits for one token), which can be minted and burned by the issuer. This is not unlike how TFT is currently a token on the stellar blockchain. In a similar fashion, operations on these “assets” are transactions on TFChain, and thus require a minimal amount of TFT to pay for the transaction fee.
Then, we introduce the liquidity pool concept. A research project already exists from a separate organization to add the uniswap V1 protocol directly on substrate based chains, working with these “assets”, so this is something which seems doable (the impact of transaction volume on the chain size should be investigated first of course).
We also generalize the current bridge module, to not only support TFT coming from stellar, but rather make it generic over the token (which would then require an asset to be created on TFChain). Similar to how tokens exist on different chains.
Lastly, we add an optional field on contracts specifying which asset to use to pay for the contract. If this is not set, the user pays in TFT, like it currently is.
Putting it all together:
The DAO creates an asset for “some currency”. In the current case this would be some kind of USD stable coin. A bridge is set up from this stable coin to TFChain and in reverse. DAO is used to create the asset to gain improved governance on the asset (i.e. no funny business where someone just destroys the asset or freezes it for certain people).
The DAO then sets up a liquidity pool for this asset to TFT. Again the DAO sets it up so there is governance in the parameters of the pool. The pool is funded with some initial amount of asset and TFT.
The DAO approves this asset to be used in contract payments.
Now when a user creates a contract, he can specify to be billed in the “USD” asset. At payment time, calculations are done as normal to get the amount of TFT the user pays. If no alternative payment currency is set on the contract, the payment happens as normal (TFT is taken from the account of the user and distributed to the receivers). If Asset is set, an additional step is done where the exact amount of TFT is purchased from the pool, which is then transferred to the receivers. The amount of Asset required will depend on the price of the pool at that time.
There might be marginal differences on the charged price in USD based on the price in the pool (as opposed to being actually fixed since we calculate cost in USD). However this seems like a worthwhile tradeoff for a truly generic solution. For instance, it is very easy to also use the same flow to allow payment in ETH’s, DOT’s, XLM’s, … All that is needed is a bridge implementation and the DAO doing some calls for the required setups.
Notes:
Exchange price of the Asset is governed by the liquidity pool on TFChain in this scenario. This price can and will be different from the “official” price. Specifically, multiple swaps in the same block might also increase the price. This should not pose a problem however:
- Arbitrage can (and will) happen, so price of the liquidity pool will be maintained very close the the official price
- Swaps for contracts will be for small amounts (since payments are regular). Even if a large amount of swaps for contracts happen in the same block, a sufficiently large liquidity pool (which again is actually not that large) will be an effective buffer here.
