# \[RFC\] Request For Comments: The OPEN Rules Upgrade v1.2 **URL:** \ **Category:** OPEN Stablecoin DTF\ **Created:** [January 28, 2026, 10:10pm UTC](https://forum.reserve.org/t/rfc-request-for-comments-the-open-rules-upgrade-v1-2/1428 "2026-01-28T22:10:45Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![0xJMG](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.reserve.org/0xjmg/32/1104_2.png) [@0xJMG](https://forum.reserve.org/u/0xJMG)\ **Post date:** [January 28, 2026, 10:10pm UTC](https://forum.reserve.org/t/rfc-request-for-comments-the-open-rules-upgrade-v1-2/1428/1 "2026-01-28T22:10:45Z")
## RFC Summary - OPEN v1.1 indexes top-10 Universe projects, but exposes diversification, weighting, and clipping risks. - Proposed fixes include tighter caps, better efficiency metrics than TVL, and alternatives to zero-clipping. - RFC v1.2 invites community input on caps, metrics, growth measurement, and clipping tradeoffs. ## How v1.1 Works 1. OPEN Universe: Anyone can propose additions to the OPEN Universe whitelist. Candidate projects move to OPEN Universe after vlSQUILL Snapshot approval ([see process here](https://forum.reserve.org/t/rfc-the-open-universe-rules-upgrade-v1-1/1356#:~:text=3a.%20OPEN%20Universe,iteration%20and%20automation.)). 2. OPEN Rules: Top 10 Universe whitelist projects are indexed following OPEN Rules (v1.1 methodology detailed in Table 1 below) Projects are tracked on [v3 Metrics: $OPEN Universe: by glyph](https://docs.google.com/spreadsheets/d/1MMZSiyIoUggJYZiRYV0U_KS-at4UE-Kt8Y9JVut_bfY/edit?gid=0#gid=0) **Table 1: OPEN Index v1.1 Rules** | Rule | v1.1 Method | Data Source | | --- | --- | --- | | OPEN Universe whitelist inclusion | Universe whitelist application → RFC → vlSQUILL Snapshot approval | Manual calculation | | Number of constituents | Up to 10 from OPEN Universe whitelist, ranked by index weights | n/a | | Rebalancing cadence | Quarterly, calendar year | n/a | | Index Weight 1 | 20% — Liquidity efficiency = constituent liquidity / OPEN market cap | DeFiLlama DEX liquidity; CoinGecko market cap | | Index Weight 2 | 60% — Value efficiency = constituent TVL / FDV | DeFiLlama TVL; CoinGecko FDV | | Index Weight 3 | 20% — Growth velocity = YoY TVL growth | DeFiLlama TVL | | Zero/negative value clipping | Negative values clipped to zero; positives only weighted | Manual calculation | | Component weight bands | ≤40% max, ≥1% min at quarterly rebalance; interim resets via governance | Manual calculation | | Onchain rebalance approval | vlSQUILL approved | Onchain / Reserve app | ## v1.1 Problem - Diversification risk: permits a single constituent to reach 40% of index weight. Consider the rationale and tradeoffs of cap at 35%, 30% or 25%. - Weighting risk: TVL varies too much by protocol mechanics; revenue and P/S proposed as more impactful inputs. - Clipping risk: Zero/negative value clipping loses signal; consider deviation from median or worst-performer to preserve full spread or z-score mapping to preserve underperformance without discarding data. Problems and suggestions are further unpacked in [OPEN Rules v1.2, request for comments Jan 2026](https://docs.google.com/spreadsheets/d/1sdJuuENyVRQf7HIXoFUq9x352klT7B2m6t_rZR0PG-E/edit?gid=0#gid=0). If you’d like to add your input via a column to the document, just request access in the google sheet. ## Call to action This RFC invites your input in the comments on four questions: 1. Diversification risk: What maximum and minimum constituent weights do you recommend, and what are the tradeoffs? Please cite supporting evidence where available. 2. Weighting risk: For the Value Efficiency weight, how should the numerator and denominator be changed using a standardized, publicly available metric from DeFiLlama without customization? Please provide supporting arguments. 3. Weighting risk: For the Growth Velocity weight, how should the numerator and denominator be changed using a standardized, publicly available metric from DeFiLlama without customization? Please provide supporting arguments. 4. Clipping risk: should this approach change, and if so, what alternative is recommended and why? Please include tradeoffs and supporting rationale. ## Helpful links - [Mint OPEN](https://app.reserve.org/ethereum/index-dtf/0x323c03c48660fe31186fa82c289b0766d331ce21/overview) - [OPEN constituents dashboard](https://docs.google.com/spreadsheets/d/1MMZSiyIoUggJYZiRYV0U_KS-at4UE-Kt8Y9JVut_bfY/edit?gid=0#gid=0) - [Follow OPEN on 𝕏](https://x.com/OpenStableIndex) - [Secret Admirers Telegram chat](https://t.me/+fIODVyG8z5A1ZTNh) - [Discuss / RFC on Forums](https://forum.reserve.org/c/open-dtf/67) - [Track OPEN on CoinGecko](https://www.coingecko.com/en/coins/open-stablecoin-index) - [OPEN-WETH on Curve](https://www.curve.finance/dex/ethereum/pools/factory-twocrypto-178/deposit/) - [OPEN-WETH on Uniswap](https://app.uniswap.org/explore/pools/ethereum/0xaBaebcc9EEe363CeA2150eE03ac96db110F0e745) - [Vote-lock SQUILL and govern OPEN](https://app.reserve.org/ethereum/index-dtf/0x323c03c48660fe31186fa82c289b0766d331ce21/governance) - [Propose projects for Universe whitelist](https://docs.google.com/forms/d/e/1FAIpQLScK3NAR6drnqqmOuaoHejIj-hMcqaAQ6lFFG_FnM70C4y_WRw/viewform) ---
**Author:** ![Frogenomics](https://avatars.discourse-cdn.com/v4/letter/f/f04885/32.png) [@Frogenomics](https://forum.reserve.org/u/Frogenomics)\ **Post date:** [February 4, 2026, 10:08pm UTC](https://forum.reserve.org/t/rfc-request-for-comments-the-open-rules-upgrade-v1-2/1428/2 "2026-02-04T22:08:58Z")
# Response to $OPEN Index Methodology RFC GM, I’m honored to respond to this call to action. ## Market Volatility & Rebalancing Capacity In times of volatility and capital expansion, the asset values within the OPEN index will be unpredictable and difficult to rebalance reasonably. To address this, I propose adding **stability anchors** to the index composition. ### Proposed Stability Anchors (10-30% combined allocation): - **sCRVUSD** (Curve’s savings stablecoin) - **cbBTC** (Coinbase wrapped Bitcoin) - **frxETH** (Frax staked ETH) - **xAUT (** Tether Gold) **Purpose:** These assets would absorb unreasonable rebalancing volatility, providing liquidity buffers during extreme market conditions while maintaining yield generation for the index. **Combined weight:** 10-30% of total index position ### Governance Token Constituents (70-90% allocation): **Individual weight range: 3-19% per constituent** This structure maintains the ability to: - Push dominant positions toward quality protocols (up to 19%) - Capture assets with speculative growth opportunity (minimum 3% threshold) - Preserve diversification across 8-12 governance tokens * * * ## Value Efficiency & Growth Weighting Methodology I support using **Fees / Market Cap** as the primary value efficiency metric: **Formula:** ```auto Value Efficiency Score = (Fees 30d × 12) / Governance Token Market Cap ``` **Why Fees over Revenue:** For stablecoin protocols specifically, fees represent total economic activity while revenue reflects only what’s retained post-distribution. Since we’re indexing governance tokens that _represent_ the protocol’s economic engine, fees are the superior measure. **What this captures:** - **Protocol usage intensity** — high fees indicate high activity - **Token valuation efficiency** — low market cap relative to fees suggests undervaluation - **Long-term sustainability** — fee generation is essential for protocol longevity **Example:** - Protocol A: $50M annual fees, $500M market cap → **10% efficiency score** - Protocol B: $10M annual fees, $200M market cap → **5% efficiency score** - **Result:** Protocol A receives 2× the weight from this factor * * * ## Clipping Position **DeFi moves fast. The protocol deserves the right to clip without boundaries.** Traditional index methodologies impose gradual rebalancing caps to minimize market impact. However, in a market characterized by: - Rapid governance token volatility - Protocol exploits and de-pegging events - Shifting regulatory landscapes - Fast-moving capital flows …restrictive clipping policies create more risk than they mitigate. **I support uncapped clipping authority** for quarterly rebalances, with transparent methodology execution and governance oversight. ---
**Author:** ![0xJMG](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.reserve.org/0xjmg/32/1104_2.png) [@0xJMG](https://forum.reserve.org/u/0xJMG)\ **Post date:** [February 16, 2026, 6:35pm UTC](https://forum.reserve.org/t/rfc-request-for-comments-the-open-rules-upgrade-v1-2/1428/3 "2026-02-16T18:35:15Z")
Hey Frogenomics, Thank you for your post, which quickly reminded me, I should have included OPEN’s current mandate (and methodology) in the intro. Here it is: _ **The Open Stablecoin Networks Index is a value-weighted DTF that tracks DeFi’s ten strongest open stablecoin networks in one $OPEN token. Eligible projects are first whitelisted by vSQUILL-OPEN governance, which reviews asset backing, peg design, mint and redeem rules, safety mechanisms, revenue sharing, and decentralized control.** _ _ **Whitelisted projects are then ranked and weighted, with only the top ten included. Weights use a composite score: 60% on TVL relative to FDV, comparing supplied value to market valuation, 20% on year-over-year TVL growth, and 20% on liquidity efficiency. Quarterly rebalances cap holdings at 40% and set a 1% minimum to help reduce concentration risk and smooth large swings.** _\* Your ideas for stability anchors is interesting but would make more sense in an index where people want stability, rather than an index that tracks DeFi stablecoin networks growth. Appreciate your comment on Fees / Mkt Cap VS Revenue / Mkt Cap for value efficiency & growth weighting. But wouldn’t large fees and low revenue compared to other protocols indicate a less desirable project to own? i.e. less value to accrue to network owners. One concern we are considering is how to make OPEN maximally programmatic in a way that can run on autopilot with no custom calculations. This is hinting toward using DefiLlama’s P/S ratios (Revenue / Mkt Cap) out of the box. Here is Defillama’s P/S leaderboard. [https://defillama.com/ps](https://defillama.com/ps) Potentially what this (v1.2) might lead too if approved by vlSQUILL governance: - \_\_%. Liquidity efficiency = constituent liquidity / OPEN market cap - \_\_%. Value efficiency = P/S (Mkt cap / Revenue) - \_\_%. Growth Velocity = YoY Revenue Growth From Current v1.1: - 20%. Liquidity efficiency = constituent liquidity / OPEN market cap - 60%. Value efficiency = constituent TVL / FDV - 20%. Growth Velocity = YoY TVL Growth Welcome your thoughts and hope others will weigh in. ---
**Author:** ![0xJMG](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.reserve.org/0xjmg/32/1104_2.png) [@0xJMG](https://forum.reserve.org/u/0xJMG)\ **Post date:** [September 19, 2026, 11:57pm UTC](https://forum.reserve.org/t/rfc-request-for-comments-the-open-rules-upgrade-v1-2/1428/4 "2026-09-19T23:57:50Z")
**This RFC is CLOSED.** Discussion has moved to the following link: > [@Help peer review OPEN v1.2 methodology options](https://forum.reserve.org/t/help-peer-review-open-v1-2-methodology-options/1653): > > 1. Introduction OPEN needs a healthy inspiring chart backed by a methodology that the community can understand, reproduce, challenge, and maintain. You can review current OPEN v1.1 parameters and history here: You are invited to peer review eight backtested methodologies for OPEN. Nothing in this post is financial advice. Please critique the eligibility rules, variables, data sources, formulas, portfolio construction, assumptions, and conclusions. Criticism is most useful when paired with …