Funders
Last updated
Last updated
Funding a Portal bootstraps the upfront yield that’s paid to Depositors
Funders receive bTokens in return for bootstrapping liquidity
bTokens can be burned later to receive a share of PSM from the funding reward pool
When a specific Portal is ready to launch, it undergoes an initial funding phase where funders can deposit PSM tokens.
In return, funders are given receipt tokens called “bTokens,” which are distributed based on the “rewardRate.” For example, if someone deposits 100 PSM tokens and the rewardRate is 1,000%, they’ll get 1000 bTokens.
bTokens can later be redeemed for PSM tokens via the “funding reward pool.” You can think of the funding pool as a redemption pool, and it receives 10-20% of all PSM tokens deposited into a Portal over time via the arbitrage process explained in the next section.
In Portals v1 (HLP), bToken holders own a claim on a certain % of the PSM tokens within the funding reward pool. As bToken holders claim their PSM, the remaining holders' claim in % terms grows, which can make it advantageous to wait.
Consider the following scenario:
1 million PSM tokens deposited into a Portal
1,000% rewardRate
10 million bTokens total held by depositors
Continuing the above scenario, time has now passed and there are 100k PSM in the funding pool. The depositor with 5 million bTokens decides to burn them for 50k PSM, or 50% of the pool total.
Now, the 5 million burned bTokens are gone. That means there are 5 million left, and 50k PSM in the funding pool. This is actually advantageous for remaining bToken holders. For example, a depositor who still has 1 million bTokens can now claim 20% of the funding pool instead of their original 10%.
As the funding pool grows, they’ll accumulate rights to more deposited PSM. Thus, funders are incentivized to wait to burn their bTokens.
If you’re interested in reading more information on bTokens of V1, we cover them in our blog post here.
Similar to Portals V1, funders receive bTokens in return for providing initial funding. However, the redemption method in V2 is more efficient.
In v1, bTokens represent a claim on funding pool assets based on the total number of outstanding bTokens (that haven’t been burned yet). In this scenario, bToken holders would gain a larger share of future funding pool assets by waiting until other bToken holders burned their bTokens, but the burn value of bTokens start at zero PSM.
In v2, a funder can burn their bTokens for a constantly increasing amount of PSM which starts at the breakeven value. This means that funders don't need to wait to recoup their investments but instead start earning a fixed APR immediately. However, there won’t be enough assets to service all redemptions immediately. bToken holders who wish to redeem must do so when the reward pool holds enough tokens. As the shared LP receives more PSM from arbitrageurs, more bToken holders will be able to redeem their bTokens.
This change in redemption logic accounts considers the fact that not all bToken holders want to redeem for PSM at once. Hence, it is not necessary that the funding reward pool holds enough tokens for all bToken holders at the same time. This adjustment also means that bToken holders earn a fixed APR instead of a variable APR which is the case in V1.
