Storage & data on-boarding with reduced pledge collateral ("pledge shortfall") #666
Replies: 7 comments 10 replies
-
will this lead to a situation where 2 sectors pledged in the same epoch can get the same QAP with different IP? that should be avoided. the fee calculations "proposed" above are most likely way more complex than allowing QAP of 0.5 or a flexible pledge % per sector. |
Beta Was this translation helpful? Give feedback.
-
|
It will not. Such sectors would have the same initial pledge requirement, but the miner may have a shortfall from their total (sum over sectors) initial pledge requirement. |
Beta Was this translation helpful? Give feedback.
-
|
sorry, i asked the wrong way. i try to rephrase it. assuming 2 miners A and B. A is utilizing the features of this proposal and B does not. What i read out of the proposal is: if A and B have an identical onboarding pattern, same amount of sectors (same quality), committed at the same epochs then A can get the same QAP as B by shortfalling his miner - only putting up a fraction of the needed IP.
In my eyes now this kicks in. A is earning rewards he hasn't provided the pledge for, B is loosing out on rewards. This won't fly with existing miners i think. sorry for not getting too technical here, i try to get a simple as possible understanding of whats proposed here. |
Beta Was this translation helpful? Give feedback.
-
The only things I see missing from the above description is that 1) some fraction of A's block rewards are redirected to cover the shortfall 2) some fraction of A's block reward is burnt. So A will 1) have less liquidity in its rewards and 2) earn strictly less than B. However I agree that A would make strictly more FIL per up front pledge.
My understanding of the design sketch here is that shortfall could be leveraged by all existing miners so there shouldn't be any asymmetry between new and existing miners. |
Beta Was this translation helpful? Give feedback.
-
and thats the problem - if A makes more rewards B makes less. So
is in the end covered by B, not A As long as not all miners using this scheme - and especially existing miners with limited, not endless funds will have no chance to participate - this will cause a reward shift to those who are able to participate. |
Beta Was this translation helpful? Give feedback.
-
|
I have a potentail concern with some of the implications (as I understand them). I agree with the observation is that SPs do not have equal access to capital - and I'd argue the current design of many leasing providers (that focus on singularly coupling an SP to a capital source via a multisig) do not solve for this issue. This is why I'm strongly in favor of smart contract based solutions (ala Glif, Collectifi) that are targeting a smart contract based owner for SPs - which also open the door for market capital providers to exist for storage providers. Building up those markets will take time, but I think are shorter than potentially even this fip going through - though not at odds with this FIP (though do have implications). My understanding of the issues we are seeing is a mismatch in the capital markets - there are hundreds of millions of Filecoin sitting idle that are not being put to work, and part of the reason for that is: Solving for this should start with fixing the capital markets - by building out robust on-chain infra that allows for these markets to form. My issue with this proposal is that if we introduce the protocol as a potential borrowing source, it implicitly means that the protocol is making a determination of how duration risk should be priced (which could be inaccurate, and therefore stunt the incentive for tokenholders to put their FIL to work), and implicitly the network is valuing the FIL it emits (if a completely neutral party were to participate in this program, we should assume they borrow and spend all FIL up until they are break even on their operations - shoveling FIL into network participants who aren't long term aligned with the network). Unless we pick an aggressive numbers, the program then is potentially going to lead to less FIL being put to work (if 420m FIL is sitting idle, and the true market clearing rate for 18m of duration risk is 40%+ of block rewards, but this program sets the number at 33% we then artificially constrain the network (and potentially lead to more FIL net being sold)). In other words: if participants are going to borrow from the protocol, we should target them doing it as a last resort - and it should be excessively punitive compared with working with existing tokenholders. Given we don't know what the true market clearing rate should be, it feels like this is a hard number to set now without potentially stunting the markets we want to see form. |
Beta Was this translation helpful? Give feedback.
-
|
@jnthnvctr - I think the structural mismatch between pledge duration and staking behavior (prefer shorter term duration) will likely render the market clearing rate too high for the network to economically function if it relies purely on a staking clearing rate (i.e. for SPs to be adequately compensated to borrow FIL). @anorth you say "This is a temporary situation. In time, increased scale and accessibility of token leasing programs and applications (especially on the FVM) will make leasing much more widespread." - This may be true but it may not solve the structural issue eluded to above. It might be the case that these problems can be solved with properly structured capital markets orientated solutions - FIL hypothecation, FIL liquidity facilities, FIL repo, FIL deposits, etc etc but this is creating a FIL bank (and a bank needs strong capital backing to be risk mitigated). Liquidity solutions like liquidity staking protocols are less likely to be successful as they will create excess risks (imo) without the benefit of robust protection. At the margin they may help, but liquidity mismatch (enabling stakers to exit before the pledge duration is over) should be carefully managed. The exception to this is if the capital markets solutions eluded to above exist and thus the FIL economy is more robust. Then these solutions could be more effective. To reiterate, the fundamental issue (imo) is the duration and size of the pledge requirement vs the natural appetite of FIL holders to stake. This can also be solved by changing the structural mismatch. Either decreasing the size of the pledge requirement (like is suggested in this discussion) or reducing the duration of the pledge requirement. Both these mechanisms should be explored. However, rather than framing either solution as a short-term fix or for them to require a fee, why not introduce them as an incentive mechanism to reward actors who generate value for the network by creating commercial revenues, adopting appropriate standards or otherwise acting in a way that aligns with the broader network goals etc etc. For example, SPs that commit long-duration CC could qualify for dispensation from pledge or a reduced pledge/sector duration for storage deals. A robust and stable FIL economy and paid deals would negate the requirement for long-duration sectors because the incentive to continue to perform services would exist (fees) and the friction associated would be reduced. FIL+, for instance, would be a much more elegant solution if it was a combination of various incentivization levers rather than a pure multiplier. It would also likely create less risk for SPs and thus a more stable network. It should also be reserved for paid deals (imo). |
Beta Was this translation helpful? Give feedback.
-
|
I understand the proposal's vision and motivation, but I agree with @jnthnvctr that the key thing is to establish a capital market using staking or lending smart contracts. We already have a dozen such contracts in the works. The proposed capital market would make the network the lender. However, managing risk, including defining collateral and interest rates dynamically based on the network and economic status, is the most difficult aspect of creating a lending market. It would be better to leave this to the APPs, which would not directly impact consensus security. Furthermore, if the proposal is implemented, a built-in lending market will be established, and other staking/lending markets will have to compete with it, in addition to competing with each other. In other words, a lending smart contract must be more attractive than the built-in one for storage providers. This will impact lending market innovation and make setting the parameters for the built-in market difficult. |
Beta Was this translation helpful? Give feedback.
-
|
@jnthnvctr has re-stated a goal that was already explicitly stated
And @steven004 raises a similar concern. This is one of the easy-to-raise concerns that prematurely stopped exploration of these ideas over a year ago. We are on the same page about this being a "concern" to address. We believe that deeper exploration here will reveal constructions that are beneficial and with minimal risk of interference. Yes, robust and scaled token leasing programs, on- and off-chain, will eventually provide better solutions. But SPs are severely limited now, and we have no idea how long it will take for leasing programs to reach the levels of trust and adoption required to make this limit on the network go away. I would like to be clear here that there will be no lending taking place from the network. No tokens will be minted or transferred. The risks of lending mostly don't apply (to either party). This proposal will just be a change to the rules that the network enforces about pledge requirements. Thanks for raising the concern. I've posted this discussion early, before a concrete construction and parameters, in order to gather desires and concerns from the community. This is one we're well aware of, and we should inspect any proposal against it. |
Beta Was this translation helpful? Give feedback.
-
|
a 33% rate means 66% / year on the blockrewards a SP earns. thats not viable. we can put some numbers behind this. if you borrow 300 FIL right now you need 100 of them for fees (doesn't matter if FIL+ or not, publish fees make up the difference) to pledge the remaining 200. With a FIL on FIL 1 year ROI of 50% that will be 100 FIL reward per year. Now a interest rate of 33% already means that the miner doesn't get any of his rewards - at. all. - while still having expenses to actually run the hardware and the storage. |
Beta Was this translation helpful? Give feedback.
-
|
What are the incentives for SP to use shortfalls? |
Beta Was this translation helpful? Give feedback.
-
|
The details are something to work out but it seems likely to be along the lines of more sectors and greater aggregate rewards achievable per unit pledge, so as to enable an SP who has a data pipeline/hardware to grow at a faster rate than would otherwise be possible when limited by pledge availability. |
Beta Was this translation helpful? Give feedback.
-
|
The PL Cryptonet and CryptoEconLab teams have continued to explore this space with more detailed design and analysis. Both of these activities are ongoing, but we’ve reached a point where proposals are concrete enough to share for wider analysis and feedback. This post is co-authored by @anorth and @tmellan. We’ll copy a brief specification for two different mechanisms into top-level comments below, so they can have independent discussion threads. This comment has some discussion relevant to both. The problem and goals remain consistent with the introductory post. For both mechanisms:
The result is that an SP can onboard more power for a given amount of pledge tokens. This can raise FIL-on-FIL returns (but not gross income). The mechanisms are designed such that using a shortfall is unattractive if tokens for the full pledge amount are available – the protocol fees should match or exceed leasing costs associated with using those tokens. Defining successA successful outcome for a change like this would be:
A failed outcome would be a constant rate of onboarding (as if there had been no change) despite wide use of shortfalls, resulting in a reduced amount of pledging for the same power. This might be because onboarding is limited by other factors, or the total network block reward cannot support the fiat costs of additional onboarding. Another failed outcome would be that the shortfall mechanism is unused, e.g. because it is unattractive to SPs. This exploration was motivated by current network conditions, but a successful mechanism should be relevant in the future too. Shortfalls could provide a buffer for various conditions leading to low pledge availability, including external economic conditions or periods of low trust in token leasing or staking mechanisms. A successful mechanism should be a stabilising force. Part of our ongoing analysis work is toward a more rigorous evaluation framework and identification of the most relevant metrics. Relative advantagesAny protocol change is likely to benefit some parties more than others. These proposals don’t change the total block reward (except to the extent that additional onboarding can increase baseline minting), they can only change the distribution. Two such tradeoffs are:
Early feedbackWe interviewed a number of Filecoin community members directly about these problems and proposals, both SPs and other ecosystem participants. We’d firstly like to say a huge thank you to those who shared their time and thoughts with us. The early feedback has helped widen our perspective and sharpen our thinking. Perspectives varied, of course, but a few message were relatively common, summarised below.
This feedback was very helpful for putting the work ahead to realise these proposals into perspective. Impact on token leasing marketsAn explicit goal of both mechanisms is to avoid undercutting external or on-chain token leasing platforms. If tokens are available at a leasing cost that is supported by an SPs operational returns, they should be preferred to taking a shortfall. Quantifying and confirming this property is difficult, since it depends on things like leasing fees that can’t be directly observed on-chain. Dynamic fee mechanisms seem to at best achieve the property that taking a shortfall isn’t consistently more preferable to leasing tokens, but it’s difficult to ensure that a shortfall is strictly less preferable. This does’t matter while tokens are scarce (all those available for leasing should be used) but can matter in the crossover point where tokens are available but not abundant, and SPs face a real decision about how to fund pledge. On the other hand, since a shortfall can increase an SP’s FIL-on-FIL return (because the pledge denominator is smaller), this could increase the token leasing fees that SPs can afford to pay. This may increase investors’ returns and draw more tokens into use, to the benefit of holders and leasing platforms. Other impactsWe’re still designing and analysing these mechanisms. We’ve decided to share the work in progress to gather more community feedback and help us identify other impacts. A few pieces of investigation that we know are outstanding are:
The proposed mechanisms may change as a result of these and other investigations. ResourcesIn addition to the mechanism specifications to be posted below, here are some resources to help you understand and analyse these proposals.
Next stepsWe’re proposing these mechanisms for community consideration and feedback. Analysis is ongoing and we expect discussion here to generate new questions for us all to consider. Whether or not we should pursue detailed design and analysis now depends considerably on community enthusiasm for these mechanisms. Our primary goal is to support SPs’ onboarding, so their opinion that such mechanisms will help is an important input. |
Beta Was this translation helpful? Give feedback.
-
|
thanks for the details on how you intend to structure it. one major point comes to mind immediately - besides the concerns voiced above already - QAP != 1 is a choice. QAP itself is a great mechanism to lower/raise the on boarding rate of storage and data without the need for more pledge FIL. |
Beta Was this translation helpful? Give feedback.
-
Thing 1This is one specification for a pledge shortfall mechanism. Summary
Actor stateMiner actor stateA new A new /// Total rewards and added funds locked in vesting table.
locked_funds: TokenAmount, // Existing
/// Absolute value of debt this miner owes from unpaid fees.
fee_debt: TokenAmount, // Existing
/// Sum of initial pledge requirements of all active sectors.
initial_pledge: TokenAmount, // Existing
/// Amount of initial pledge requirement that is satisifed by tokens
/// held on balance.
initial_pledge_satisfied: TokenAmount, // New!
/// Fraction of vested rewards to redirect into pledge
/// while there is a shortfall.
/// Represented as some fixed point, e.g. 1/1000.
shortfall_repayment_take: u32, // New!A miner has a shortfall of Note: A miner’s total pledge is considered to be Power actor stateTwo new fields track the total initial pledge requirement and satisfaction across all miners. At migration, set these to values calculated from the sum over corresponding miner actor fields. /// Sum of initial pledge *satisfied* plus vesting rewards across all miners.
total_pledge_collateral: TokenAmount, // Existing
/// Sum of initial pledge requirements of all miners.
initial_pledge_requirement: TokenAmount, // New!
/// Sum of initial pledge satisfied of all miners.
initial_pledge_satisfied: TokenAmount, // New!Initial pledge is broken out from the existing The network overall has a shortfall of Actor behaviourMiner actorAn incremental shortfall is available at any time the storage provider is increasing their pledge. This means that whenever an SP is increasing their pledge (e.g. sector onboarding, SnapDeal, extension with multiplier), they can provide less than the notionally required amount. The maximum available incremental shortfall is equal to a maximum “repayment take” fraction of the expected rewards for the new commitment over its term. The maximum repayment take value comes from the power actor (see below). An SP’s total shortfall determines their repayment reward fraction. This fraction is held constant until shortfall is reduced to zero, or increased when additional onboarding increases the shortfall. Some supporting policy functions: // A pessimistic projected reward for power over some period.
fn expected_reward_for_power(network_reward, network_power, power, period) {
// The reward is projected from the current per-epoch reward for
// the share of power, with a pessimistic decay
// - REWARD_DECAY is the constant network reward decay rate
// - BASELINE_GROWTH is the constant baseline function growth rate
// This pessimistically assumes that the share of power decays as if
// a miner stopped growing while the rest of the network grew at the
// baseline function rate.
// This can still temporarily under-estimate if:
// - Reward decays faster, e.g. due to baseline crossing
// (but then the network isn't growing at baseline rate), or
// - The network grows even faster that baseline rate
decay = REWARD_DECAY + BASELINE_GROWTH
return sum_of_exponential_decay(period, decay) * network_reward * power / network_power
}
// The maximum shortfall amount permitted for a miner to maintain,
// or incrementally add.
fn max_shortfall(network_reward_estimate, network_power_estimate, power, period,
repayment_take) {
repayment_take * expected_reward_for_power(...)
}
// SUM[(1-r)^x] for x in 0..duration
fn sum_over_exponential_decay(duration, decay) -> float:
return (1 - pow(1 - decay, duration) + decay * pow(1 - decay, duration)) / decaySector activationSector activation includes the struct ProveCommitSectorParams {
sector_number: SectorNumber,
proof: Vec<u8>,
// New: Amount of balance to lock as pledge.
// Any less than the required pledge amount is taken as a shortfall.
// A value greater than requirement is clamped to the actual requirement.
// Zero means to lock exactly the minimum amount allowed (max shortfall).
// Value greater than zero but less than the minimum allowed are rejected.
pledge: TokenAmount,
}
// Similar for ProveCommitAggregateParams...The new sector’s pledge requirement is calculated as usual. The incremental shortfall allowed is calculated as the maximum repayment capability of the new power. The minimum pledge amount that the SP must provide is then the usual requirement less the incremental shortfall. max_repayment_take = fetch_parameters_from_power_actor()
pledge_requirement = initial_pledge_for_power(...)
allowed_shortfall = max_shortfall(network_reward, network_power,
sector_power, sector.duration, max_repayment_take)
minimum_pledge_requirement = pledge_requirement - allowed_shortfall
if params.pledge == 0 {
params.pledge = minimum_pledge_requirement
} else if params.pledge > pledge_requirement {
params.pledge = pledge_requirement
} else if params.pledge < minimum_pledge_requirement {
abort("pledge is less than minimum")
}
// Update state
miner.inital_pledge += pledge_requirement
miner.initial_pledge_satisfied += params.pledgeThe actual repayment take rate (fraction of earned rewards) that will subsequently be redirected into pledge is then calculated from the SP’s actual total shortfall (i.e. the incremental shortfall plus residual shortfall from earlier onboarding). If the new repayment take is greater than the rate the SP is already paying, their rate is updated. If less, the rate is not changed. Note that if an SP has a shortfall based on one duration, then commits a sector with shortfall and a shorter duration, the repayment take for both will be accelerated to the newer, shorter duration. An SP can commit shorter sectors with full collateral to avoid accelerating an existing repayment schedule. // After updating state
if params.pledge < pledge_requirement {
current_shortfall = miner.inital_pledge - miner.initial_pledge_satisfied
expected_rewards = expected_reward_for_power(network_reward, network_power,
miner.power, sector.duration)
repayment_take = current_shortfall / expected_rewards
if repayment_take > max_repayment_take {
abort("computed repayment reward fraction exceeds maximum")
}
// Ratchet up repayment take if necessary.
miner.shortfall_repayment_take = max(miner.shortfall_repayment_take, repayment_take)
}The power actor’s UpdatePledgeTotal method is expanded to include the initial pledge, and initial pledge satisfied. struct UpdatePledgeTotalParams {
pledge_delta: TokenAmount, // The existing field
initial_pledge_delta: TokenAmount, // New!
initial_pledge_satisifed_delta: TokenAmount, // New!
}The miner sends pledge updates to the power actor corresponding to its state updates. Sector updateSimilar to sector activation, a new parameter lets the SP specify the amount of additional pledge to lock. This may be less than the computed requirement, resulting in a shortfall. Note that shortfall may only be taken against additional pledge requirements. If the pledge requirement does not increase, an SP cannot use this mechanism to release already-pledged tokens. incremental_power = new_power - old_power
old_pledge_requirement = old_sector.initial_pledge
new_pledge_requirement = initial_pledge_for_power(...)
incremental_pledge = new_pledge_requirement - old_pledge_requirement
if incremental_pledge > 0 {
duration = sector.expiration - current_epoch
allowed_shortfall = max_shortfall(network_reward, network_power,
incremental_power, duration)
minimum_pledge_requirement = new_pledge_requirement - allowed_shortfall
// Continue as for sector activation
}Sector extensionSimilar to activation and update, an SP specifies the additional pledge to lock, and may take a shortfall. The duration for computing the maximum shortfall is the sectors new expiration epoch minus its old expiration epoch (i.e. the incremental duration addition). Note that initial pledge requirements at extension are only likely to change significantly with the introduction of some kind of duration multiplier. Sector expirationWhen a sector expires, its pledge requirement that is returned in proportion to the miner’s overall satisfaction of pledge requirements. The ratio of shortfall to pledge requirement thus remains constant. pledge_satisfaction = miner.initial_pledge_satisfied / miner.initial_pledge
pledge_to_release = pledge_satisfaction * sector.initial_pledgeThe repayment fraction of rewards is updated to maintain a constant repayment amount despite the reduced rate of rewards from expired power. TODO: account for the fact that absolute shortfall has reduced (to keep fraction constant). This adjustment is only needed to adjust for different ratios of pledge:power for different sectors. The proposed spec assumes the ratio for the expired sector was zero, which is too harsh. miner.shortfall_repayment_take *= old_power / new_powerSector terminationSimilar to expiration (after paying termination fee). Receiving rewards—fees and repaymentA miner pays fees from vested rewards, except where insufficient vested rewards are available in which case fees are paid from vesting rewards. Some of the earned rewards are also automatically locked to reduce the pledge shortfall. max_fee_take = fetch_parameters_from_power_actor()
immediate_reward = 0.25 * earned_reward // Existing behaviour
vesting_reward = 0.75 * earned_reward // Existing behaviour
max_shortfall = max_shortfall(network_reward, network_power,
miner_power, 5_YEARS) // 5_YEARS may as well be infinity given the decay rate
actual_shortfall = miner.initial_pledge - miner.initial_pledge_satisfied
shortfall_fraction = actual_shortfall / max_shortfall
fee_take_rate = shortfall_fraction * max_fee_take
fee_amount = earned_reward * miner.fee_take_rate
burn(fee_amount)
// Cater for parameters where fee amount can exceed the immediately
// available rewards.
if fee_amount > immediate_reward {
vesting_reward -= (fee_amount - immediate_reward)
}
vest(vesting_reward)Repayments of the shortfall are made when tokens vest. vested_reward = unlock_vested_rewards(...)
shortfall = miner.initial_pledge - miner.initial_pledge_satisfied
repayment_amount = vested_reward * miner.shortfall_repayment_take
if repayment_amount <= shortfall {
repayment_amount = shortfall
// Reset repayment rate to zero
miner.shortfall_repayment_take = 0
}
miner.initial_pledge_satisfied += repayment_amount
// Any amount not locked as pledge becomes available balance.Penalties and fee debtThe current behaviour is maintained. A miner pays penalties from vesting rewards, then available balance, but cannot reduce their balance below the satisfied pledge amount. A miner goes into fee debt if they have no unlocked balance to pay an incremental fee. A penalty cannot be used to increase shortfall. Explicit shortfall repaymentA new method allows a miner to lock funds to reduce their shortfall immediately. Dynamic feesThis is a rough sketch, needs more detail. The power actor maintains the maximum repayment take and fee take (fractions of earned reward to take for repayment/fee) parameters for incremental shortfalls. The values sum to 1.0. The values adjust to increase the cost of taking a shortfall if it is heavily utilised by the network, and decrease to a floor if not utilised. The fee take is initially set to If the actual network shortfall is greater than Note that changes in the shortfall fee only affect SPs who add new, incremental shortfall. An SP that onboards only fully-pledged sectors will not experience any increase in their repayment take. An SP that does onboard a new sector with a shortfall will have the new repayment take apply to all their resulting shortfall. Design notesThe incremental pledge shortfall fraction is the same as the miner’s max shortfall fraction. We need some part of the incremental pledge to be provided in order to avoid shocks, and maintain demand for tokens. We could set the incremental pledge shortfall fraction higher (e.g. 50%) than the max shortfall fraction, but this would advantage to larger miners. In effect, they would be using their already large income streams to pay down the new pledge. This would support greater network-wide use, but advantage established parties more. |
Beta Was this translation helpful? Give feedback.
-
Thing 2This is an alternative specification for a pledge shortfall mechanism. Summary
Actor StateMiner Actor StateMiner actor state tracks one new field: Power Actor StateNo change for the basic construction Actor BehaviorSector ActivationSector activation includes the Sector Onboarding Burn and Receiving RewardsSet the SP repayment (burn) rate: The burn take rate formulation presented here can be generalised in a number of ways. Two ways are: (i) by making the exponent dynamic, allowing it to change based on the level of shortfall, and (ii) introducing an additional burn fee that increases with shortfall uptake. Both generalisations can in effect make shortfall progressively less attractive with the level of uptake. One indirectly through repayment dynamics without any additional cost (but through less favourable cash flow), and one explicitly through an additional fee rate component. While full specification of these generalisations is beyond the scope of this introductory spec, sketches for each are presented at the end. Distribute rewards between burning, vesting, and immediate release: Sector ExpirationWhen a sector expires, the outstanding burn obligation is reduced proportionally to the fraction of power represented by the sector. The sector’s initial pledge amount is returned in full. The remaining ratio of the burn obligation to pledge requirement thus remains constant. Sector TerminationSimilar to expiration following termination fee payment Generalized Burn Rate VariantsTwo variants are set out that can generalise the dynamics to make uptake of the shortfall progressively less attractive. Variant 1 increases the shortfall repayment rate by changing the exponent, which makes it less attractive under most network conditions. Variant 2 introduces an additive rate penalty. |
Beta Was this translation helpful? Give feedback.
-
|
From a very simplistic view, wouldn't it be better to create greater incentive for the lenders? My understanding is that there is not necessarily a problem with FIL availability (i.e. circulating supply) but that it is not making it's way to SP's. I do agree that the risk here is overcomplicating layer 1. It is complex today and the proposals whilst logical may have unintended consequences i.e. like new participants feeling overwhelmed about the inner workings of Filecoin. In saying this I am impartial to this proposal. my only question would be whether better time is spent focusing on how to redirect FIL back to SP's via lending solutions and solve the problem that way. |
Beta Was this translation helpful? Give feedback.
-
At least some Filecoin storage providers are evidently struggling to source Filecoin tokens to lease and pledge as collateral for onboarding new storage or data. Cryptonet have been exploring protocol design changes that could ease this problem for some time, more energetically since the thoughtful discussion opened in #583. Despite some immedite concerns raised by those ideas, deeper consideration has convinced us that there are fruitful, win-win constructions that could help SPs onboard more storage and data while, a bonus, also helping to stabilise the circulating token supply.
Problem
These problems are mutually reinforcing: constrained network growth limits the flow of tokens from circulating into pledge, and inflation may be one reason token holders are unwilling to enter long-term locking agreements which could enable growth.
This is a temporary situation. In time, increased scale and accessibility of token leasing programs and applications (especially on the FVM) will make leasing much more widespread. Decaying block reward emissions and the cessation of SAFT vesting will ease inflation pressure. But in the meantime, the network could benefit significantly from a mechanism made available now.
Goals
The motivating objective of these ideas is to reduce the intensity of the two identified problems, supporting more robust network growth until the circumstances improve.
Other properties to seek or maintain include:
Proposal sketch
These objectives can be met by some combination of the following ideas:
The amount of shortfall an individual SP takes on will determine the fee and repayment raes. Each SP has ability to select a tradeoff that works for them, maintaining sufficient free returns for opex, token leasing fees, etc.
An SP will only be able to increase their shortfall at points of increased commitment; mechanisms will offer no support for early release to already-locked pledge.
Intuitions
Work to be done
Both the Cryptonet and CryptoEconLab teams are now focused on working out the details for a concrete protocol proposal. We should have a more concrete proposal in the coming weeks and, if well supported, can work towards prompt implementation.
Work to be done includes:
While we nut out some details, we are seeking feedback and suggestions from the community on these ideas and their implications. We are especially interested to hear from SPs experiencing these problems, and from developers of the token leasing platforms that we expect to eventually take the reins as long term solutions.
I realise this outline doesn’t yet provide enough detail for SPs to plan any concrete operational changes. We are still working out those details, but wish to indicate the directions we are exploring.
Beta Was this translation helpful? Give feedback.
All reactions