RUN rewards go first to pay off getRUN balance

[dckc]

What is the Problem Being Solved?

BLD stakers can getRUN to get liquid RUN in exchange for a lien on their BLD.

This is somewhat like a vault, but it doesn't liquidate. Instead, until the balance is paid off, any RUN rewards for the relevant account go to pay down the balance.

This ticket covers the functionality needed to intervene in the RUN rewards stream and pay down user debts.

Note: Current plan is this functionality does not launch with Mainnet 1

Description of the Design

Mainnet 1 Design: N/A; launch with manual payback

Future Design:
After each epoch, when RUN rewards are collected, service iterates over users with outstanding getRUN balances, calculates expected RUN rewards, and reduces balance in lieu of paying out RUN.

Acceptance Criteria

• All user with no outstanding getRUN balance receives RUN rewards proportional to BLD staked
• All users with outstanding getRUN balance receives no RUN rewards, but getRUN debt balance is reduced by the amount they should have received based on BLD staked
• All users with getRUN balances which are paid off in full by the RUN rewards for an epoch show a getRUN debt balance of zero and have received the remainder of their RUN rewards

Security Considerations

Test Plan

cc @rowgraus @dtribble @Chris-Hibbert

[Tartuffo]

Investigate alternative mechanism - a tool to run through everything and pay off debts. @dtribble to find out fro Zaki what is new in the Cosmos space for this. Then Dan can pick it up, but lowest prio for MN-1.

[Tartuffo]

@JimLarson to add a ticket to do the design of doing this in Golang, using the hook Jim put in. They we will decide between implementing this in Go or in JS. Doing it in Go will likely be faster to impl.

[JimLarson]

Wrote a rough design in #4466. It's complicated a little by the need to do some duplicate bookkeeping on the Golang side so it can synchronously know the remaining debt. The golang side could even be the record of truth for the getRUN state. But this interacts with the planned design of the JS level code.

[dckc]

On 3 March, @dtribble had an idea: `claimUpTo(address, qty) => claimedQty` or in batch: ```js claimUpTo: async (addresses, debts) => { return zip(addresses, debts).map(([a, q]) => min(rewardsPending.get(a) || 0n, q), ); }, ``` oops... that's missing denom. Anyway... We had a good discussion of this and #4466 last Fri (18 March). We recalled that on 16 Feb, we decided to go with the approach in #4466. That approach seems to involve having the JS layer keep the golang layer informed about balance changes. But what about accrued interest? Does this mean a bridge crossing for every account for every epoch? OTOH, is the claimUpTo approach any more efficient? My head was too full to think about it further that day. Today, I wonder: perhaps the golang side can do the same calculation to apply interest to the debt on demand?

…

On Fri, Feb 4, 2022 at 9:13 PM Jim Larson ***@***.***> wrote: Wrote a rough design in #4466 <#4466>. ...

[JimLarson]

Note that RUN rewards for clawback vesting accounts will first segregate the unvested fraction of the reward, then the getRUN (or WYLawayTheHours) repayment is taken out of the vested fraction.

[dckc]

@Tartuffo @rowgraus @dtribble @jessysaurusrex thoughts on priority of this for the May 30 target?

@Tartuffo should this be on my radar? It fell off a bit; the issue history shows I was un-assigned by you Apr 6.

[aj-agoric]

Closing as discussed in today's Triage meeting.