After several consultations within the Telx Council and other parties, here is the final draft of the SAP proposal. The main changes are 1) the removal of any system selected “best” pool and so the user now has to select from a list of available pools which one to invest into. 2) the removal of any development cost recovery claw back option since that was generally felt unfair to the other liquidity providers.
…start doc
Single Asset Provision
TelxIP - TyAkemi
The following is a very high-level concept and will require some software development and detailed technical specification. However, there has been discussion with Grant Kee and his team and so a high level estimate of resource requirements has been included.
V1 – Initial draft 20Nov24
V2 – after review with Grant & Markus 25Nov24, & discussion with Telx Council
V3 – after comments from Telx Council 4Dec24
Final – after discussion from Telx Council meeting 12Dec24 – proposal loaded to Forum
Final.1 – amendments following concerns raised about the “system” nominated pool, references to which have all been removed; and
charging claw back for the facility, which it was felt was unfair to the general user and so may be seen as a deterrent 30Dec24 – resubmitted to council for review
- Abstract Summary
Currently Telx is supported by 6 Liquidity Pools (facilitated through Balancer), which enable miners to provide liquidity through a combination of a few specific assets and in return offer varying rates of rewards. However, this it is a complicated, multi-step process, which many potential users find restrictive and prohibits general participation in the platform. This in turn leads to reduced liquidity which can cause underlying issues with price volatility, difficulty trading and even price manipulation.
This proposal attempts to make the process of providing liquidity easier for the general user through simplifying the actual process, (two or three clicks), implementing the solution solely within Telx, and extending the number of assets that can be provided by the user, leading to reduction and minimisation of these underlying issues mentioned above.
This proposal is designed to be an extension to the current method of providing liquidity directly through balancer and NOT intended to be a replacement.
However, it can also be viewed as a useful stepping stone by increasing the functionality of the Tel app by incorporating and re-using the developed code modules and make those available to the Tel app , which currently cannot access any Dex’s where Telx Liquidity resides.
This proposal, if approved by the Telx council will then need to be approved by the Platform, Treasury and Compliance Councils.
- Background to the Problem
Personal Observations when using current Telx
I often have spare coin/token that I could provide as liquidity to gain APR (assuming the coins are all on Polygon – and if not, there is an additional step of Bridging to polygon)
Issues / Problems to overcome
- That coin may not be coins participating in 1 of the 6 current pools
- so first I have to swap – which is obviously quite easy to do but may require 1 (or 2 at most) swaps to get those coins into one of the participating 7 coins in the current pools (currently Tel, wBTC, wETH, wMatic/POL, DFX, USDC & BAL).
- I then have to decide in which Pool to invest – which is in practice a difficult decision due to:
- Varying rates of IL with respect to each coin – so need to understand how IL works
- This in turn boils down to a complex guess since you have to estimate how one coin will perform pricewise in relation to the other coin (over the timeframe in which you want to invest)
- Different rates of return from each Pool
- Different volume throughput / different fee generation
- potentially different rates of future reward allocation that could alter during the investment timeframe
So, all in all this is a fairly complex step and in itself can put people off participating!
- then its a 2-step process – which again the user needs to understand:
- Provide Liquidity to Balancer Pool
- Need to know the mechanics of that, - optimisation, and in what ratio to provide 2 / 3-coin combinations
- Then take LP token from Balancer & remember to Stake in Telx
- Necessitates jumping between platforms
Overall – quite an involved process, user needs to make a lot of decisions along the way, and so can be just “too hard“ for potential participants !
Not hugely complex once you get your head around the steps, but I’m sure off-putting to a number of users who just want to see some return for their coin.
- Specification of the Solution
Proposed Design Objectives for Single Asset Provision (SAP)
Simple User Interface – to attract more users and make it easier to deposit liquidity (3 clicks) so that Telx can take advantage of this increased liquidity provided.
Extending Liquidity provision to include coins not currently supported by the Balancer pools (automatic swaps would happen in the background)
This makes it easier for the user to provide LP and may even be extended as a in-app feature to enable mobile user to provide LP from the Tel app using the simplified 3-click concepts
Basic Idea
To provide Liquidity
- Connect your wallet to Telx
- Have a Telx form to select coin to use and amount of coin to invest (this can be used to calculate a $value to invest)
- System presents user with the current list of pools, highlighting the expected rewards to be received (based on the $Value/(TVL+$value)) from each pool at the time of investment
- User Selects the pool to invest in and confirms.
- This could be extended later to show more analytics for each pool (Stage 2)
To withdraw Liquidity
Give the user the option to withdraw an amount of Liquidity in the base coins of the Pool. This would also be done through Telx
- Connect your wallet to Telx
- Have a Telx form which lists the Pool(s) the user’s wallet is currently invested in
- Have a Telx form to specify a $amount or a LP percentage (scale from 1-100%) to withdraw
- User Selects the pool to withdraw from and confirms
To Claim Rewards
- Rewards are accumulated as now (every block) based on fixed rate of Total LP (determined as part of TELX Council rewards issuance) and can be withdrawn anytime
NOTE: this is not proposing any additional pools but shifting provision away from Balancer & Telx and making it directly through Telx
Mechanics
- User is providing Liquidity into a User Selected Pool that offers a known rate of return (at the time of investment)
- The “coin” being supplied can be valued into a monetary amount using current $value which is the value of Investment (“VOI”), which can be used to determine the rewards for each pool needed for the selection list
- The coin is then swapped to the relevant coins required for the selected pool in the proportions required by Balancer, generating a LPT quantity which is then automatically staked in Telx)
In the background
- The coin the user is providing is swapped (via maybe 1 or 2 routes into Tel and the other coin(s)
- That Liquidity is then directed to an actual pool based on the selection by the user preference generating LPTs
- These LPTs are automatically staked within Telx
To withdraw Liquidity
- The $amount or Percentage specified by the user is used to calculate a quantity of LTP to, first unstake from Telx and then automatically withdraw those LTP’s from the actual balance pool
-
Resource needs
After a high-level discussion with Grant and Markus and as a first stab estimate, they felt overall project timeline in the region of 2 months (excluding any dashboard development which they suggest undertake as a separate phase II)
Resources – 2 – smart contract developer and back-end developer
Development/Testing Hours – 30 productive hrs /person/wk – Total 480 hrs
Platform Council review required to determine if outsourced or can be handled in house, and if outsourced – by who ?
Also, some external security audit would be required if any new smart contract work is required – but that can only be determined once a more detail technical review is undertaken as to actual implementation solution
-
Financial requirements – cost
Treasury Council review and further discussion is required after Platform Council Review (see Feasibility Section 10 below)
-
Timeline (milestones and significant target dates)
Once Platform & Treasury/Compliance Councils review then a more accurate timeline can be provided - but estimate 2-3 months elapsed
-
Rational behind proposal
If the overall process is easier for the user, this will encourage new miners to participate leading to increased Liquidity, reduced volatility, & better trading prices
It will also expand the exposure of Telx and opportunities for new users onboarded through MNO’s in the future
Provide a useful first step to expose the concepts and benefits of Defi to new and existing users.
If the base work is done to implement this for Telx, then could provide a useful start point to extend Tel app using re-usable segments
-
Risk and mitigation strategy
The main risk with any software development is that it is buggy – but detailed Acceptance testing and a security audit, if required, should mitigate any potential risks
It has also been suggested that this proposal be supplemented with additional educational material on Liquidity Provision 101 , pointers explaining IL and other risks plus additional Pool Analytics (this last point being covered by Andrew’s proposal). Together these will lead to a deeper understanding of LP and work towards Telcoin’s overall mission to help educate new users.
-
Potential alternatives (if relevant)
The alternative is to reject this proposal, maintaining status quo, and so missing the benefits and advantages this proposal would bring to Telx
-
Feasibility (consider Legal, Technical, Economic, Financial, political impact)
Important Consideration 1: User Control - The existing facility to provide LP direct into 1 of 6 well defined balancer pools, though complicated, places complete onus of the individual for their investment decisions.
o User has to decide which pool to invest in, and
o User has to accept and understand the risks versus rewards aspects:
estimated fees,
estimated apr%, and
the risks associated with IL
The main drawback to be considered with this proposal is by offering this simpler and more streamlined method of providing LP, by definition, it takes away some of the user’s understanding on how Liquidity pools function. However this can be mitigated by beefing up the user
Important Consideration 2: Development – what is being proposed will require some smart contract development and back-end development. If the smart contract work can use existing smart contracts, then there may be some advantage in developing in house, and may not need an additional security audit. However, if there is not the development bandwidth available in-house then development may be outsourced to some external agency (tbd)
This consideration should be referred to Platform Council for a decision
Important Consideration 3: Cost – the cost cannot be accurately determined at this juncture. Also, it is not clear at this point how any costs will be covered, and out of which budget. Treasury Council to advise on this consideration
This consideration should be referred to Treasury Council for a decision
Important Consideration 4: Cost Recovery – I’ve left this consideration in the proposal for reference only. The idea of a clawback cost recovery was initiated by the technical team but after consultation within the Telx Council – it was thought not fair and a disadvantage to potential users
[*Some further thought needs to be given to the consideration of revenue claw-back in terms of trading fees or some other form of revenue generation through the user’s use of this SAP facility. Is there a mechanism where the user gets a guaranteed minimum rate of return (to make it an attractive ROI to the user but less than manually investing in a particular pool) and any return over that minimum gets split between the user and the remainder flows back into the Tel Treasury. *
Remember, the Liquidity provided by the user, is actually providing Liquidity into an actual pool (from the 6 currently in operation which have established apr%, so there may be scope for some form of clawback or cost-recovery by splitting the difference !
What I have suggested, as an example, is a 2:1 split of rewards. 2/3 goes to the user, 1/3 goes back to treasury as a development cost recovery claw back. So the user gets less than if they were to invest directly in the pools, but importantly still gets an attractive rate of return (better than the banks !) ]
-
Clear Implementation Plan – potential Conflicts and Dependencies
To be decided in consultation with the technical team
-
Metrics for success / KPI factors
The following metrics can be used to measure success
• Overall Total Liquidity
• Staked Liquidity in the new generic pool
• Overall Volume
• Fees
• User Adoption Levels
-
Proposal monitoring / development implementation checkpoints
Periodic checks on number of minors using the generic pool and volume of Liquidity provided – should both increase over time
-
Overall Telcoin Mission alignment and Values
There is close alignment with the overall objects of Telx
…end doc
