# Zcash Shielded Hosting Fee Mechanism

This document presents a Zcash-focused `Shielded Hosting Fee Mechansism`, aka `SHF Mechanism`. Shielded Hosting Fees pay out a fee rate in block rewards, then ensure the matching amount is privately deducted in zero-knowledge proofs.

## Abstract

Hosting fees result in transfers from holders into block rewards in each block. Hosting fees are charged at a given proportional rate per block from all holders of a shielded asset. The aggregate payments accrue into block rewards.

The total supply of the asset is publicly visible in each block, and so are the aggregate hosting fee rewards. However, the number of holders of the asset, and the amounts each hold are private.

The total supply of an asset, the distribution between holders, and the hosting fee rate may all vary between blocks with this mechanism, which allows this scheme to support wrapped or bridged tokens that must maintain a specific price/supply peg.

This mechanism works for any given asset type independently of others. It may be a useful component of a multi-asset system by itself, or it may be combined with other cross-asset mechanisms.

This scheme is isomorphic to existing `ZEC` creation using a different unit of account. We introduce this separate unit `nZEC` and show the distributional equivalence. This helps elucidate differing interpretations of Zcash's existing monetary policy with mathematical rigour.

## Motivation

In Zcash currently, `ZEC` holders pay something almost equivalent to hosting fees in the form of new `ZEC` issuance into block rewards. The difference from this scheme is in the units of account: if a holder holds $X$ units of `ZEC` over time $X$ does not vary and instead the total supply increases.

In this scheme the total supply of an asset $A$ does not change as hosting fees are transferred, and instead a user who holds $Y_{t_0}$ units of $A$ at time time $t_0$ will hold $Y_t < Y_{t_0}$ units at a later time $t$ to account for paying hosting fees.

While this different scheme of units of account does not matter for `ZEC` itself currently, it becomes important if Zcash is extended to support multiple assets *and* the supply of those assets must not be altered by hosting fees. A key use case is if assets which represent wrapped tokens from another blockchain (or any other source). In that scenario, this mechanism allows holders of that other asset $A$ to pay hosting fees in a manner distributionally equivalent to `ZEC` holders, *without* altering the total supply of $A$ which must be managed by a separate issuance mechanism.

For example, if Zcash can support a `fooBTC` asset which is pegged 1:1 with `BTC`, and 1000 `BTC` has migrated to `fooBTC` on the Zcash network, the holders of `fooBTC` can pay for their use of the network with this mechanism without breaking the 1:1 peg between `fooBTC` and native `BTC`.

This document is not a specific proposal for altering Zcash; rather it is an economic building block which may be useful to integrate into other more complete multi-asset support proposals moving forward.

As of this writing, Zcash community is actively discussing extensions for multi-asset support, sometimes called Zcash Shielded Assets or ZSAs.[^shield_all_the_things] A key open question in a complete ZSA design is finding a sustainable economic mechanism design to ensure multi-asset support sustains Zcash moving forward. This SHF Mechanism design provides one possible mechanism to address this open question.

[^shield_all_the_things]: Both the label "Zcash Shielded Assets" and this design document assume multi-asset support will be provided entirely within a Zcash shielded pool, without support in Transparent Addresses.

Finally, note that this mechanism isn't *specific* to multi-asset support, and even if Zcash remained a single-asset network, introducing hosting fees independent of the base monetary policy may be an important option for future economic improvements.

## Multi-asset Considerations

While the primary motivation for this SHF Mechanism is to enable economically sustainable multi-asset support, this mechanism itself is *asset-specific*. The design applies to each asset type independently without considering other assets. There is no cross-asset requirement of this design, such as price oracles or asset exchange mechanism.

This simplifying assumption presents several implications when considering multi-asset support:

- Hosting fees for an asset type are assessed against amounts of only that asset, so any fee assessment is independent across assets.
- Each asset type is assumed to have a specific associated `fee schedule`. However, in multi-asset, different asset types may have different schedules.
- The hosting fees are transfers from holders to fee recipients denominated in the asset type itself. In a multi-asset system, recipients would therefore receive fees denominated in every distinct asset type with non-zero hosting fees.
- Each asset type must be associated with a `hosting fee schedule` (described in [Design Specification](#Design-Specification)), although there could be different schedules for different asset types.

In a multi-asset system, this SHF Mechanism could be used as-is, or it may potentially be combined with various separate cross-asset mechanisms. For example, it may be possible to design an in-protocol exchange system which could convert hosting fees from many asset types into a single type for a recipient, if desireable.

## Design Specification

This section presents a high-level design that focuses on the pecuniary layer with enough specificity to integrate into a full Zcash consensus rule modification proposal.

A complete Zcash Improvement Proposal which relies on this mechanism will also need to specify explicit consensus rule changes, including: ZKP circuit requirements, issuance/redemption operations, hosting fee recipient rules, numeric error considerations, and more.

### Global Consensus State

This design requires new global consensus state associated with each block. Block producers must calculate and commit to correct values, and validators must ensure these values are correct as part of block consensus checks.

This state consists of a single scalar `hosting remainder accumulator` for each `hosting fee schedule`.

Let $f_h$ be the `hosting fee rate` at height $h$ for the target asset:

$$
f_h \in [0, 1]
$$

A value of 0 means no hosting fees at height $h$. A value of 1 means all funds are transferred completely as hosting fees in block $h$.

**Example:** Assuming blocks arrive approximately every 75 seconds, a constant fee schedule of $f_h = 5.95227534 \times 10^{-9}$ results in annual hosting fees of about 25 basis points, or 0.25%.

This mechanism description does not specify $f_h$. Specifying this value is required for a complete consensus rule proposal. This design supports $f_h$ varying on a per-block granularity.

The remainder, $r_h$, is the proportion of the asset remaining after hosting fees are deducted at height $h$:

$$
r_h = 1 - f_h
$$

Because all amounts or any aggregate of amounts pay hosting fees proportional to their sum, the remainder can be applied to the total supply or any given amount coherently.

Let $R_h$ be the `hosting remainder accumulator` at height $h$:

$$
R_h = \prod_{0 ≤ k < h}{r_k}
$$

The value of $R_h$ must be updated once per block by multiplying $R_{h-1} \times r_h$.[^one_fee_rate_per_schedule]

[^one_fee_rate_per_schedule]: If there are multiple `fee rates` each one must be tracked explicitly with it's own separate $R_h$.

### Supply Conservation

The total supply $S_h$ is always known for every block height. This mechanism never alters the supply $S_h$. However, this mechanism *does* operate correctly when combined with separate mechanisms which alter the supply over blocks, such as provided by cross-chain issuance/redeem features.

The property of SHF of not altering the supply is called the `supply conservation constraint`. To meet this constraint, SHF must ensure this amount paid out is exactly equal to the amount deducted from all holders in block $h$, which is described below.

After describing the payout and deduction mechanisms and arguing they preserve `supply conservation constraint`, we re-examine the behavior in the face of [Extrinsic Supply Changes](#Extrinsic-Supply-Changes) which come from outside this mechanism.

### Hosting Fee Payouts

In each block, hosting fees are paid out to whichever recipients a final design designates. This document is agnostic to the fee recipients. A plausible example could be that these fees accrue to miners and Dev Fund recipients, similar to new `ZEC` issuance in Zcash NU4.

The amount paid out in a block is transparent, although this document assumes all value is then encoded into private `notes` within that same block, similar to the `Shielded Coinbase` feature in Zcash NU4.

At block height $h$, the aggregate amount paid out, $F_h$, is defined by the fee rate, $f_h$, and the supply *as of the previous block*, $S_{h-1}$:

$$
F_h = f_h \times S_{h-1}
$$

This definition of supply ensures that $S_h$ means "the supply after block $h$ is consensed upon", and the previous-block offset $h-1$ ensures correctness in the face of changing supply, as described in [Extrinsic Supply Changes](#Extrinsic-Supply-Changes).

This amount $F_h$ is transparently committed in the block, and recipients encode that amount into `notes`.

### Deducting Hosting Fees

Any observable amount must ensure the requisite hosting fees have been deducted. By tracking when an amount was received and the current block height, these deductions can be calculated "on demand". Let $a_h$ be an amount at block height $h$ which was received at block height $h_0$, then:

$$
a_h = a_{h_0} \times \prod_{h_0 ≤ k < h}{r_k}
$$

Rather than multiply all of the $r_k$ for every intervening block, this product is equivalent to a simpler product using the `hosting remainder accumulator` at the time the amount was received, $h_0$, and the current value at $h$ (the [Amount Product Derivation](#Amount-Product-Derivation) in given in the appendix):

$$
a_h = a_{h_0} \times R_{h_0}^{-1} \times R_h
$$

Because $A_{h_0}$ and $R_{h_0}$ are known at the time of receipt and do not vary with respect to each other, we introduce $A_{h_0} = \frac{a_{h_0}}{R_{h_0}}$ as a simplification:

$$
a_h = A_{h_0} \times R_h
$$

This amount for any height $h$ *MUST* be correctly displayed to users so that they understand the extent of hosting fee deducations. An end-user UX *should not* ever display $a_{h_0}$, which is merely a computational convenience and does not represent actual value a user controls.[^debug_tools]

[^debug_tools]: An important exception to this UX requirement is made for debugging or expert technical analysis tools, where the user of such tool is expected to understand this protocol value and its implications.

#### Privacy and Note Contents

When a note is spent, the `creation height`, $h_0$, of a note must be private to prevent linkage across creation/spend heights. By implication, anything depending on $h_0$ must also be private. Therefore, to support this hosting fee mechanism, each `note` must privately contain $AR_{h_0}$. Importantly, multiplying the two terms of $A_h$ can be done privately in constant space within a ZKP circuit statement implementing this mechanism. The ZKP circuit design and its efficiency is open future work.

#### Spend Height

Shielded Zcash transactions must be created prior to inclusion in a block, yet they must include a proof that the notes they spend were previously created. In this hosting fee scheme, they must also prove that the hosting fees have been properly deducted from a note amount up to "an appropriate" height.

This proof must be completed prior to inclusion in a block, and cannot trivially rely on any prediction at what height a transaction will be included into a block.

Instead, this scheme requires that a transaction, $t$, commit to a `spend height`, $h_t$, which is a publicly visible value associated with the transaction.

In the existing Zcash NU4 protocol, the proof that all inputs spent in a transaction were previously committed also must commit to some height prior to which the inputs are committed with an associated `anchor`, so it's natural to use the same height value for `spend height`.

The above calculation of remaining funds for a note after deducting hosting fees then uses this $h_t$ rather than the current block height $h$:

$$
a_{h_t} = A_{h_0} \times R_{h_t}
$$

*Crucially* all new notes created in a transaction with `spend height` $h_t$ *MUST* use that height as the `creation height` of all newly created notes. So for every note, its $h_0$ is equal to the $h_t$ of the transaction which created it.

We keep these notation distinct, to help us separately consider notes being spent versus notes being created by a transaction:

- All notes created by a transaction must have $h_0 = h_t$ for that transaction.
- Each note being spent by a transaction has a separate, note-specific $h_0 < h_t$ value.

#### Observable Supply Consistency

The use of `spend height` enables private deduction of hosting fees, but it complicates the `supply conservation constraint`; if a block at height $h$ includes a transaction with a very old `spend height` $h_t ⪡ h$, how can we reason about supply integrity?

The creator of the transaction proved they paid hosting fees from an old note $n_{old}$ only up to the very outdated height $h_t$, *not* all hosting fees due up to height $h$. However, the new note, $n_{new}$ has `creation height` set to this old $h_t$, so the present value of this $n_{new}$ note which a recipient effectively receives is:

$$
a_h = A_{h_t} \times R_{h}$
$$

This deducts all hosting fees from the `spend height` up to the height of interest, $h$, because it's equivalent to: $a_h = A_{h_t} \times \prod_{h_t ≤ k < h}{r_k}$

At each height, $k$, in the product, $r_k \in [0, 1]$. For every height with $r_k > 0$ the product diminishes, and this accounts for the hosting fees up to $h$.

Remember it is necessary that any UX *MUST* display the estimated current value $a_h$ regardless of the age of the note so that the recipient correctly sees the full hosting fee deductions.

With both this UX requirement and the requirement that note creation must encode the spend height as each new notes $h_0$, we argue there is no user-observable deviation from supply consistency.

It is also important to ensure that any amounts outside of notes also appropriately account for hosting fee deductions, a caveat we return to below when considering [Supply Consistency on Removal](#Supply-Consistency-on-Removal) in extrinsic supply changes, next.

## Extrinsic Supply Changes

With both hosting fee payouts and hosting fee deductions accounted for and argued to be observably equal above, we now turn our attention to extrinsic (with respect to SHF) changes of the target asset supply.

This SHF Mechanism is `oblivious` to such changes in the total supply of the target asset so long as these constraints are met:

- All changes to the supply are publicly visible, and
- Any newly created supply at height $h$ is captured in newly created notes with $h_0 = h$.
- Any transparently removed supply properly deducts hosting fees outside of the ZKP circuit context.
- The hosting fee payout in block $h$ *MUST exclude* the newly issued assets. This constraint is already provided for when introducing the aggregate payout formula above, $F_h = f_h \times S_{h-1}$, as is captured by the prior-block offset $h-1$.

The use of the term `oblivious` here indicates that the mechanism functions correctly regardless of any separate mechanisms for altering the supply so long as the constraints are met. This is a key feature to enable separate flexible issuance/redemption mechanisms.

### Supply Consistency on Creation

Consider that in the block at height $h$ new assets are issued: $S_{h} = S_{h-1} + \Delta S_h$ where $\Delta S_h > 0$

#### Payout Consistency

Recall the aggregate payout formula from above is: $F_h = f_h \times S_{h-1}$

This excludes the new supply $\Delta S_h$, so as of block height $h$, payouts are oblivious by definition.

Consider the next block $h+1$ where the aggregate payout is then:

$$
F_{h+1} = f_{h+1} \times S_h = f_{h+1} \times (S_{h-1} + \Delta S_h)
$$

The aggregate payout mechanism now covers the new supply, $\Delta S_h$. Because aggregate payouts are based only on the previous height's supply and no other longer term state, it is oblivious to changes in the supply. *So long as* deductions correctly match, the payout side is taken care of.

#### Deduction Consistency

Now let's ensure private hosting fee deductions match the required $F_h$ payout:

The amount is publicly validated by consensus by the first constraint, and the new supply $\Delta S_h$ must be encoded into new notes with $h_0 = h$ by the second constraint. For each such new note at height $h$ we then have this note value remainder calculation:

- $a_h = A_{h_0} \times R_h$
- $a_h = a_{h_0} \times R_{h_0}^{-1} \times R_h$
- $a_h = a_{h_0} \times R_{h_0}^{-1} \times R_{h_0}$ because $h_0 = h$
- $a_h = a_{h_0}$

The new notes store the literal amount encoded into them by the asset extrinsic creation mechanism, and no funds have been deducted. This matches [Payout Consistency](#Payout-Consistency) above where the aggregate payout excludes the new supply.

Meanwhile, the same is true of any other notes created at height $h$ due to ZKP transfers.

Finally, any pre-existing notes which were not created as part of new supply creation, as well as any notes spent by a transfer are correctly deducted $f_h$ proportional to their size. The total of all such notes is $S_{h-1}$, which is precisely the supply term in the aggregate payout formula $F_h = f_h \times S_{h-1}$.

### Supply Consistency on Removal

Extrinsic supply removal occurs when the visible supply of the asset decreases by an extrinsic mechanism: $S_{h} = S_{h-1} + \Delta S_h$ where $\Delta S_h < 0$

In this case, previously existing notes must be spent and their value is not encoded into newly formed notes. Presumably the extrinsic supply change mechanism does something useful with this, such as for an issuer to enact a redemption of a wrapped token.

#### Payout Consistency

The aggregate payout equation covers $S_{h-1}$ so any supply destroyed in block $h$ has already contributed to the aggregate payout by definition.

#### Deduction Consistency

A transaction which contributes supply to be removed ensures within the ZKP formula but only up to the spend height $h_t$. Recall that the spend height must be less than the current block height $h_t < h$, so there is a "gap" in deductions for that window.

Here we must introduce a new visible consensus rule modification, scoped to a specific transaction, $txn$, to ensure the funds to be redeemed have the appropriate amount deducted from height $h_t$ up to $h$ to cover hosting fee payouts for this gap:

$$
a^{removed}_{txn} = a^{*}_{txn} \times R_{h_t}^{-1} \times R_{h}
$$

Here we introduce $a^{*}_{txn}$ which the ZKP layer must ensure is the sum amount spent across all spent notes which is to be applied to removal. This amount and it's application to a supply removal operation must be publicly encoded in $txn$. The transaction creator proves the value of $a^{*}_{txn}$ is correctly accounted for via the ZKP private hosting fee deductions summed across all note values contributing to the public supply removal. Then validating nodes must calculate $a^{removed}_{txn}$ in order to apply this final amount towards any removal mechanism. Note that in this case, validators must multiple by $R_{h_t}^{-1}$ explicitly, rather than an $A_{…}$ style product term, because the latter are note-specific.

##### Private Redemption

Explicit extrinsic supply removal can support the `redemption` of a pegged/bridged token by an issuer or extrinsic protocol mechanism. However, an issuer could support "private redemptions" where a user transfers some wrapped asset to the issuer's private address. The issuer can then redeem the underlying asset to the user.

For example, a user may privately send $X$ units of `fooBTC` on a future multi-asset Zcash protocol to the `fooBTC` issuer's Z-Address, then that issuer would redeem $X$ `BTC` to the user on Bitcoin's blockchain.

By dint of the privacy of this arrangement, the publicly tracked supply $S_h$ will not be reduced. This fact immediately highlights a risk of this scheme because $S_h$ can no longer reliably track the correct outstanding issued supply. In fact, because $S_h$ is larger than the correct value for a pegged asset, the very next block will transfer hosting fees on this incorrect amount, and the wrapped tokens supply will immediately be larger than the backing token supply.

Therefore it is essential that proper issuance for pegged tokens use the explicit extrinsic supply reduction mechanism to implement redemptions.

## Conclusion

This Shielded Hosting Fee Mechanism introduces a means of privately charging a target asset holder a hosting fee proportional to their holdings. The fee rate can vary over block heights, and a multi-asset protocol may utilize multiple fee schedules. By remaining oblivious to extrinsic supply changes, this mechanism can integrate with different supply change rules, such as issuance/redemption operations for pegged/bridged tokens. This mechanism is a feasible delta from the existing Zcash private circuit design that can also work in a future multi-asset extension.

## Future Work

This document does not cover ZKP circuit design for the proposed balance changes.

This document does not cover computational numeric error considerations. In particular, the continual multiplication of $R_h = R_{h-1} * f_h$

## Acknowledgements

I owe personally discovering the possibility and value of privacy-preserving hosting fees which conserve supply to Zooko and discussions with the Electric Coin Co. Scientific Advisory Group: Arthur Breitman, Vitalik Buterin, Mary Maller, Zaki Manian, and Gordon Mohr.

The `hosting remainder accumulator` scheme is directly inspired from the Zcash PEG Zone and Penumbra designs from Henry de Valence.

# Appendicies

## nZEC

Here we introduce a new fictional unit `nZEC` which is defined to distribute block rewards only through this SHF mechanism (ignoring transaction fees). Then we show how this scheme is distributionally equivalent to `ZEC`, modulo the differing units of account.

**TODO:** Clean this section up and present concrete numbers / graphs for the fee schedule.

### nZEC Supply and Units

The first feature of `nZEC` is that its supply, $S^n$ is constant, and defined to be numerically equal the `ZEC` cap.

The supply of `ZEC` increases through new issuance in each block at a diminishing rate. Eventually, at height $h_E$, the new issuance rate drops to zero, so we define $S^n = S^{ZEC}_{h_E}$

Because the supply is constant, any proportion of the supply, $r^n$ represents exactly $r^n \times S^n$ units of `nZEC`. For example 21,000 `nZEC` is always (approximately) a thousandth of the supply.

### nZEC Distribution

Rather than issue new units as block rewards, `nZEC` funds block rewards via the SHF Mechanism by defining the fee schedule to match the `ZEC` issuance rate proportionally.

At height $h$, the proportion of supply created for `ZEC` block rewards is the ratio of newly issued `ZEC` $\Delta S^{ZEC}_h$ to the supply at that height $S^{ZEC}_h$ so this ratio is used for the hosting fee rate of `nZEC`:

- $f_h = \frac{\Delta S^{ZEC}_h}{S^{ZEC}_h}$

The `aggregate hosting fee` payout at block height $h$ is:

- $F_h = f_h \times S^n$

While `ZEC` $\Delta S^{ZEC}_h$ is constant between halvings or other exceptional transitions, the supply ratio of issuance, `B_h` continually diminishes as the supply denominator $S^{ZEC}_h$ grows, so the hosting fee payouts in units of `nZEC` marginally diminish with each block.

Every `nZEC` balance pays hosting fees at each block as described above in FIXME LINK TO PRIVATE DEDUCTIONS SECTION.

### Comparison to ZEC Supply Proportions

In Zcash, each block introduces newly created `ZEC` units as part of the block reward:

- $S^{ZEC}_h = S^{ZEC}_{h-1} + \Delta S^{ZEC}_h$

The proportion of `ZEC` supply at height $h-1$ to the supply after issuance at height $h$ is:

- $\frac{ S^{ZEC}_{h-1} }{ S^{ZEC}_h }$
- $\frac{ S^{ZEC}_{h-1} }{ S^{ZEC}_h } + \frac{ \Delta S^{ZEC}_h - \Delta S^{ZEC}_h }{ S^{ZEC}_h }$
- $\frac{ S^{ZEC}_{h-1} + \Delta S^{ZEC}_h }{ S^{ZEC}_h } - \frac{ \Delta S^{ZEC}_h }{ S^{ZEC}_h }$
- $\frac{ S^{ZEC}_h }{ S^{ZEC}_h } - \frac{ \Delta S^{ZEC}_h }{ S^{ZEC}_h }$
- $1 - f_h$
- $r_h$

This is precisely the SHF remainder ratio, $r_h$.

#### Hosting Fee Deduction Proportional Equivalence

The total `ZEC` supply is present in `notes`[^utxo_simplification] and the proportion of total supply represented in each note dimishes proportionally to $r_h$.

[^utxo_simplification]: When comparing `nZEC` to `ZEC` we consider transparent UTXO amounts to be effectively equivalent to amounts in encrypted notes.

In units of `nZEC` this deduction is explicitly tracked, since `nZEC` units are proportional to the constant total `nZEC` supply $S^n$.

#### Hosting Fee Payout Proportional Equivalence

The newly issued `ZEC` at height $h$ is:

- $\Delta S^{ZEC}_h$

- $\frac{ \Delta S^{ZEC}_h }{ S^{ZEC}_h } \times S^{ZEC}_h$

- $f_h \times S^{ZEC}_h$

FIXME: We need `ZEC->nZEC` unit conversion to show this is the aggregate SHF payout.

YYY

- $F_h = f_h \times S_{h-1}$

#### ZEC End of Issuance

Once the issuance-per-block reaches 0 at $h_E$, the extant supply will not increase and is capped:

- $S^{ZEC}_{h+1} = S^{ZEC}_{h} = S^{ZEC}_{h_E}$ for $h ≥ h_E$

This supply cap is slight less than 21,000,000 `ZEC`.[^precise_supply_cap]

[^precise_supply_cap]: **TODO:** Calculate this precisely and describe how here.

#### ZEC Supply Ratios

Since the `ZEC` supply grows over time before reaching the cap, a given number of `ZEC` units represents a varying proportion of the currently supply. The proportion of total supply given for $X$ `ZEC` units at height $h$ is $\frac{X}{S^{ZEC}_h}$

When new units are issued as block rewards, the recipients gain a fraction of the total supply, and all prior holders' holdings are reduced proportionally.

Block reward recipients receive a proportion of the supply at block $h$ defiend as $B_h = \frac{\Delta S^{ZEC}_h}{S^{ZEC}_h}$

The proportion of the supply held by everyone else outside this block reward is $R_h = 1 - B_h$

All other holders are diluted proportionally. Before the issuance at height $h-1$, each user holds $X$ `ZEC` whose proportion of the supply is $\frac{X}{S^{ZEC}_{h-1}}$, while after the issuance, each user holds $X$ `ZEC` whose proportion is now $\frac{X}{S^{ZEC}_{h}} = R_h \times \frac{X}{S^{ZEC}_{h-1}}$

## Algebraic Derivations

### Amount Product Derivation

An amount $a_h$ received at $h_0$ has hosting fee deductions for each block up to a target block of interest $h$, which is equivalent to a single multiplication:

- $a_h = a_{h_0} \times \prod_{h_0 ≤ k < h}{r_k}$
- $a_h = a_{h_0} \times [(\prod_{0 ≤ k < h_0}{r_k})^{-1} \times \prod_{0 ≤ k < h_0}{r_k}] \times (\prod_{h_0 ≤ k < h}{r_k})$
- $a_h = a_{h_0} \times (\prod_{0 ≤ k < h_0}{r_k})^{-1} \times \prod_{0 ≤ k < h}{r_k}$
- $a_h = a_{h_0} \times R_{h_0}^{-1} \times R_h$
- $a_h = A_{h_0} \times R_h$

## About this Document

### Distribution

Next steps:

- get feedback/review from ECC team.
- get feedback/review from the ECC SAG.
- get feedback/review from the GMU team.
- write a summary human-language blog post.

### BUGS / FIXMES

I'm not clear at all on boundaries and there are likely off-by-one errors in the products.