Using Agoric Beans v2 as a deflationary mechanism

Governance
1

Governance > Parameter Changes

Agoric’s existing split-fee architecture (gas vs. beans) could be improved to enable mechanisms like those discussed in Introduce a deflationary mechanism: burn 1 BLD for every staking reward claim.

How We Got Here

TL;DR: Agoric “beans” are similar to gas, but the chain uses a governance-controlled menu to count and accumulate them in the transaction submitter’s x/swingset bean debt. When a submitter’s bean debt exceeds a batching threshold, the debt is converted into Cosmos coins which are deducted from the transaction submitter’s x/bank account.

You can skip to New Requirements if you don’t want to read all the context.

History

When Agoric first needed to prevent abuse of Cosmos messages that result in triggering on-chain JavaScript (JS contracts running under our SwingSet kernel), we were faced with some difficulties.

Our async JS contract model did not make Cosmos’s synchronous gas estimation possible. At most, simulation could count the Cosmos gas required for the synchronous operation of queueing a message to SwingSet. However, the async work performed as a consequence of processing that message would definitely not be knowable synchronously.

We came up with some designs to track (more or less precise) billing of JS contract work to the right entity, but we did not yet fully implement them. Instead, we focused on what was possible with a deterministic one-time fee.

Status Quo

Today, the Cosmos x/swingset module exposes a governance-controlled menu of “bean” prices. That menu is consulted to calculate the approximate net cost of inbound async messages.

Whenever the accumulated bean account debt is greater than a threshold parameter, its value is translated into Cosmos coins which are deducted from the submitter’s Cosmos x/bank account.

This, unfortunately, is “spooky action at a distance”, since the x/bank deductions made during a tx aren’t visibly surfaced in the synchronous transaction data presented to the submitter for signing before execution. Having said that, the model may still be acceptable as part of the fees paid by contracts themselves, since they are already fully async.

At the time, there didn’t seem to be a way to group the synchronous bean fees with the gas fees without detrimentally affecting the Cosmos gas price calculations. Now, after more investigation, there is a relatively simple solution which forms the underpinnings for this proposal.

New Requirements

The community’s agreement for the need of a deflationary mechanism seems to imply the following new requirements for the Agoric fee model:

  1. All deflation-related params must be controllable by staker governance (no further software-upgrade required to change them)
  2. Deflation parameters should be overridable per tx message type
  3. Deflation fees should be surfaced to clients by accounting for them in gas estimates
  4. Gas and fees due to deflation must be skimmed before conventional tx execution, to ensure the mechanism is compatible with the existing chain

Proposed Plan

These requirements can be satisfied by improving the existing bean counting mechanism, and lean into an AnteHandlerDecorator to enforce the new policies. We can introduce a minimum gas price parameter, then increase simulation gas estimates so that a client (which has an independently-specified gas price) uses the combined gas limits and thus combined fee amounts. During execution, deduct the extra portion of the gas limit and burn (or collect) its corresponding extra portion of the fee, before continuing with the builtin Cosmos SDK gas and fee deduction.

  1. enable custom bean counting of arbitrary transactions by including a new governance parameter (arrays of entries for deterministic ordering instead of maps or records): msgTypeBeanOverrides: Array<[MsgType, Array<[Unit, UIntString]>]>. For example:
const msgTypeBeanOverrides = [
  // Charge an arbitrary number of beans per withdraw reward message.
  [ '/cosmos.distribution.v1beta1.MsgWithdrawDelegatorReward',[
      ['message', '1000000000']
    ],
  ],
};
  1. during simulation, embed all synchronous fees (including beans) by using the beans-to-BLD with a new minimum gas price parameter to determine the gas value due to beans
  2. during execution, deduct the gas and fees calculated due to beans, then divide the deducted fees via parameters into an amount to burn, or send to other destinations (e.g. feeCollector, etc.) before continuing with the standard Cosmos gas/fee ante handler processing
  3. Migrate x/swingset’s current Go code that calculates beans into equivalent msgTypeBeanOverrides governance params

Thoughts?

3 Likes
Introduce a deflationary mechanism: burn 1 BLD for every staking reward claim
2

Strong support for this proposal. The key improvement over the original burn-per-claim idea is that msgTypeBeanOverrides builds general rails rather than a one-off mechanism — governance can extend burn parameters to any message type later (including orchestration-related flows as network activity grows) without another software upgrade. That flexibility is worth the implementation effort by itself.

1 Like
3

Solid proposal. Making bean fees transparent, controllable by governance, and properly surfaced in gas estimates is a big improvement over the current setup. I like that it enables clean deflationary mechanics without needing constant upgrades. This feels like the right direction for the deflationary model. Supportive of this approach.

1 Like
4

Strong support for this proposal.

5

Something similar to internet computer cycles and canisters