# Moneta controller and observer review — 7 September 2026 Status: research and implementation review, not an approved monetary-policy upgrade or security audit. The desktop design change does not activate these proposals. ## Main conclusion More aggressive feedback is not the priority. The highest-value improvements are independently obtained market observations, explicit limits over time, and a defensible miner security budget. No controller can infer a reliable tMON market price when no authenticated liquid market exists. Missing observations should continue to disable stability bonuses. The implementation inspected is `observer_runtime.py`, `moneta_core/observation_io.py`, `moneta_core/reservoir.py`, `moneta_core/constants.py`, and the reservoir/runtime regression tests. `moneta_core/observer.py` also contains an older research model; its five-source basket must not be confused with the operational runtime, which currently obtains a BLS CPI reference and an optional operator-configured market document. ## 1. Agreement is not authenticity `validate_market_feed` requires 3–8 different venue labels, bounded integer prices, freshness, reported volume and depth, and limited dispersion. Those checks reject malformed/stale/outlying documents. They do not prove that any named venue exists, has that order book, trades the correct token, or is independent of the other venues. One publisher can fabricate three mutually consistent rows. Work-weighted aggregation does not fix correlated dependence on one publisher. BIS describes the unavoidable trust/efficiency tradeoff in bringing off-chain facts into consensus. Chainlink separately distinguishes inaccurate oracle reporting from manipulation of the underlying market itself. Even authentic signatures cannot establish that a thin market has an economically meaningful price. [BIS](https://www.bis.org/publ/bisbull76.htm), [Chainlink](https://chain.link/education-hub/market-manipulation-vs-oracle-exploits). Recommended next design: independently fetch identified instruments from multiple independent venue operators. Pin instrument identity, quote units, timestamp meaning, parser version and transport constraints. Keep original response hashes and acquisition times for diagnosis. Cap each correlated operator's weight; venue count alone is not diversity. Use executable depth near the price and conservatively filtered trades, not self-reported volume alone. Do not silently introduce an administrator-controlled feed allowlist as if it were permissionless consensus. The trust model and upgrade process must be explicit. Release gate: adversarial fixtures for duplicate operators, invented labels, wrong instruments, decimal/unit errors, replay, crossed books, stale data, future timestamps, 51% correlated work, and a validly signed but manipulated price. The existing tests cover only part of this boundary. ## 2. Bound the accumulated effect, not only one epoch The v2 candidate allows at most 100 ppm (0.01%) of circulating supply as additional release per 144-block epoch, before pressure, per-block bounds and available reserve. Seven qualifying NORMAL epochs delay activation. This is a block-count cadence, not a fixed number of hours. For a deliberately simplified ceiling illustration, with all other limits ignored and every epoch releasing its ceiling: `S(n) <= S(0) * (1 + 0.0001)^n` This is NOT a bound on total supply including base subsidies and NOT a forecast of the implemented controller. It isolates compounding of the bonus ceiling. At 1,000 epochs the multiplier is about 1.1052; at 10,000 it is about 2.7181. A small per-epoch cap is not a small lifetime allocation. Reserve exhaustion can bind earlier. Recommended next design: a separate rolling/cumulative bonus budget, accounted from validated history; activation and reorg rules must be deterministic. A wall-clock budget cannot blindly trust local time or miner-provided timestamps. Compare a fixed block-window budget with a carefully specified chain-time budget under accelerated mining and timestamp manipulation. Do not call 144 blocks a day without a proven difficulty/cadence relationship. ## 3. Recovery delay has a real cost The candidate's symmetric error `e = 2(P - T)/(P + T)` is bounded between -2 and 2 for positive prices and treats reciprocal price ratios symmetrically. For P/T = 2, e = 2/3; for P/T = 1/2, e = -2/3. This is a useful bounded signal, not proof of stability. A linearized illustrative model `e(t+1) = (1 - a*k)e(t)` is stable only when `0 < a*k < 2`, where `a` is the unknown market response to issuance and `k` the feedback gain. Delay, changing liquidity and speculative demand invalidate reliance on that simple condition. Moneta has no measured market response from which to calibrate `a`. Maker's original Oracle Security Module deliberately delayed prices so emergency action could intervene; copying the delay without the intervention mechanism would not provide the same protection. A delay also increases stale-price exposure. [Maker protocol whitepaper](https://makerdao.com/whitepaper/White%20Paper%20-The%20Maker%20Protocol_%20MakerDAO%E2%80%99s%20Multi-Collateral%20Dai%20%28MCD%29%20System-FINAL-%20021720.pdf). Recommended next design: keep fast failure to SAFE and deliberately slower recovery; simulate transient spikes, persistent false prices, oscillation near the deadband, demand collapse and reorgs. Use sensitivity sweeps rather than one favorable trajectory. Preserve the existing immediate cancellation of a stale positive bonus after a crash. Do not claim that spending a reservoir mechanically restores market purchasing power. ## 4. Preserve a security budget Current v2 allocation caps reserve-funded subsidies and bonuses at remaining inventory; once empty, miners rely on fees. Fee burning can also reduce miner revenue. Supply scarcity and consensus security are different goals. For R units of reserve and a constant net subsidy b per block, the simplest runway estimate is `R/b` blocks, assuming b>0, no bonuses and no other reserve movements. The operational calculation must use net fees, burn and bonus policy, not this simplified estimate alone. Recommended next design: publish a reserve-runway diagnostic with explicit assumptions, stress-test near-zero fee demand, and compare lower fee burns, a protected subsidy reserve, or explicitly governed tail issuance. Each changes incentives or supply guarantees; none is an unconditional improvement. Evaluate independently before adopting a consensus change. ## 5. Reference index and privacy The operational reference is US CPI normalized to a fixed baseline. US consumer inflation is not a universal global cost-of-living index, an Indian household basket, or an exchange rate. BLS explains that CPI measures price changes for a defined consumer basket and is an approximation rather than a complete cost-of-living measure. [BLS CPI FAQ](https://www.bls.gov/cpi/questions-and-answers.htm). Recommended next design: document basket, geography, release lag, revisions and units precisely. Do not average several indexes merely to appear diversified; normalize and assess correlated components first. Fresh fetching does not make an old observation period current. ## 6. Concrete code risks and release blockers - Fixed in this candidate: market HTTPS fetching previously validated DNS and then resolved again through urllib. The connection now uses the vetted numeric socket addresses and verifies TLS against the original hostname. New regressions cover no second DNS resolution, rejection of mixed public/private DNS answers, and rejecting redirects. This narrows one transport weakness; it does not establish feed authenticity or complete the broader SSRF audit. - New client helper specs and Electron resource entries are being prepared, but complete Tor bundles and installed-GUI verification are still required. A successful source test is not an installed-app test. - Native Windows CLI onion support remains unfinished. Do not advertise it as completed through a GUI style update. - Candidate v2 has a timestamp-based activation scheduled for September 19 in the source. Rollout and compatibility review must be finalized before distributing it as a production-ready node. - Migrated the default GitHub registry/upgrade URLs in all four codebases to the Sites registry and download page. The original Tailscale seed remains an untrusted hint; live reachability and a first production onion seed are still unverified. - Full-repository security review is still incomplete; existing static scanners and tests cannot prove that malicious peers or compromised devices cannot harm users. ## Priorities 1. Finish distribution, reachable bootstrap and installed Tor interoperability. 2. Fix demonstrated input/transport weaknesses and test recovery under malicious peers. 3. Authenticate and independently acquire economically meaningful observations. 4. Evaluate time/cumulative budgets and reserve-runway tradeoffs with reproducible stress scenarios. 5. Only then calibrate any economic response and approve a compatible protocol rollout.