TL;DR
- The State Subscription economy has been quoting ten Sync Units for a dollar for some time, yet nothing in the corpus ever fixed what a single Sync Unit counts. Three conversion rates ended up living side by side: one sync per Unit, ten Units per session, and roughly a hundred Units a month for the same user.
- This research defines the Sync Unit as one committed state binding and anchors it to a single-domain S₁ observation. The meter debits at completion only, and a cycle that never commits is metered in part only when the client caused the abort.
- Binding weights are not assigned by preference. The sync degree hierarchy is the weight axis, and each weight decomposes into a capacity term for processing load and a guarantee term for the obligation the network carries on that asset. The decomposition yields 0.25, 1, 4 and 8 across S₀ through S₃.
- Applying degree weights inverts the existing frequency bands. An atomic-binding asset synchronized twenty-five times a year is heavier than an observation asset synchronized two hundred times. Until now the first was classified Light and the second Heavy.
- Rebuilding the unit is separate from raising the price. The definition is revenue neutral by construction, and recalibrating the actual rate is left to follow-up research.
We Have Been Billing in an Undefined Unit
Five studies in the State Subscription economy series have settled cost structure, multi-tier pricing, revenue distribution, token circulation, and rewards and insurance. One unit sits underneath every calculation in all of them. It is the Sync Unit. Entry buys ten Sync Units for a dollar, Growth prepays for a monthly credit block, Enterprise runs against a Unit cap. Burn thresholds, credit rollover volumes, and the usage variance estimate for medium-frequency customers are all denominated in it. In other words, we have been doing oracle usage metering from the beginning without ever writing down what the meter counts.
Nowhere is one Sync Unit defined.
The evidence is inside our own writing. Token Flow Mechanics in State Subscription Economy, discussing unused credit, records that four uses in a month leave 1,196 Units unused. Subtracting four from twelve hundred puts the rate at one synchronization per Unit. A later section of the same study has that same medium-frequency customer consuming about a hundred Units a month. For a customer running four to seventeen synchronizations, that rate has to sit somewhere between six and twenty-five Units per synchronization. Meanwhile the Entry package in From Node Risk Imbalance to Multi-Tier Economics is built as one Unit for session initialization, eight for state updates, one for termination, which makes one session ten Units.
Three rates coexist in one body of work. This is no arithmetic slip. It is the symptom that appears whenever a unit is used for calculation before it is defined. Each study picked whichever conversion read most naturally in its own context, and those picks disagreed.
Two printed pages from the same prior study, highlighted side by side, where one customer tier consumes a different number of Units on each page.
Metrology met this problem long ago. From 1889 to 2019 the kilogram was defined by a single platinum-iridium artifact kept in a vault outside Paris. The trouble was that the artifact’s mass drifted slightly over time. The US National Institute of Standards and Technology, explaining the redefinition, records that “the measured mass of each individual standard changed, or ‘drifted,’ a bit over time” [1]. The world eventually tied the unit to the Planck constant rather than to an object, because a unit moored to a thing moves when the thing moves.
Our Sync Unit is currently moored to a price list. The “ten Units for a dollar” package has been standing in for the definition, so the unit shifts when the price shifts and the conversion shifts when the asset type shifts. This research reverses that relationship. The unit is tied to an invariant of the system first, and the price is then decided on top of it.
Part I. What Oracle Usage Metering Must Count
1.1 Four Conditions for a Metering Unit
Before choosing a billing unit, the conditions a good one must satisfy have to be stated. Four conditions govern any oracle usage metering unit worth adopting.
Invariance. The definition must be independent of price, tier, and packaging. If a price change moves the unit, time series comparison collapses.
Observability. A client must be able to recompute its own bill. Cloud billing research demonstrates the failure mode empirically. Jellinek and colleagues measured billing on EC2, Google Compute Engine and Rackspace, found network traffic undercharged by an average of 3.4 percent and one Rackspace bug overcharging storage by 36.3 percent, and concluded that billing events occur inside the infrastructure and are “largely unobservable to customers” [2]. Sekar and Maniatis formalized the same problem under the name verifiable resource accounting [3]. There is a counterexample worth noticing. Tokens in a language model API are countable by the client before a request is sent, because the tokenizer is public. Whether the meter lives only inside the provider or can be reproduced outside it separates the two cases.
Resistance to manipulation. Neither the client nor the operator should be able to inflate or deflate consumption unilaterally. Where one side can raise the other’s bill, the meter becomes an attack surface.
Commensurability. The unit a client pays and the workload a node is rewarded for must count the same event. Two ledgers counting different events leave no ground for deciding which one is right.
1.2 Three Candidates and Why Two Fail
Three metering bases were examined against those conditions.
Message-based metering is what existing oracles do. One request, one charge. Chainlink Functions documents total cost as gas cost plus premium fees, with an estimate reserved at request time and the actual figure deducted at fulfillment [4]. The structure fits discrete data delivery where requests and responses correspond one to one. In state synchronization a single binding cycle can commit several state changes together, while one logical update can produce several messages across domains. Counting messages leaks our internal batching structure straight onto the invoice.
Computation-based metering is the Ethereum gas approach, pricing operations and storage access and summing them. In state synchronization this basis misses the dominant cost. Our bottleneck is coordination rather than computation: the window a preemptive lock is held, the wait for the slowest domain to finalize, the readiness to run a compensating path on failure. Proof generation is amortized across batches too, so per-item computation cost itself moves with batch size.
Binding-based metering is what we adopt. What state synchronization actually produces is neither a message nor a computation but a commitment that two domains agree on the same fact. That is the thing we sell, so that is the thing to count.
1.3 The Reference Binding: Defining One Sync Unit
Definition. One Sync Unit (SU) is the quantity metered when a single unidirectional observation binding on one domain commits. A cycle at degree S₁, with one bound domain, whose state change stays within the base payload, is exactly 1 SU.
The anchor sits at S₁ because that is the smallest complete event that can be called synchronization. S₀ assets do not change state after issuance, so no binding occurs at all, and S₂ upward involves mutual binding across two domains and is no longer atomic in this sense. For the reason that led metrology to a constant instead of an artifact, we picked the protocol’s minimal complete event instead of a price package.
Three consequences follow at once. First, the meter debits at Commit rather than Bind, since a cycle that locks but never commits delivered no state to the client. Second, the metered object is the cycle rather than the count of state changes, because several deltas committed together are one agreement. Third, not every binding carries the same value. With the reference binding set at one, everything else has to be decided as a multiple of it.
Part II. Where the Weights Come From
2.1 The Capacity Term
There is no need to invent weights. Oraclizer’s system design already carries relative workload by degree. The four degrees defined in Sync Degree Hierarchy travel different processing paths, and design analysis puts those paths in the following ratio. Taking S₃ Full BVC as 1.0, S₂ Soft BVC sits near 0.7, the S₁ lightweight path near 0.2, and S₀ static registration near 0.05. The spread comes from whether mutual rollback is enforced, whether a preemptive lock is acquired and held, and whether proof generation is included.
Since the billing anchor is S₁, the same ratios are renormalized against it.
\(\omega_{cap}(S_0)=0.25\), \(\omega_{cap}(S_1)=1\), \(\omega_{cap}(S_2)=3.5\), \(\omega_{cap}(S_3)=5\)
This is the capacity term. It expresses the relative resource a node actually spends processing that binding.
2.2 The Guarantee Term
Capacity alone is not enough, because the obligation the network carries on an asset exists separately from processing load. Insurance and Recovery Economics fixed session protection priority by degree for the situation where the security threshold breaks. S₃ and S₂ sessions are held up by the insurance emergency tranche acting as a temporary security bond until safe migration, while S₁ and S₀ sessions are force-terminated at the last consistent state.
That decision means the size of an asset’s claim on the network differs by degree. An S₃ asset receives enforced mutual rollback and a priority sequencing slot, and in a crisis it receives bond support as well. An S₂ asset receives eventual consistency recovery through the retry queue along with safe migration. S₁ and S₀ assets receive no guarantee at all.
Charging for a guarantee that is never available is mismetering rather than price discrimination. A distinction is worth drawing here. Cross-subsidy by usage frequency is a strategy, because a customer can move between tiers and adjust. Cross-subsidy by degree is a defect. An asset’s degree is not a value the customer selects; it is a structural requirement determined from five properties at tokenization, recorded in the registry, and forced to S₃ once the asset becomes subject to regulatory action. Making a customer pay for an unavailable guarantee because of an attribute they cannot change is a metering error before it is a fairness problem.
The protection premium \(\rho(d)\) therefore sits as follows.
\(\rho(S_0)=\rho(S_1)=0\), \(\rho(S_2)=0.15\), \(\rho(S_3)=0.60\)
The zeros at S₀ and S₁ are forced by the argument above rather than chosen as policy. The S₂ and S₃ figures are midpoints of a range derived from the protection self-funding condition, namely that the premium collected at a degree must cover the expected protection outflow to that degree. The admissible bands are \(\rho(S_2)\in[0.10,0.20]\) and \(\rho(S_3)\in[0.50,0.70]\).
2.3 The Combined Degree Weight
Combining the two terms:
$$\omega(d) = \omega_{cap}(d)\cdot\bigl(1+\rho(d)\bigr) \tag{1}$$
| Degree | Capacity \(\omega_{cap}\) | Premium \(\rho\) | Product | Derived \(\omega\) |
|---|---|---|---|---|
| S₀ Static | 0.25 | 0 | 0.25 | 0.25 |
| S₁ Unidirectional Observation | 1 | 0 | 1.00 | 1 |
| S₂ Bidirectional Coupling | 3.5 | 0.15 | 4.03 | 4 |
| S₃ Atomic State Binding | 5 | 0.60 | 8.00 | 8 |
Pushing the admissible bands to their limits still gives \(\omega(S_2)\in[3.85,4.20]\) and \(\omega(S_3)\in[7.5,8.5]\), so the integers 4 and 8 fall inside. Rounding does not escape the band, so integer weights are adopted. A metering unit is safer handled with integer arithmetic in a smart contract.
A unit whose value varies by kind is not an unusual design. Language model APIs price input tokens, cached input tokens and output tokens at different rates, and the spread can exceed tenfold [8]. Snowflake defines a credit as a “unit of measure” and then doubles hourly credit consumption with each step up in warehouse size [7]. Both put per-kind weights beneath a single nominal unit, which is what degree weighting does. The difference is that our axis is the synchronization strength an asset structurally requires rather than a product grade set by the supplier.
What matters is that the weight is strictly increasing in degree. Under the reduction relation S₃ ⊇ S₂ ⊇ S₁ ⊇ S₀ a higher path can safely process a lower asset, so a break in monotonicity opens a route to a higher guarantee at a lower charge. A formal property of the hierarchy passes straight through into a constraint on the billing structure.
The admissible bands pushed to their edges before the integers 4 and 8 were adopted.
2.4 Billing on the Required Degree
The reduction relation creates one more problem. Because a higher path can safely process a lower asset, the actual processing path may sit above the asset’s required degree depending on the operating regime. So what is billed: the path actually taken, or the degree the asset requires?
Billing the actual path would let an operator inflate invoices through routing alone. Billing the required degree leaks in the opposite direction. We take the latter with one exception that plugs the leak.
Billing basis. A binding’s weight is determined by the asset’s required degree as recorded in the RWA Registry. Where operational reasons put a binding on a higher path, the difference is absorbed by the operator and not billed to the client. The exception is dynamic promotion by D-quencer consensus following regulatory action, where bindings from the moment of promotion onward are metered at the new degree.
Who bears which risk is clear under this rule. The operator carries the cost of its own routing conservatism. The client pays only what the asset structurally requires and sees no invoice movement from operational judgments beyond its control. And promotion is never retroactive. Remetering bindings that already committed would make the invoice non-final, which violates the observability condition head on.
2.5 The Fan-Out Multiplier
Degree expresses the depth of a binding, meaning how tightly two domains are tied. Bindings have a second axis as well: breadth, meaning how many domains are bound together. A cross-chain burn-and-release can be S₃ while touching four domains, and a single-chain maturity redemption can be S₃ while touching two.
Folding the two axes into one reflects neither properly. Degree weights are therefore defined at each degree’s base fan-out, and only domains beyond that are handled by a multiplier. The base fan-out is \(m_0(S_1)=1\) and \(m_0(S_2)=m_0(S_3)=2\), where \(m\) counts domains written at commit and excludes domains that are only read.
$$\text{fanout}(a) = 1+\kappa\bigl(m(a)-m_0(d(a))\bigr),\quad \kappa=0.4 \tag{2}$$
There is a reason \(\kappa\) is below one. Adding a domain does not add a proof, since one is generated for the binding as a whole, and the sequencing slot is consumed once. What scales with domain count is the locking, the finality watching, the commit propagation, and the rollback path. Design analysis puts those four at roughly forty percent of the per-domain resource bundle, which gives \(\kappa=0.4\) with an admissible band of \([0.3,0.5]\).
The lock expiry bound \(T_{lock}=\max_i(T_{finality}^{D_i})+T_{margin}\) is defined as a maximum rather than a sum, which is the second reason the coefficient stays small. More domains do not extend the wait beyond the slowest one, so the time-axis cost is already absorbed by the degree weight.
2.6 The Payload Term and the Incentive to Batch
Cycle-level metering gives clients a reason to batch. Several deltas in one cycle are metered once, so client interest and network load reduction point the same way. That is a good property, but without a bound a single cycle could carry unlimited work.
Ethereum went through this twice. In 2016 EIP-150 raised SLOAD from 50 to 200 and EXTCODESIZE from 20 to 700 on the grounds that “opcodes that read the state tree are under-priced relative to other opcodes” [5]. In 2021 EIP-2929 found the same family still underpriced, cited measurements of malicious transactions taking 20 to 80 seconds to execute, and lifted cold SLOAD to 2100 and cold account access to 2600 [6]. Where a metering unit’s weights fail to track real resource consumption, the gap always becomes an attack surface.
Hence the payload term. With \(\Delta\) as the number of state leaves a cycle updates and \(\Delta_0\) as the base payload, the metering multiplier is \(\lceil \Delta/\Delta_0\rceil\) with \(\Delta_0=8\). The basis is the median. A typical RWA binding touches something like four to eight leaves covering principal, accrued interest, holder balance and compliance flags, and the base is aligned so that the median binding is exactly one unit.
The term only fires on bulk action. A corporate action updating forty holder balances at once meters at \(\lceil 40/8\rceil=5\).
2.7 The Complete Metering Expression
One binding meters as follows.
$$u(a,k) = \omega\bigl(d(a)\bigr)\cdot\Bigl[1+\kappa\bigl(m(a,k)-m_0(d(a))\bigr)\Bigr]\cdot\Bigl\lceil \frac{\Delta_k}{\Delta_0}\Bigr\rceil \tag{3}$$
A whole session meters as the sum over every committed binding including the opening one, plus one unit for the closing record.
$$U(\text{session}) = 1+\sum_{k=0}^{n} u(a,k)+\rho_a\sum_{j\in A_c} u(a,j) \tag{4}$$
Here \(k=0\) is the initial state registration binding at session open, \(n\) is the count of subsequent bindings within the session, \(A_c\) is the set of cycles aborted through client fault, and \(\rho_a\) is the abort metering rate. That closing record is the session envelope; session open carries no separate envelope item and is metered as the first binding itself.
One check is worth running here. Feed expression (4) a single-domain S₁ asset that closes after eight state updates and it returns \(1+1\times 9=10\) SU. The ten Units of the existing Entry package come back exactly. That package was never wrong; it silently assumed degree S₁ and a domain count of one. The moment the assumption surfaces, so does the reason those numbers could not travel to any other asset.
Figure 1: Anatomy of One Metered Sync Unit
Part III. One Contract Through One Year
3.1 Three Assets
What the definition actually changes only becomes visible when a lifecycle runs through it. Three assets of different character are run for one year.
Asset A, a benchmark-tracking token (S₁, \(m=1\)). It reflects an external rate indicator weekly, giving 52 bindings a year. The observation is one-way and never written back to an off-chain ledger.
Asset B, a quarterly coupon bond (S₂, \(m=2\)). Four coupon payments, twelve monthly valuation updates, two holder eligibility reconfirmations, giving 18 bindings a year.
Asset C, a regulated security subject to regulatory action (S₃, \(m=3\)). Four quarterly distributions, twelve regulatory status checks, two maturity-related events, giving 18 bindings a year written simultaneously to two chains and one off-chain ledger.
| Asset | Degree | Domains | Bindings/yr | Fan-out | SU per binding | Annual SU |
|---|---|---|---|---|---|---|
| A benchmark-tracking token | S₁ | 1 | 52 | 1.0 | 1.0 | 54 |
| B quarterly coupon bond | S₂ | 2 | 18 | 1.0 | 4.0 | 77 |
| C regulated security | S₃ | 3 | 18 | 1.4 | 11.2 | 214 |
Counted the old way, A registers 52 and B and C register 18 each, which classifies A as the heaviest customer of the three. Counted the new way the ordering flips completely. A is lightest at 54 and C is heaviest at 214. Even between B and C, which share an identical binding count, a factor of 2.8 opens up.
3.2 The Band Inversion
This reversal is not an isolated case; it comes out of the structure. The existing frequency bands were defined by annual synchronization count: Light at 50 or fewer, Medium from 50 to 200, Heavy above 200. Those boundaries were derived in Cost Structure Analysis from inflection points on the unit cost curve.
The boundary values survive. Feeding a single-domain S₁ asset into expression (4) turns 50 annual synchronizations into 52 SU and 200 into 202 SU, so ignoring the session envelope the boundaries transfer directly to 50 and 200 SU a year. The numbers stay and the axis changes. Once the axis changes, the same asset lands in a different band.
| Degree | Light (≤50 SU/yr) | Medium (50 to 200) | Heavy (over 200 SU/yr) |
|---|---|---|---|
| S₁ | 48 bindings or fewer | 49 to 198 | 199 or more |
| S₂ | 11 or fewer | 12 to 48 | 49 or more |
| S₃ | 5 or fewer | 6 to 23 | 24 or more |
Stating the crossover makes it concrete. An S₁ asset on the Heavy boundary synchronizes 200 times a year, close to four times a week. The S₃ binding count that produces the same load solves \(8n+9\ge 202\) at \(n\ge 25\). An atomic-binding asset synchronizing once a fortnight weighs the same as an observation asset synchronizing four times a week. Under the old classification the first was Light and the second was Heavy.
Cost Structure Analysis reported node loss rates of 15 to 25 percent on heavy-frequency sessions. We have treated the source of those losses purely as a pricing problem. What surfaces now is that part of the cause sat in the classification itself. A low-frequency high-degree session classified as low load and placed in a low-rate band leaves the node assigned to it losing money regardless of the rate. When the metering axis is wrong, adjusting price alone will not close the gap.
Figure 2: Annual Metered Load of Three Assets and the Band Inversion
3.3 Parameter Sensitivity
Three parameters drive the result. Each is checked at the ends of its admissible band.
| Parameter | Adopted | Band | Result at the band edges |
|---|---|---|---|
| \(\rho(S_2)\) | 0.15 | 0.10 to 0.20 | \(\omega(S_2)=3.85\) to \(4.20\), integer 4 holds |
| \(\rho(S_3)\) | 0.60 | 0.50 to 0.70 | \(\omega(S_3)=7.5\) to \(8.5\), integer 8 holds |
| \(\kappa\) | 0.4 | 0.3 to 0.5 | Asset C lands between 199 and 229 SU, stays Heavy |
The band inversion holds as long as \(\omega(S_3)/\omega(S_1)\ge 4\), so the conclusion does not flip anywhere in the range. Removing the inversion would require S₃ processing load to sit below four times S₁, which amounts to treating enforced mutual rollback and preemptive locking as nearly free.
3.4 The Revenue Neutrality Condition
Changing the unit raises the SU figure for the same work. That must not by itself mean charging more. Redefinition should be revenue neutral on its own, and any price change should be a separate, explicit decision.
With \(\pi_d\) as the degree mix of bindings, the mean weight is \(\bar\omega=\sum_d \pi_d\,\omega(d)\), and the neutrality condition requires the new rate \(p_{SU}\) to satisfy \(p_{SU}=p_{sync}/\bar\omega\) against the old per-synchronization rate.
\(\bar\omega\) moves a great deal with asset mix. Between an observation-heavy portfolio and a regulation-heavy one the mean weight nearly doubles, so the actual rate has to be set after mix data accumulates, and that belongs to follow-up research. What is established here is the condition itself. Redefining a unit must not move the total invoice.
The condition applies to every constant computed under the old conversion. Usage caps, burn thresholds, and usage variance estimates denominated in the previous unit all need to be reset in the new one.
Part IV. When and How the Meter Debits
4.1 Commit-Time Debit and Abort Attribution
Metering happens only at Commit, for two reasons. Charging at Bind creates an attack surface, because a counterparty domain repeatedly inducing failure would inflate the client’s invoice through its own behaviour, violating the manipulation condition. And the node reward layer already counts completed BVC cycles, so the two ledgers only reconcile if they count the same event.
Aborted cycles still consume resources, and an abort in Full BVC runs the mutual rollback path. Leaving all of them free opens a low-cost denial of service through repeated submission of invalid state transitions. Attribution splits them.
| Cause of abort | Metering | Cost borne by |
|---|---|---|
| Client fault (invalid state transition, compliance validation failure) | partial, \(\rho_a\) times | client |
| Counterparty domain fault (external ledger rejection, reorganization) | 0 | operator, insurance pool |
| Network fault (node failure, consensus delay) | 0 | operator, insurance pool |
Structure decides where \(\rho_a\) can sit. The floor is real consumption: in the latency decomposition by degree, Bind and Verify take roughly a third of the cycle and rollback execution adds to that, so anything lower subsidizes the abort path. The ceiling is one. Once abort metering equals commit metering, the network earns as much from failure as from success, and from that point the meter runs the incentive backwards. The principle is to stay conservative between those two bounds.
4.2 Aligning the Time Lattices
Three time units bear on metering: event time when a binding commits, the accounting period in which metered values are aggregated and recorded, and the billing period on which a client settles. If those three do not align, the attribution of cycles straddling a boundary becomes ambiguous.
The node reward layer uses the Epoch as its accounting unit with a seven-Epoch smoothing window. The client side uses the month-start prepayment and month-end unused credit settlement fixed in Token Flow Mechanics in State Subscription Economy. For the two lattices to align, the billing period must be an integer multiple of the Epoch, so that the metered values in one invoice decompose into an unambiguous number of Epoch records.
Adopting a daily Epoch makes a calendar month 28 to 31 Epochs, satisfying the condition automatically, and a seven-Epoch smoothing window still maps onto a week. Keeping a weekly Epoch makes a calendar month roughly 4.35 Epochs and breaks the condition, forcing the billing period to be redefined as four Epochs of 28 days, at which point the annual billing count moves from twelve to thirteen. The alignment condition effectively selects the daily Epoch.
The usual objection to daily accounting is gas cost, since a distribution transaction every day accumulates expense. That objection only holds if the accounting unit and the payout period are treated as the same thing. Node rewards are claimed on a pull model at a time of the node’s choosing, and the smoothing window remains seven Epochs. Keeping metering records at daily resolution is a different matter from moving tokens daily.
4.3 Metering Across the Three Tiers
The three tiers share one oracle usage metering pipeline and differ only in settlement.
Pay-per-sync. Expression (3) debits at commit and the four-way distribution executes on the spot. No lag separates metering from settlement.
Prepaid credit. The commit debits the credit balance, and unused amounts are confirmed at period end. The existing policy of converting a share of unused credit to the insurance pool and rolling the rest forward stands unchanged. Since the debit now reflects degree weight, the same credit supports a different number of synchronizations depending on asset mix. Displaying a balance as “synchronizations remaining” has to become “SU remaining”.
Flat subscription. The commit increments a cumulative SU counter checked against the cap, and the congestion burn on amounts above the cap stays in place. The cap’s meaning changes. The same number previously meant a count of synchronizations and now means SU, so a high-degree cross-chain portfolio reaches it far earlier. The bound now bites first on the usage patterns that genuinely cost the most, and recalibrating the threshold has to happen alongside rate setting.
4.4 A Bill Anyone Can Recompute
The root problem in cloud billing was that customers could not verify their own consumption [2]. The meter lives inside the provider and the customer receives only the result, which is why verifiable resource accounting became a research topic in the first place [3].
A state oracle sits in a structurally better position on this, and it is where oracle usage metering diverges from the cloud case. The meter is consensus state. When a binding commits, OSS emits a synchronization completion event and D-quencer consensus records it at the Epoch boundary. Making the bill recomputable requires only that the metering inputs travel in that record. If the Epoch record carries, per session, the list of committed cycles along with each cycle’s \((d,m,\lceil\Delta/\Delta_0\rceil)\), the charge becomes a deterministic function of public state.
$$\text{Bill}(\text{session}) = f\bigl(\text{public event log},\ \text{meterVersion}\bigr) \tag{5}$$
A client can recompute its own invoice independently, and a mismatch becomes a bug instead of a dispute. Metering moves from something to be trusted to something to be checked.
Part V. Governing the Weights
5.1 Repricing Will Come
Getting weights right on the first attempt is not possible. Ethereum’s two gas repricings show as much. EIP-150 raised the cost of state-tree reading opcodes in 2016 only after denial of service attacks demonstrated the underpricing [5], and five years later EIP-2929 confirmed by measurement that the same family was still underpriced and raised it again by close to threefold [6]. Both were hard forks.
The same will happen to us. \(\omega\), \(\kappa\), \(\Delta_0\) and \(\rho_a\) are derived from design analysis and will be adjusted as measurement accumulates. The problem is allowing adjustment while keeping invoices final.
5.2 meterVersion and Session Pinning
One decisive difference separates gas from our meter. An Ethereum transaction ends inside one block, whereas an Oracle Session lives for years alongside the asset. The session of a ten-year bond will meet several weight revisions along the way, and an institutional issuer cannot forecast contract cost if the economics of a live session shift underneath it.
Three layers handle this.
Version pinning. The meterVersion current at session open is recorded in session metadata, and every binding in that session meters at the pinned version.
Repinning events. A transfer of ownership closes one session and starts another by definition, so it repins to the latest version naturally. Degree promotion by regulatory action is also a repinning event, applied from the promotion onward. Pinning carries a maximum term, after which repinning occurs with advance notice.
Bounded change and no retroactivity. Weight movement within a governance period is capped, and changes are announced at least one billing period ahead. Retroactive application never occurs. A binding that has committed keeps the metered value of the version in force at that moment, permanently.
Figure 3: Metering Timeline from Commit to Verifiable Bill
Part VI. Open Questions
This research closed what it could close as a single source of truth. The remaining items sit outside its scope and pass to follow-up work.
Recalibrating the rate and the tier prices. The revenue neutrality condition is set, but the actual SU rate, the three tier prices, the appropriate level of the usage cap and the congestion burn threshold lie outside this study. Research on pricing calibration takes them up.
Measuring the degree mix. The customer distribution figures were estimated on the synchronization count axis. They have to be re-estimated on the SU axis, and that result determines the mean weight and the revenue-neutral rate.
Aligning the node reward layer with the meter. A node’s throughput score currently counts completed cycles as they come. Now that client-side metering carries weight, two ledgers count the same cycle at different weights. A node that processed eight times the work receives the same score as one that processed a single unit, and follow-up research on reward structure has to take this up alongside the rest.
Calibrating the weights against measurement. The capacity term is relative load derived from design analysis. Once testnet measurement accumulates it becomes the subject of the first meterVersion revision.
Accounting for mid-life degree promotion. The principle that a promoted asset meters at the new weight only from the promotion onward is established, but the handling of a cycle in flight at that moment, and the revaluation of a prepaid credit balance, need further work.
Conclusion
Across five studies the State Subscription economy designed cost, price, distribution, circulation and insurance while leaving one metering unit undefined. The gap was quiet but not harmless. Three different conversion rates coexisted in one body of work, and low-frequency high-degree assets were classified as low load, becoming one source of node losses.
What this research did was tie the unit back to an invariant of the system. One Sync Unit is the commit of a single-domain observation binding, and every other binding is a multiple of it. The multiples were not set by preference. They decompose into a capacity term for processing load and a guarantee term for the obligation the network carries, and both terms were drawn from the already-settled degree hierarchy and session protection priority. Looking for structure the system already has beats inventing a new rule, every time.
Once the definition changed, the ten Units of the old package came back as a special case, and with them the reason those numbers could never be transplanted onto another asset. The frequency boundaries of 50 and 200 survived while the axis moved from count to SU, and that move alone made visible a fact that had been hidden: an atomic-binding asset synchronizing once a fortnight is heavier than an observation asset synchronizing four times a week.
Some questions can only be asked once the unit exists. What is one SU fairly worth? Where should tier boundaries move when the degree mix shifts? And why does a node that did eight times the work receive a single unit of score? Oracle usage metering starts with the meter, not the price. The scale has to stand before there is any point discussing what goes on it.
References
[1]. National Institute of Standards and Technology. (2019). Kilogram: Introduction. https://www.nist.gov/si-redefinition/kilogram-introduction
[2]. Jellinek, R., Zhai, Y., Ristenpart, T., & Swift, M. (2014). A Day Late and a Dollar Short: The Case for Research on Cloud Billing Systems. USENIX HotCloud ’14. https://www.usenix.org/conference/hotcloud14/workshop-program/presentation/jellinek
[3]. Sekar, V., & Maniatis, P. (2011). Verifiable Resource Accounting for Cloud Computing Services. Proceedings of the 3rd ACM Workshop on Cloud Computing Security (CCSW ’11). https://dl.acm.org/doi/10.1145/2046660.2046666
[4]. Chainlink. (2025). Chainlink Functions Billing. Chainlink Documentation. https://docs.chain.link/chainlink-functions/resources/billing
[5]. Buterin, V. (2016). EIP-150: Gas cost changes for IO-heavy operations. Ethereum Improvement Proposals. https://eips.ethereum.org/EIPS/eip-150
[6]. Buterin, V., & Swende, M. (2020). EIP-2929: Gas cost increases for state access opcodes. Ethereum Improvement Proposals. https://eips.ethereum.org/EIPS/eip-2929
[7]. Snowflake. (2025). Understanding compute cost. Snowflake Documentation. https://docs.snowflake.com/en/user-guide/cost-understanding-compute
[8]. OpenAI. (2026). API Pricing. OpenAI Platform Documentation. https://developers.openai.com/api/docs/pricing
