Proof-of-Deposit – initial proposal and request for feedback

Hi @Tim

Re your other questions:

I don’t see any reason in principle why cStables enrolled in PoD would need to be locked for an extended time. I considered this a while back in the context of Algorand (imagining PoD implemented on Algorand with a native stablecoin), and in that case it is not necessary for the stablecoin to be locked/immobilised/rendered illiquid. I will think some more about how this works in Celo. I suspect the same applies, but I’ll get back to you on this.

Understood. We do not propose to alter the rate at which rewards are generated / distributed by the protocol, or the total quantity of these rewards. A primary goal of our proposal is to get Celo to the point where it has sufficient real-world utility, and non-speculative use, to continue to thrive when CELO inflation runs out.

We are more-than-happy to entertain suggestions for alternative ways to achieving our goal. Regarding the risk / benefit and potential for a long audit cycle, once people feel that they have the measure of our proposal and its potential upside, we’ll be at the point where we can judge whether this potential is worth the time effort it will take to implement it.

Our mechanism does not require the price of any cStable. The size of the deposits of cStable and CELO stakes are in terms of the percentages of the total number of cStables and CELO tokens (respectively) that are enrolled. I elaborated on this in this reply to @Pinotio.com

As for implementation details in general, we would be happy to have an open call to field any further questions.

1 Like

Apologies, we’ve been mixing up terminology a bit. I believe what you’re asking is:

Is a validator offering to share 100% of their epoch rewards with cUSD depositors an attack vector?

We stress that this isn’t an attack vector and is entirely allowed! A “malicious” validator taking such a course of action would be akin to intentionally mispricing an asset: e.g. trying to sell CELO for $1 or $100 even though the market price of CELO is $3. That is to say, you are free to do it, but you are much better off matching the market.

In our case, the result of a validator “mispricing” the proportion of epoch rewards they share with cUSD depositors, is that such a validator will end up earning less epoch rewards overall. It can be quite simply explained why this is the case:

  1. Validator M, the “mispricer”, “misprices” the proportion of epoch rewards they share with cUSD depositors by offering more than the market rate

    (a) The below also applies if M offers less than the market, but with CELO and cUSD switched

  2. Initially:

    (a) CELO stakers will start moving their votes from M to other validators as they will get a better return

    (b) cUSD depositors will start moving their votes from other validators to M as they will get a better return

  3. Because the percentage of epoch rewards a validator earns is based on min(%CELO, %cUSD), the outflow of CELO from M will start reducing their percentage of epoch rewards earnt faster than for other validators

    (a) Even though there is also an outflow of cUSD from other validators, as they are the majority, the reduction to their percentage of epoch rewards is less as they have a higher starting %cUSD

  4. cUSD depositors will also start moving their votes from M to other validators

    (a) Even though M is offering to share more of their epoch rewards, the percentage of epoch rewards M is receiving will be increasingly lower than other validators

  5. M ends up experiencing an outflow of both CELO and cUSD, reducing their overall percentage of epoch rewards earnt

All this is from using the deceptively simple min function, meaning that the incentive to fill a deficit of %CELO or %cUSD a lot stronger than acquiring an excess of %CELO or %cUSD.

Retaining this cap for CELO does not interfere with proof-of-deposit. It is unnecessary to set a similar cap for cUSD as our use of the min function means that there is an increasing disincentive to having %CUSD above %CELO (which has a cap).

We do however recommend setting a small minimum cUSD requirement for becoming a validator (similar to the already existing minimum CELO requirement). This will eliminate any remote possibility of 100% of cUSD votes going to a single validator.

2 Likes

Hi @Pinotio.com

Thanks for setting me straight on this. I had somehow misinterpreted how this Tobin tax works.

A Last Resort Mechanism like the one suggested is, I think, worth considering seriously. I have not thought about it deeply, but my feeling is that it would be in the interests of CELO holders to have such a thing in place, even though it introduces a risk of dilution.

As we have outlined, our proposed mechanism aims to buffer declines in the CELO price by making cStables particularly attractive in a market downturn. This should reduce the risk of cStables becoming under-collateralised. I suppose, then, that PoD could make the Last Resort Minting Mechanism even more interesting to CELO holders.

1 Like

Great to see well thought-out and communicated proposals! I think Celo would do well to experiment with novel financial models like this.

Quick question, and perhaps showing my misunderstanding of the proposal, but why should the validator voting rank rely on min(CELO votes, cUSD votes)? Shouldn’t it be sum()?

If I’m validating and can offer some x% of my epoch rewards to people voting with cUSD, shouldn’t those deposits add to my standing in the election? Using this min() model, all someone needs to do is vote 1c for me and suddenly I’m dropped out of the election. Or is it an opt-in model?

Even so - voters take time to switch so even the highest elected groups might even drop out for an epoch or so while their cUSD votes accumulate.

Validating on Celo is somewhat complicated enough, I don’t know why the validators need to be involved in these market dynamics, it’s just yet another variable to have to control for. Why couldn’t we just reduce epoch rewards evenly across the elected set, and apply those funds helds back proportionally to all cUSD holders who lock in some contract? Couldn’t we then just update the election process to include these deposits at voting power, at some on-chain determined exchange rate?

I guess what I’m describing sounds just like another yield farm, so it’s probably missing the point of your proposal. I’ll have another read through.

3 Likes

Hi @Thylacine, thank you for your questions!

To clarify, %cUSD is only used in determining what % of epoch rewards a validator receives. It has no affect on a validator’s chances of getting elected (which is still only based on their CELO votes alone).

Also, the %cUSD is sum of all cUSD votes for you divided by sum of all cUSD votes for every validators. So a single person voting 1c for you won’t drop your epoch rewards to zero (unless that is the only vote you get).

There are various reasons which motivate the use of min rather than sum. For instance, using min means that validators need to share their epoch rewards to retain their revenue . If we were to use sum, it would risk a “tragedy of the commons” where few (if any) validators would share their epoch rewards with cUSD depositors. This is because, in that scenario, validators could share 0% and still retain the same revenue as they will receive more CELO votes, as a result of them offering a higher return compared to those validators who do share.

The issue with reducing epoch rewards evenly across the elected set is:

  1. how will the proportion shared be decided?

  2. how do you ensure the proportion shared is appropriate? Keep in mind this will eventually be extended to multiple cStables.

If the proportion shared is decided by vote, this will be counter-productive to boosting CELO’s marketcap. After all, the attraction of a deposit rewards rate on cStables is greatly diminished if investors and users know that the validators can vote it to 0% at any time (and are constantly tempted to do so to maximise their own APY on CELO).

This is the famous time inconsistency problem (as John highlighted here) which can only be overcome by using an incentive-aligned market mechanism. This makes a huge difference because:

  1. investors and users will be confident that the rewards will be perpetual (rather than trend downwards to zero), and will price their expectations into CELO

  2. investors and users will need to keep their money in cUSD in order to keep earning the rewards (as opposed to temporarily investing, and then withdrawing their money after the rewards expire)

  3. a market mechanism means that the appropriate proportion of rewards to share will emerge, and can dynamically change, from balancing the incentives of CELO, cUSD, and other cStable voters.

Point 1 is really is the key here if our objective is to maximise CELO’s marketcap as the price of an asset is all about market expectations. We argue that establishing strong market confidence in CELO’s future outlook is worth the extra complexity.

1 Like

I don’t understand this, especially in the context of Celo’s discrete validator seat / election process.

Unless mandated, no validator group is going to switch the basis of their election votes unless it gives them a new seat. There’s no benefit to having 1.9 seats of cUSD versus 1.0 seats of CELO votes, but there is a real danger of 0.1 seats of cUSD votes, especially on day zero when the proposal is activated and the public hasn’t started depositing and voting for groups with cUSD.

If cUSD votes are additive though, and the cUSD depositor community signals this is a desired feature for a validator group by voting en masse by those who give up their rewards, wont this just form a market equilibrium where each validator group has to see the potential opportunity for more seats, and start offering it themselves? Kind of like how the validator fee is set on Cosmos networks - it forms a generally accepted range among the validators.

I may be over-simplifying and I’m definitely not an economist, just trying to zoom out. Disclosure: I am a currently elected validator =)

3 Likes

Apologies @Thylacine, I made a big mistake in my answer! I was mixing up election vs distribution of epoch rewards.

To be clear:

  • Getting elected is only based upon the number of CELO votes a validator receives
  • Distribution of block rewards (a validator’s revenue) is based upon the technique we described

I have edited my answer above to reflect this.

As such, the transition from the old system to the new would not be causing issues with validators getting elected. The new method to distribute epoch rewards can be phased in various ways, such as activating it after a time period to allow sufficient cUSD votes to be accumulated.

Ah I see where you’re going. The key issue with this method is that it will require comparing CELO votes vs cUSD votes vs other cStable votes using the same unit. The obvious way is to convert all the tokens to USD value before adding, but this has huge potential for fluctuations in a token’s “voting power” from block to block, and creates a dependency on external price feeds.

Also, because the marketcap of CELO should always be at least >2x greater than all the cStables combined, offering to share 0% of the epoch rewards with cStables will likely result in greater voting power for a validator compared to validators who do share.

1 Like

Apologies, I didn’t fully appreciate the point you raised here. After chatting with @Thylacine, I realised I should of been using the term block rewards rather than epoch rewards.

By block rewards I mean:

all revenue (e.g. transaction fees and newly minted CELO) that goes to validators before deducting expenses such as sharing with voters/delegators

1 Like

I would assume there has been modeling of some sort done, is there a place where we can see the results of various scenarios and how it affects the various and sundry stakeholders and such?

Ok, I’m confused now.

If only CELO is the basis for a validator being elected, then:

a) what does it mean to “vote” with cUSD
b) why would validators care about anything other than how much CELO they have voting for them?

3 Likes

I like the idea of a deposit rate paid for by minting cUSD from newly minted CELO. But I’m skeptical of the implementation as described because the process of setting epoch rewards as min of active cUSD/CELO votes feels overly complicated. The commission rate charged by validator groups only impacts the validator nodes that are elected in that group, it does not impact the yield paid to voters. They are rewarded based on the uptime score and slashing multiplier of the group they are voting for.

If someone stakes+votes CELO then they earn CELO yield at a rate determined by the inflation rate, the pro rata share of CELO they have staked, the group’s uptime score and slashing multiplier. If they stake+vote with cUSD then they should probably earn cUSD at a rate determined by the inflation rate, their pro rata share of staked cUSD, the group’s uptime score and slashing multiplier.

4 Likes

You are welcome to take a look at our initial analysis.

a) We admit “voting” is not really the correct term to use. Rather it is an association of cUSD deposits with validators.

b) the percentage of block rewards that a validator earns is based on min(%CELO, %cUSD). This incentivises validators to attract cUSD deposits to be associated with them else their earnings will drop

Our use of min is all about incentive design. By basing the percentage of block rewards that a validator earns on min(%CELO, %cUSD) we can enable the following benefits (which no other method can):

  1. It creates sustainable internal demand for cUSD which will attract external demand.

    a) internal demand comes from validators constantly competing to attract both CELO and cUSD in order to earn the most block rewards that they can. In this way, we prevent the deposit rewards rate from trending to zero.

    b) external demand requires confidence that the deposit rewards rate is sustainable and reliable as investors will price this risk into their decision making. Maker DAO was the first to attempt to provide an analogous primitive with its Dai Savings Rate which famously got voted to zero.

    Since then, there have been other similar initiatives (e.g. Valora’s Supercharge Program), but all have either met with a similar fate, or have simply not seen much adoption—presumably because it is assumed (correctly) that if there were to be significant adoption, the rate would similarly trend to zero, and so is not worth the cost and effort to switch. In contrast, our mechanism can avoid this fate because the deposit rewards rate is market determined.

  2. It allows a market determined rate to fluidly emerge

    a) What proportion of block rewards should validators share with depositors? If it is a parameter that is voted on, it will be akin to price controls on goods.

    That is to say, setting the “price” is possible, but it is highly inefficient as you are actively ignoring supply and demand dynamics, ending up with either excess supply (leaving money on the table), or excess demand (you lose a lot of money from needing to acquire and provide the necessary supply). The latter is why Terra’s Anchor protocol is constantly having to top up their yield reserve, and is also why it is unsustainable in the long-term.

    The ultimate result is that a system which allows a market rate will outcompete systems which practice price control. We believe that our proposal achieves this market rate with an extremely elegant mechanism.

    b) The above problem is particularly pronounced when Proof-of-Deposit is extended to multiple cStables

1 Like

Morning Ying,

Thanks for the recipe. Now, where are the cookies? :wink:

I guess I should have more clear. Where can the results of the modeling be found?

What, I’m looking for is are the projections of what will happen in the best, expected, and worst case scenarios, for example: how the changes Proof of Deposit makes will affect the revenue available to Validators.

What I would also hope for is some kind of market study that might show how these changes work. Looking for the basis of why you would expect a certain number to be the best case and another number to be the worst.

1 Like

Thanks @ying_chan . Some high level additional thoughts here.

Celo Emissions
If anything, Celo’s token supply schedule is a bit more like Bitcoin’s then Ethereum. Like Bitcoin, there is i) a somewhat arbitrary schedule over which there are decreasing rates of Celo emissions, and ii) there is a fixed cap of Celo tokens.

The contrasts with Ethereum, where i) the rate of emissions (on the PoS chain) is determined by a curve that sets emissions (i.e. staking rewards). This curve is set in order to ensure there is a minimum number of validators (i.e. there are more Ether emissions if there aren’t enough validators). [By contrast, the rate of rewards on locked Celo is set to incentivise a high percentage of Celo being locked, which is a different goal that reduces the amount of Celo that is liquid on a short (<3 day) timeframe.]

In Celo (vs Ethereum) a lot of epoch rewards go to the on-chain community fund, a tiny portion goes to carbon offsets, and a significant portion goes to validator and locked Celo rewards. Quite simply:

  • With about 100 validators getting 60k cUSD each per year, this is about 6M cUSD per year in cost.
  • With 1B Celo and, very roughly, 50% locked receiving 5% rewards, that is 25M CELO annually in rewards going to locked Celo. With Celo at 3 cUSD per CELO, you can see that locked Celo rewards are much greater than validator rewards.

Note that validators do also earn a portion of transaction fees, but since network usage is low, this isn’t worth much right now (although we should be aiming for it to be!).

I’m not very expert on this, but security comes from not being able to control a significant portion of validators. (I think controlling 1/3rd of validators allows someone to stall the network.) . So I guess the logic is that by incentivising a high locking rate, that means a lot of CELO is voting, and that makes it expensive to buy the CELO needed to get a large amount of validators elected.

Celo owner behaviour
I think, as a locked Celo holder, that I’m incentivised to vote for a validator with high uptime and that is honest - because otherwise my rewards (although not my stake) can be hit.

This wouldn’t change in your proposal @ying_chan and @John.Fletcher , as I understand.

cUSD owner behaviour
In your new system, I now have an incentive to “deposit” my cUSD with one or more validators because they may pay me interest.
My incentive is to pick the validators paying the highest interest. (There doesn’t seem to be any downside to picking a bad or dishonest validator).

Validator Behaviour with Proof of Deposit
Now, the validator rewards (i.e. the ~65k cUSD paid per year) are apportioned, not evenly per validator, but according to min (Celo they have deposited with them as a percentage of the total outstanding CELO, cUSD deposited with them as a percentage of the outstanding cUSD)

In this case, I assume it makes sense for validators to start offering interest/rewards both in Celo to those who “deposit” (or would it just be the locked and voting amount that counts? I don’t understand this point yet) and also in cUSD.

In equilibrium, one would imagine that validators will pay interest up to a point where the rewards they earn, less the interest rate paid is equal to their operating costs.

Overall, this system will solve for some equilibrium interest rate for a given level of validator rewards (currently set at 65k per validator). So, one question we might ask is whether - in this new system - the rewards per validator should be increased (at the expense of either targeting a lower % of locked Celo [to reduce rewards for locked CELO] or at the expense of smaller flows to the community fund).

Right now, assuming all validator rewards went as interest to cUSD (which would not be the case), then the interest rate would be 6M / 100 M cUSD outstanding = 6%. Note that upwards pressure on CELO price wouldn’t increase these interest rates because validator rewards are denominated in cUSD at present (not in CELO).

2 Likes

Hi @Pinotio.com

It seems there is some confusion over definitions here:

This might help.

1 Like

I don’t understand how that definition addresses the concern pinotio has.

There still seems to be a perverse incentive.

Hi All, here are some notes from a call I just had with Ying and John.

cc @sep @MarkusBerlin @roman @tim @marek @rene_celo @thezviad

Broadly, I think this is the single highest leverage thing Celo could do right now to gain awareness+adaption - and I’m leaning more strongly towards recommending we implement this soon, and across all cStables from the start so we best support our mission.

What this proposal doesn’t change = Celo locking and voting

  • As a Celo holder, I’m still incentivised to lock my Celo with validators that have high uptime and that are honest. (Additionally, more on this later, there will be an incentive to lock with validators that pay the highest interest rate on Celo).
  • Locked Celo rewards would still be subject to slashing and downtime penalties as is currently the case.
  • In the new system, Celo is still the only token used for the election of validators. No change.
  • Nothing changes about voting in of validators or about consensus.

What this proposal does change = how rewards are distributed

  • Today, locked Celo rewards flow through validators (and are reduced by slashing or downtime penalties), but validators don’t earn any of these rewards. Validators just earn transaction fees and also the ~65k cUSD per validator.
  • In the proof of deposit system, validators as a whole would directly earn i) validator rewards (the 65k cUSD X # of validators) + ii) transaction rewards + iii) the rewards that currently go to locked Celo (to be clear, validators would now earn this directly, they are no longer just passing these through to locked Celo holders).
  • In the proof of deposit system, cStable holders can deposit (think of it like assigning) their cStables to validators in order to earn interest from validators. There will likely be no required locking period for these deposits (because they don’t contribute to security) so the cStables remain a currency and not a security. Depositors are incentivised to deposit with validators that pay the most interest on a given cStable. (Most likely, wallets will automatically assign deposits to validators paying the highest rates, and all validators will move to an equilibrium market interest rate for each token).
  • Validators use their (now substantially increased) earnings (as per above) to pay interest on Celo and cStables, to pay for their costs and for profits.

This pool of rewards (i - iii above) would be distributed among validators proportional to their min (% of Celo , % of cUSD, % of cEUR …). Here:

  • % Celo is how much locked Celo they have voting for them as a % of total locked;
  • % cUSD is how much cUSD they have assigned to them as a % of total deposited;
  • % cEUR is how much cEUR they have assigned to them as a % of total deposited.
  • etc. for cREAL and other cStables.

This is what incentivises validators to pay interest on cStables. This also incentivises validators to have equal amounts of each token (as a percentage of total locked/deposited across the community) locked/deposited with them.

Why this could significantly increase cUSD and other cStables outstanding
Consider cUSD, of which there is about $100M outstanding today.

Now, consider epoch rewards today of about 13M CELO per year.

If even 3M of these epoch awards ended up going towards interest on cUSD, that would be 3M x $3 per Celo = $9M in annual interest on cUSD, which would be an interest rate of about 9%.

That rate - over time - would get competed down as volume comes in. Let’s say it got competed down to 2%. That implies the outstanding volume of cUSD deposited would be about $9M / 2% = $450M. So, cUSD outstanding would go up 4.5X .

However, as people buy in to cUSD, this requires CELO, so there should be upwards pressure on CELO. This increases the value of epoch rewards, which increases the rate of interest paid. So the increase in cUSD demand could be greater. Of course, this logic applies in reverse as well, so if CELO price drops, there is less money to pay interest - more on that later in the “Crypto Crash” section.

A thought on the efficiency of staking rewards
Lots of protocols pay staking rewards (Ethereum PoS, Cardano etc.). Rates are around 5-7% - like Celo. To a large degree, the rate doesn’t matter much though. You own Celo or Ethereum because you think it will 10X or 100X, not because of the 5% yield. So, one can argue that Celo spending lots of epoch rewards to incentivise locking is not very efficient. In other words, locking is - particularly for a smaller protocol - quite inelastic. People lock if the rate is positive but they don’t change behaviour much if the rate is 3% versus 8% on Celo.

Rather than direct all rewards towards locking of Celo, it’s interesting to think about having a portion directed towards establishing risk free interest rates on cStables (as this proposal does). If we think about financial inclusion and emerging markets, it seems a lot more practical to offer people a “risk-free” savings rate on cStables then to have them understand the complexities of owning Celo and locking that.

Crypto Crash
A key scenario to think about is what happens when there is a crypto market crash in which Celo price crashes too. Obviously this reduces the interest that can be paid (under this new system) to cStables.

However, we know that in a crypto market crash, money moves into stables. In TradFi, when stocks crash, the money moves to bonds. In crypto, when prices crash, money largely moves out into fiat (and some moves into Tether) - which is crushing for protocols. To the extent we can have solid cStables that offer some yield (even if that yield declines in a crypto crash), we can keep funds within the Celo ecosystem rather than have it leave during a crash.

I hope there can be some deep consideration and action on this during Celo Connect to either find a fatal flaw or to push this through a CGP.

5 Likes

This penalty remains, yes?

From a user perspective, researching and ‘voting’ for a validator seems very, very, problematic to me on a currency that I’m hopefully going to be using to buy groceries and pay rent with, that I’m holding as dry powder ready to invest with.

It puts the user of cUSD in the position of having to regularly and constantly keep up with the reward rates available, the go through the process of choosing that validator in Valora and doing the Valora approval or maybe even having to switch wallets…

Seriously, would anyone here really do that work once a week or even once a month for your interest bearing checking account at the bank where you keep your fiat money?

If I, as a retail user, was expected to do that much work I’d probably be looking for a new bank.

Do you really think that work-a-day person in Columbia or the Phillipeans or Eastern Utah has the time or will or understanding to vote on this stuff.

Complexity is a bane and this looks like it’s going to be complex to use for non-nerds.

I really do see this as a fatal flaw.

I fully agree that if Celo’s stable coins paid interest there would be much greater demand. This is a truly worthwhile goal.

I do think though that the use case must be truly simple to be marketable and gain acceptance.

It should not take investment research and maintenance to run an electronic interest bearing checking account.

So, where’s the supporting data for this?

To me it seems like a fair number of assumptions and suppositions are being made without much testing/piloting of the idea.

I asked above for the results of any modeling and that hasn’t been put forward.

I’m going to quote from the other thread where I’ve been conversing with John and Ying.

I’d like to see this go 14 or 40 years.

There are other ways to provide interest to the stable coin holders.

2 Likes

Thanks @markbarendt

Slashing
Slashing and downtime penalties remain in place on Celo rewards. Yes.

Easy for Users
You are right that this needs to be simple for the user, and this is allowed for by the proposal. Wallets will automatically be able to assign cStables to the validators paying the highest interest rate. From the user’s perspective, this will be like a checking/savings account. They just deposit funds to their wallet, earn interest, and spend when needed. They don’t need to think about voting. This automation does not pose a security risk because cStables assignments/deposits have no impact on validator election.

Efficiency of staking
My wording was perhaps too strong, but I think it’s worth questioning the efficiency of how rewards currently go primarily to locked Celo instead of to cStables. And, I see an opportunity from this consideration.

One piece of empirical data you can look at is how the percentage of locked celo has changed (or not changed much) since we had a CGP that tied the rewards rate to the percentage locked.

Modelling
I disagree with the need for detailled modelling here. When it comes to complex systems, having complex models often leads to overconfidence in the results.

Rather, I advocate simple analysis on a scenario basis (e.g. what happens in a crypto crash OR what happens if 3M Celo goes to cUSD OR what happens if someone tries to attack by doing X).

If you have some further scenarios, please do suggest them and we can think about them. This is an excellent way to think about robustness.

Prosperity for All
I think we are aiming to evolve protocol incentives so that we have the right short term incentives to drive adoption, while also having a system that will be sustainable in the long run.

Other ways to provide interest
The other ways I can think of are:

  1. Valora supercharge - this has the drawback that it’s not credible it can be sustained.
  2. Directly assigning epoch rewards to cStables (e.g. let’s direct 3M Celo to stables each year). The problem here is that there isn’t a good market mechanism for setting interest rates. We would be manually guessing what the right equilibrium rates should be for cUSD, cEUR, cREAL etc. It’s very hard to see how we could get this right.

Proof of Deposit provides a market based mechanism for providing interest, and it should be sustainable because the interest rate comes from validators via what currently are validator + locked Celo + transaction fees . Epoch rewards will continue for quite a while, and after that, if the network is successful, transaction fees should be meaningful.

It’s worth noting that right now we are “guessing” what the market rate for paying validators should be (65k cUSD). Proof of Deposit also solves this problem because it turns being a validator into being market based where Validator profit = Rewards minus operating costs minus interest payments.

Could you lay out some other ways that we could pay interest on cStables along with their pros and cons? I’m open to finding better ways because I agree with you that having a deposit rate (with easy user experience) could help us achieve community goals. Cheers.

2 Likes

I still see the interest rate considerations as a perverse incentive, that risk may be worth taking but I’m not truly sold on that.

As to simplicity from a user perspective I would hope for absolutely no interaction needed at the users end.

On my way to work so my responses will filter in.