Reserve contract receives JS metering fees; IST fees distributed to reward pool and reserve

[rowgraus]

This ticket covers inflows to the Reserve as well as how the Reserve covers shortfalls from vault liquidations

Inflows to the Reserve should include:

• All IST generated from execution fees (gas) on the Agoric chain should flow to an IST purse controlled by the Reserve Reward distribution mechanics #5427
• 50% of fees collected from Inter Protocol contracts go to the Reserve. Best if this is a governable parameter. Fee distributor contract #5448

Reward distribution mechanics

• Daily, 10% of total reward purse should be distributed to stakers/validators as rewards (simple smoothing function) Reward distribution mechanics #5427

[Tartuffo]

@warner @michaelfig Need a vBank purse for the Cosmos layer to put fees into.
That vBank purse then needs to be available in the vault contract, to cover defaults. Needs to be setup in bootstrap.

[Tartuffo]

@dckc Dan you are the primary on this. LMK if that is problematic.

[dtribble]

The Reserve pool now exists, so this should be unblocked.

[dckc]

Need a vBank purse for the Cosmos layer to put fees into.

I'm looking at packages/vats/src/vat-bank.js and I don't see how to do this. What should I be looking at, @michaelfig ? @JimLarson ?

[michaelfig]

We will change the vbank from getFeeCollector() to getRewardsCollector() and getReserveCollector(), each of which is backed by a different cosmos-level module account. getRewardsCollector() is backed by the x/distr module account, getReserveCollector() is backed by a new vbank-created account.

The reserve pool will get a virtual purse via bootstrap from a closely-held vbank getReservePurse() method, so that it can manipulate the cosmos-level module account's balance from the JS side.

[rowgraus]

Updated to include discussion on vault shortfall mechanics

[rowgraus]

Discussed in RUN Protocol engineering meeting last week. Separating out ticket for reserve to cover shortfalls from liquidations: #5299

[Tartuffo]

We need to make this as small as possible to handle fees in MN-1. Maybe we don't even need this if we only use Cosmos-level feed.

[dckc]

@dtribble suggested we get more clarity on what are all the fees collected in the system and where they go. I offered to give it a whirl.

@arirubinstein I hope to get your help.

[dckc]

Survey of fees in the system

Solid lines are implemented; dotted lines are planned. This "JS metering" ticket seems to be about the x/swingset fees.

Loading

graph LR
    x/swingset -->|msg fee pt1| x/distribution
    x/swingset -.->|msg fee pt2| Reserve
    Vaults -->|mint fee| Collector[Reward Collector]
    Liquidation -->|penalty| Reserve
    AMM -->|swap fee| Collector
    AMM -.->|initial liquidity| Reserve
    PSM -->|swap fee| Collector
    Boost -->|mint fee| Collector
    Collector --> VBANK --> x/distribution --> stakers
    Collector -.->|overflow| Reserve

TODO:

• Do fees go from the AMM / Vaults / Boost go to the reserve?
• figure out how cosmos gas fits in.

Liquidation penalty is #5367

AMM, Vaults, runStake/Boost

When Inter protocol is started, in startRewardDistributor:

agoric-sdk/packages/run-protocol/src/proposals/econ-behaviors.js

Lines 534 to 539 in e570a8d

	await E(vats.distributeFees).buildDistributor(
	[vaultAdmin, ammAdmin, runStakeAdmin].map(cf =>
	E(vats.distributeFees).makeFeeCollector(zoe, cf),
	),
	feeCollectorDepositFacet,
	epochTimerService,

This uses a vat created at bootstrap: (ISSUE: why? why not a contract in the Inter protocol?)

agoric-sdk/packages/vats/src/distributeFees.js

Lines 42 to 48 in e570a8d

	async function schedulePayments() {
	contracts.map(contract =>
	E(contract)
	.collectFees()
	.then(payment => E(feeDepositFacet).receive(payment)),
	);
	}

Finally, each of the 3 contracts collects fees, for example, at AMM swap

agoric-sdk/packages/run-protocol/src/vpool-xyk-amm/singlePool.js

Line 23 in e570a8d

context.state.protocolSeat.incrementBy(harden({ RUN: prices.protocolFee }));

creator may collect them:

agoric-sdk/packages/run-protocol/src/vpool-xyk-amm/multipoolMarketMaker.js

Lines 90 to 91 in e570a8d

	* The creatorFacet has one method (makeCollectFeesInvitation, which returns
	* collected fees to the creator). `handleParamGovernance()` adds internal

Swingset message fees

agoric-sdk/golang/cosmos/x/swingset/keeper/keeper.go

Lines 185 to 189 in e570a8d

	// Charge the account immediately if they owe more than BeansPerMinFeeDebit.
	// NOTE: We assume that BeansPerMinFeeDebit is a multiple of BeansPerFeeUnit.
	feeCoins, _ := feeDecCoins.TruncateDecimal()
	if !feeCoins.IsZero() {
	err := k.bankKeeper.SendCoinsFromAccountToModule(ctx, addr, k.feeCollectorName, feeCoins)

agoric-sdk/packages/cosmic-swingset/src/sim-params.js

Lines 35 to 40 in e570a8d

	// TODO: create the cost model we want, and update these to be more principled.
	// These defaults currently make deploying an ag-solo cost less than $1.00.
	export const defaultBeansPerInboundTx = defaultBeansPerFeeUnit / 100n; // $0.01
	export const defaultBeansPerMessage = defaultBeansPerFeeUnit / 1_000n; // $0.001
	export const defaultBeansPerMessageByte = defaultBeansPerFeeUnit / 50_000n; // $0.0002
	export const defaultBeansPerMinFeeDebit = defaultBeansPerFeeUnit / 5n; // $0.2

TODO:

• confirm that they go to BLD holders via x/distribution

[Chris-Hibbert]

#5377 will add a requirement that AMM creation enforces a minimum initial liquidity. The corresponding liquidity tokens should be sent to the Reserve.

[dckc]

today's Inter meeting discussion:

• make a contract
  • for now, leave the 50% as a contract term; postpone making it governable