Submit TELxIP proposals to this channel for deliberation, feedback, and contestation by the community and the TELx Council.
TELxIP Authority
The TELx Council may use the TELxIP process to set, enforce, revise:
TELx TEL Allocation and Harvesting Rules: Make or change the rules that regulate TEL within TELx to be harvested by liquidity miners.
TELx Provisioning, Construction and Maintenance Rules: Make or change the rules that plan, finance the construction of new system improvements and maintenance to existing TELx infrastructure.
TELx Communication and Information Rules: Make or change the rules that structure how information is shared and communicated TELx by the TELx Council with the community.
TELxIP Proposal Template
Abstract:Please share a brief summary 2-3 of the proposed changes.
Specification:Please give a complete description of the changes that will be made.
Rationale:Please provide a rationale for the changes.
Implementation:Please provide details related to who will take what steps to implement the changes.
Transactions:If your proposal involves transferring TEL, please specify the amount and destination.
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
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, and extending the number of assets that can be provided by the user, leading to reduction and minimisation of these underlying issues.
However, in doing so, the proposed solution will remove some of the decision making away from the user and may prevent the user from fully understanding the inherent risks in providing liquidity (see section 10 for more detail).
A Compliance Council review of this proposal needs to happen first, to decide whether Telcoin as a platform wants to move in that direction
If the Compliance Council approve the idea then then nest steps are to undertake a Platform Council Review and finally a Treasury Council Review before formally submitting final proposal to Telx Council for voting.
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
o 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:
o 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)
o Different rates of return from each Pool
o Different volume throughput / different fee generation
o 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:
o Provide Liquidity to Balancer Pool
 Need to know the mechanics of that , - optimisation, and in what ratio to provide 2 / 3 coin combinations
o 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 (one click) so that Telx can take advantage of this Generic Liquidity provided.
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 simple 1-click concepts
Basic Idea
To provide Liquidity
Connect your wallet to Telx
Have a Telx form to select coin and amount to invest
System present user with best option of a Pool with an expected return (not guaranteed)
Click submit.
Need some sort of dashboard so user can track their investment NOTE – after technical discussion with Grant & Markus – it was felt that this may be better done under a phase 2 proposal
To withdraw Liquidity
Give the user the option to withdraw Liquidity in Tel.
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
It will have to be decided through Telx & Treasury Council whether to increase overall Tel issuance to provide rewards for this pool or re-adjust current Tel issuance levels to accommodate this additional feature.
Mechanics
User is providing Liquidity into a System Selected Pool that offers an estimated rate of return
The “coin” being supplied can be valued into a monetary amount using current $value which is the value of Investment (“VOI”)
Using the premise described below to determine the actual pool being supplied with the Liquidity, then based on the current total Liquidity of that pool, it is possible to determine an indicative expected share of rewards, which can be presented to the user as an apr%. (allowing for Revenue cost recovery split – see 4th consideration under Section 10 below)
The user can decide whether or not to invest based on a simple decision “am I happy with that return” ! Refer to Table in Appendix as an worked example.
In the background
The coin the user is providing is swapped (via maybe 1 or 2 routes into Tel and the other coin
That Liquidity is then directed to an actual pool based on the following premise
Premise - Not all liquidity pools are equal
Different pools have varying transaction volume throughput
Different pools have varying liquidity requirements
o Calculate each pool’s ratio of Liquidity/transaction vol (Liq/TrxVol ratio)
Using his ratio should enable pools to be “balanced” by bringing each pool’s Liq/TrxVol to as close a similar level as possible
 New Liquidity provision should be directed to pools with a lower Liq/TrxVol ration to bring them up to balance
 When the user comes to withdraw all or part of his liquidity – then the LP tokens are unstaked from that same pool
This idea would obviously require some degree of smart contract work and UI development so will require some technical input for feasibility and costing (see below)
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 Compliance Council approval is given (regarding direction) and Platform & Treasury Councils review then a more accurate timeline can be provided
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.
Risk and mitigation strategy
One of the main risks to be considered is by taking away some of the decision making from the user, and if their particular investment does not perform to their expectations then this could lead to user dissatisfaction and potential reputational damage to the brand.
This could be mitigated by offering the user a pick-list of certain investment strategies to select from. However, that would lead to a different type of complex decision making which detracts from the objective of providing a simply approach. It would also add to the development timeline and cost.
Potential alternatives (if relevant)
A suggestion coming after initial pitch to the Telx Council was, rather than take the decision away from the user in terms of pool selection – was to make a more intuitive UI to Telx and present the user with a list of pools plus expected apr (as can be provided for now), and have the user self select which pool to invest in and then have some smart contract work to remove the jumping into Balancer and back to stake the relevant LP tokens into Telx. Obviously the same “smarts” – would be to facilitate withdrawal of Liquidity. One advantage of this is if we extend the pools to another provider, say Quickswap, or Base – then the smart contracts would handle and direct LP to the relevant provider. So there is some merit in this alternative as well.
It is also possible to present the user with a choice of potential returns based on all the pools and let them select which pool to invest in – but that would always favour the pool with the lowest Liquidity (since that provides the highest rewards relative to the other pools) and would remove the benefit of considering the transaction volume going through the pools. A side affect would also be that using this method (simply adding to the pool with the lowest liquidity/highest return) would result in a greater loss of expected apr% since that would be constantly being reduced as extra liquidly is always being added – and so the likelihood of user disappointment relating ot poor performance would be increased.
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 decision- making and so the question is “does Telcoin want to move in that direction”?
This consideration should be referred to Compliance Council for a decision
• 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 and is dependent on the pending decisions from the first 2 considerations. Also, it is not clear at this point how any costs will be covered, and out of which budget.
This consideration should be referred to Treasury Council for a decision
• Important Consideration 4: Cost Recovery – 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 !)
This consideration should be referred to Compliance Council to determine whether this is legally / politically feasible.
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
Using the example above the user has the equivalent of $1000 to invest. This is the current value of the coin the user wants to use to provide Liquidity
Applying the “best pool” premise (see Section 3 above) the system calculates that based on current pool data – the wTel/Pol pool has the “best” / lowest Liquidity/Transaction Volume (Liq/TrxVol) ratio and offers an expected apr% return to the user of 13.12%.
