memoscan

0xcb16…f85c

All memos sent from and to 0xcb16…f85c.
0xfc9b404b…99ffsent to0xcb162218…f85c·#23,748,602·0x60a44a95…affde4
Whilst justification of the reduced rewards has not been forthcoming...strangely not many responses to requests for info....there does seem to be consensus so I am all in hopefully future proposals will actually have more info provided to justify!
0x986efbf4…92bcsent to0xcb162218…f85c·#23,747,993·0x3d466bfc…631109
Despite Obol DV growth not being as great as sometimes presented (see https://community.obol.org/t/oip-7-staking-rewards-extension-transition-toward-programmatic-protocol-revenue-sharing/719/26), I’ll still vote in favor of this proposal (>30% APY is not realistic/sustainable long-term anyway). I see it as a sensible step towards mature and sustainable tokenomics.
0x17296956…b879sent to0xcb162218…f85c·#23,740,055·0xf7d3b8a5…4b4df8
# OIP#7 Staking Rewards Extension & Transition Toward Programmatic Revenue Sharing # **Summary** This proposal seeks community approval to **launch a new staking rewards phase**, following the conclusion of the first one ([OIP-1](https://community.obol.org/t/oip-1-building-and-enabling-staking-for-the-obol-token/312/1)). The updated schedule introduces **two months of streamed rewards (until mid-January 2026)** at a rate of **137,500 OBOL per month**. The purpose of this second phase is to **ensure continuity** while preparing to transition from pre-allocated rewards to a programmatic **revenue-sharing model for the OBOL token**. As Obol’s network and Total Value Staked (TVS) continue to grow rapidly, this next phase will align stOBOL yield with **real network activity and value creation. Stakers will get direct exposure to the fees generated by the protocol.** # **Context** Since Q2, **total value secured by Distributed Validators using Obol has grown from ~1.2 B USD to more than 3.2 B USD**, marking a major step forward for the protocol. More info on the state of our Ecosystem in our recent [Ecosystem Report.](https://blog.obol.org/obol-q3-ecosystem-report/) As this growth compounds, we believe it’s time to begin **reinjecting a portion of this economic activity back into the OBOL token economy**. The current staking rewards bucket, approved under **OIP-1**, will end on **November 16, 2025**. Without renewal, staking rewards would stop streaming, interrupting stOBOL yield and breaking the continuity of the staking program just as the network enters its next stage of adoption. We believe the continuity is important to keep the amount of OBOL staked increasing and allowing programmatic revenue sharing with the maximum number of ecosystem members. # **Proposal** We are proposing to: * **Introduce a new phase of staking rewards** for two months (Nov 16 → Jan 17 approx.) * Stream rewards at a rate of **137,500 OBOL per month (half the OIP#1 rate)** * Use this period as a **bridge** toward the introduction of programmatic **revenue-sharing mechanisms** for stOBOL holders ***This second phase ensures staking remains active and uninterrupted while Obol finalize the design of sustainable, yield-backed accrual systems.*** ## **Transition to Programmatic Revenue Accrual** Obol is preparing to evolve from **pre-allocated reward distributions** to **revenue-driven token economics**, where staking yield reflects **protocol usage and validator activity** rather than scheduled reward streams. This transition begins now. The staking program acts as a bridge toward future revenue-sharing mechanisms that will align stOBOL returns with real network performance. We plan to present detailed revenue-sharing models for feedback **in the next few months**, ensuring technical soundness, and alignment with the upcoming regulation changes in the US. ***In this model, staking OBOL represents securing yield from real Ethereum validation revenue.*** ## **Why Now** * **Network maturity:** Obol’s validator ecosystem is scaling fast; maintaining staking continuity sustains confidence in the token’s role and amount of staked OBOL. * **Pendle integration:** The recent launch of the stOBOL market on Pendle has introduced on-chain yield composability. Maintaining staking rewards during this early phase supports market stability and liquidity. * **Narrative alignment:** The broader market is rewarding protocols that connect token yield to real network activity; this proposal positions OBOL on that trajectory responsibly. ***This proposal is also an opportunity to signal Obol’s intent to move toward sustainable, value-accruing token mechanics. As we finalize the technical and legal parameters for programmatic revenue sharing, this next phase keeps incentives aligned with network growth and the collective’s long-term vision.*** ## **Implementation & Authority** If approved: * Rewards continue automatically at the new rate from **November 16**. * The **Obol Association** may, if necessary, **extend the same stream for up to six months total** if revenue-sharing mechanisms are not yet live. * Any such extension will be transparently communicated to the Collective in advance. ## **Next Steps & Timeline** * **Discussion:** Oct 23 → Oct 30 * Adjustments based on feedback: Nov 1 → Nov 5 * **Target vote date:** Nov 6 (on-chain via Tally) * **New reward stream start:** Nov 16
0xf5e19192…fd8dsent to0xcb162218…f85c·#22,883,318·0x8f13d9f9…b7911b
# Shutdown of the Obol Association. ## Abstract This proposal instructs the Obol Association to **liquidate 20 million un-claimed OBOL tokens** (≈ 4 % of total supply) on the open market at the prevailing spot price and to use the realised proceeds to pay all costs associated with **shutting down the Obol Token House and related governance infrastructure**. The validator-technology stack (“Obol DVs”) and the core engineering team would continue operating on a fee-for-service model, funded by commissions from node operators, without a native token incentive layer. ## Motivation **Governance fatigue / unmet expectations** Obol Association has seen low turnout and slow delivery on key road-map items. Winding down releases contributors from procedural overhead and makes expectations clear. **Investor dissatisfaction** OBOL trades ≈ 80 % below its May-2025 ATH; sentiment is negative. **Operational cost overhang** Running delegation UI, analytics, security audits, delegate stipends, etc. **Viable fee model exists** Obol DVs can charge operators per-validator fees. Technology and team survive without token economics. ## Specifications ### 1. Token tranche to be sold * **Amount:** 20,000,000 OBOL (un-claimed airdrop allocation currently held by Association Treasury). * **Transfer status:** Already ERC-20 transferable—no contract changes required. ### 2. Sale mechanism * **TWAP Market-Order Programme*** Execute **time-weighted-average-price (TWAP)** orders of ≤ 1 % of average daily volume every 15 minutes across CEXs and DEXs for **30 consecutive trading days**. * Use an external market-maker to minimise slippage; target effective sale price within **-5 %** of prevailing index. <!----> * **Fallback OTC Block*** If 50 % of the tranche remains after 30 days, authorise OTC blocks with pre-funded counterparties at ≤ 2 % discount to seven-day VWAP. * **Reporting*** Publish daily fills (tx-hashes / trade‐IDs) to a public Dune or Google-sheet dashboard. ### **3.Use-of-funds (wind-down budget)** Legal & compliance 350k Dissolve Association entities, tax filings Security & data retention 120k 12-month archive of infra / audits Contributor off-boarding 280k Final payroll, severance, invoice settlement User communication & PR 80k Press releases, help-desk, site banners Market-maker & execution 130k Per §2 ## Conclusion Selling the dormant airdrop allocation provides a clear, transparent funding source to **close the Obol Association responsibly**, honour outstanding obligations, and let the Obol DV technology stand on its own commercial merits. Delegates are invited to review the plan, suggest amendments, and—if in agreement—vote **YES** to authorise the wind-down.
0x5e0936b2…c634sent to0xcb162218…f85c·#22,873,602·0x1368a94f…869cbe
Voting yes mainly to signal and support the call for establishing better guidelines and rules for communications to the community. If the intent of the Airdrop was to distribute tokens and reward users, then an extension aligns with that mission. This proposal presented a clear plan to accomplish a specific purpose (and well integrated the feedback from the Collective during the RFC phase). I will also argue that the airdrop was a campaign initiated and operated prior to the Collective's 'launch', and investing more efforts in previous campaigns is a sunk-cost fallacy. Outside of campaign visibility, an extension to claim doesn't move the needle in making the Collective more dynamic, or efficient. The Collective must make good on it's obligations. But ultimately establishing new, long-term, and sustainable ways to reward the community should be the focus.
0x5e0936b2…c634sent to0xcb162218…f85c·#22,873,513·0x32e45bdf…c8d132
Delegate and community representation that integrates with the Obol Association/Labs team is a healthy step for overall community and project relations. Approving the cancel role as an msig increases the surface area of things to monitor, but also allows for better flexibility and evolution of the concept as the collective grows.
0xde91165f…b98asent to0xcb162218…f85c·#22,870,311·0x97cdd22e…688f89
Voting YES. A small, transparent committee makes sense for now, as long as there’s a clear plan to expand and move toward delegate elections as the DAO matures. Glad to see the focus on process and future decentralisation.
0x31d0f76e…7ee1sent to0xcb162218…f85c·#22,869,535·0xefd47e8c…9c4376
I personally faced difficulties in getting airdrop, but participated in Obol testnet, also my teammates couldn't get airdrop because they didn't get the badge in time, although they passed the testnet honestly.
0x487c6480…65f7sent to0xcb162218…f85c·#22,869,303·0x3a80b3d0…63379c
I see no valid reason to extend the claim period. The claim period was communicated clearly and I’m sorry for those who missed. Fortunately, the team has provided many opportunities that are still ongoing for those aligned with the project. Those who are actively involved in the project and wish to accrue an allocation can still do so in more than one way. The team is cooking, let them cook. Don’t look back, move forward.
0x746bb7be…4c6dsent to0xcb162218…f85c·#22,867,825·0x958a3628…6a1a01
2 out of 3 signers to establish the cancel role is not sufficiently decentralised in my view. Willing to further explore and support this proposal in future with the updated and more decentralised treshold.
0x6d465d20…3ffbsent to0xcb162218…f85c·#22,867,261·0x687c4e33…6d93ac
Despite this OIP needed more time to cover aspects commented in the discussion (like setting a 3-5 instead a 2/3 scheme) this OIP will serve as a security mechanism for the collective
0x986efbf4…92bcsent to0xcb162218…f85c·#22,861,871·0xa0209872…20bce1
While well prepared and reasoned, I see no real need for this proposal and it would be a distraction of the team, that is rightfully focused on getting more adoption and future development of the community.
0xde91165f…b98asent to0xcb162218…f85c·#22,848,683·0x4d43b3f2…9b5859
I’m voting NO on this proposal. My previous suggestion — to require automatic staking for late claimants as proof of real commitment — was ignored. Simply re-opening the claim window benefits opportunistic actors and just adds sell pressure, without building long-term participation or strengthening the community. This approach doesn’t align with Obol’s SQUAD values or true decentralisation.
0x49df3cca…6f29sent to0xcb162218…f85c·#22,845,627·0xa369c55d…f194a4
# OIP#6 Assigning the Cancel Role to the Obol Association # **Abstract** This proposal informs the community that the Obol Association will assign the cancel function in the Governor contract to a small governance committee. This committee will have a narrow and procedural mandate: to act when a proposal has been posted onchain without following the [established governance process](https://docs.obol.org/community-and-governance/governance/token-house#token-house-governance-proposal-process). The committee will be composed of three members: one from the Obol Association, one from Obol Labs, and one trusted delegate. It will operate via a 2-of-3 multisig, and any action taken will be accompanied by a public rationale posted on the forum. While this is a small, procedural committee, it is also intended to lay the foundation for further decentralising this instance. Over time, as the scope of work expands, this body will evolve into a broader and more decentralized council with additional responsibilities and delegate-elected seats. Additional responsibilities will be voted on by the delegates. For now, however, the limited scope of this role does not justify the overhead of running formal delegate elections, and the focus remains on enabling efficient procedural enforcement. *** # **Motivation** Governance participation in the Obol Collective relies on legitimacy and clarity. However, we have seen an instance [where a proposal that did not follow the proper process was still posted to the voting portal](https://vote.obol.org/dao/proposal/42716918524819099764719128892074936994976810846828605915610483046231685146403) and ultimately reached the onchain record despite a lack of community support. This creates three major issues: * It pollutes the public governance history with misleading or unserious proposals; * It confuses newcomers who may interpret rejected or low-quality proposals as representative of the DAO’s direction; * It weakens quorum dynamics by introducing noise that drains delegate attention. To prevent these outcomes, the DAO needs a mechanism that allows for procedural enforcement of its own governance rules. Assigning the cancel role to a small committee provides this enforcement capacity in a controlled and transparent way. This is not a mechanism for censorship. It exists solely to uphold process integrity. All uses of the cancel function will be accompanied by a clear and timely rationale published on the forum. While this initial committee is appointed directly by the Association, it is not meant to remain static. Over time, and as its responsibilities expand, this committee is expected to evolve into a larger instance, with: * A broader mission, * More members, * And delegate-elected seats. At that stage, elections and more formal processes will be introduced. **For now, however, the limited scope does not warrant the coordination overhead of running a full election process.** *** # **Specifications** ### **Cancel Role Assignment** * The cancel function in the Governor contract will be assigned to a 2-of-3 multisig controlled by a small governance committee. * Initial members: * One representative from the **Obol Association**, * One from **Obol Labs** , * One **trusted delegate**, appointed by the Association. * The committee is only empowered to act when a proposal does **not follow the required governance process**, as defined in the [governance documentation](https://docs.obol.org/community-and-governance/governance/token-house#token-house-governance-proposal-process). * Any use of the cancel function will be: * Strictly limited to procedural violations, * Accompanied by a **public forum post** explaining the rationale for cancellation. ### **Resubmission Cooling Period** * If a proposal fails two onchain votes in a row (even after rework), it will be **ineligible for resubmission for 5 governance cycles**, or approximately **3.5 months** (based on the current 3-week cycle length). * This is intended to reduce spam and delegate fatigue while still allowing proposers to rework ideas. * However, the topic itself is **not permanently blocked**. The committee will have discretion to assess whether a revised submission is **substantially different** from prior versions. If the changes are meaningful, earlier resubmission may be allowed. * This policy will be documented in the governance guidelines. *** ### **Execution** * The cancel role will be assigned to a 2-of-3 multisig governed by the designated committee. This will be implemented by granting the existing `CANCEL_ROLE` on the Timelock contract to the multisig. * No contract upgrade is required, as the role already exists and can be assigned via a standard governance proposal. * For now, the current design is sufficient to uphold procedural safeguards, and represents a meaningful first step. The Obol Association will support the committee operationally, and improvements can be proposed over time as governance matures.
0x6f9bb7e4…8a1dsent to0xcb162218…f85c·#22,839,734·0x134ca692…18de88
# OIP#5 Extension of the Airdrop Claim Period for Eligible Participant **Abstract**: This proposal requests an extension of the claim period for the recent Obol airdrop, allowing eligible participants who were unable to claim within the initial timeframe to receive their tokens. The extension is aimed at fostering inclusivity, enhancing community trust, and ensuring long-term engagement within the Obol ecosystem *** **Motivation**: The airdrop is an important mechanism for distributing ownership, aligning incentives, and growing the Obol community. However, a significant number ( *more than half of the participants didn’t receive their allocation ~60%* ) of eligible participants were unable to claim their tokens due to a variety of reasons, such as: * Insufficient or missed communications, including lack of announcements from partner projects about the token claim * Technical issues or lost wallet access during the claim window. * Personal circumstances (e.g., travel, health issues, military service). Ultimately, the specific reasons listed above are not the most important factor. What truly matters is that these users actively contributed to the growth and decentralization of the Obol network but were unable to claim. The claim restrictions seem to have been introduced primarily as a procedural measure, rather than being necessitated by security, legal, or regulatory considerations. Other major Web3 projects have recognized the importance of honoring contributor efforts over rigid deadlines. For example, **Optimism** introduced multiple rounds of retroactive airdrops to include previously excluded contributors (https://app.optimism.io/airdrops) and **Arbitrum** provided 6-month claim period (https://docs.arbitrum.foundation/airdrop-eligibility-distribution) Learn about the $ARB airdrop eligibility and distribution specifications. These examples show that flexibility and fairness are aligned with decentralization principles Extending the claim period offers several benefits: 1. **Inclusivity**: Ensures that all eligible participants who wish to engage with Obol can do so. 2. **Community Trust**: Demonstrates the project’s responsiveness and commitment to fairness. 3. **Ecosystem Growth**: More token holders = more potential stakers, governance participants, and builders. 4. **Reputation**: Aligns Obol with other leading projects known for their community-centric approaches. 5. **Feasibility**: Technically straightforward with no costs. *** **Specification:** * **Extension Period**: Propose an additional 8 weeks for eligible participants to claim their tokens * **Eligibility**: Maintain the original eligibility criteria; no new recipients will be added. * **Process**: * Re-open the claim interface for the defined period. * Conduct targeted communication campaigns to ensure maximum awareness. * Optionally, publish clear statistics on unclaimed tokens to date. **Communications Plan** To address the concern regarding insufficient or missed communications, this proposal also includes a clear and actionable communications plan to ensure maximum awareness in the event of a claim period extension: 1. **Enhanced Public Announcements**: * Coordinated announcements across all Obol official channels, including Twitter, Discord, Telegram, and the community forum. * Specific outreach to partner projects with a request to amplify the message and inform their respective communities about the extended claim window. 1. **Website Banner**: * A prominent banner on the Obol homepage ([https://obol.org/](https://obol.org/)) displaying a clear call-to-action about the extended claim period, with a direct link to the claim interface and relevant instructions. By incorporating this communication strategy, the proposal aims to significantly mitigate the risk of users missing out again, ensuring that the extended claim period achieves its full intended impact **Technical Problem** Currently, it is no longer possible to execute `claimAndDelegate` due to the campaign’s expiration. However, the contract allows the creation of a new campaign via `createUnlockedCampaign` or `createLockedCampaign`. Accordingly, action is indeed required from the Obol developers — to launch a new campaign — but no contract modification is necessary **Expenses** Expenses by the Obol team related to this proposal should be compensated both the costs of developers and active promotion in the media \*\* **Action Plan**:\*\* * **June 3 - June 24**: Post proposal on forum for feedback, get approval from 4 top-100 delegates (*done*) * **July 3 - July 10**: Submit proposal on Tally for onchain voting * **July 11 - July 31**: Cost Analysis from Obol team * **OBOL Token Claim Extension**: Media preparation and initiating a Second Claim Period *** **Conclusion**: This proposal requests an additional 8 weeks for eligible participants to claim their tokens. By extending the airdrop claim period, Obol can align with these best practices, reinforce its commitment to fairness, and foster a stronger and more active community `p.s. We have confirmation from 4 delegates from the top 100 who agree to launch this vote`
0xb79294d0…89d7sent to0xcb162218…f85c·#22,577,756·0xfc995967…bd8568
We support the general direction of introduction to the delegate compensation and experimental DRS integration. However, similarly to other delegates point out, the software development cost shouldn’t be covered as this feature is an asset to Tally and likely be used for other DAOs in the future. We suggest Tally to apply for a future retro grant once it’s used by the DAO.
0x3070f20f…ec29sent to0xcb162218…f85c·#22,552,938·0xbe1d72ee…6dcb8e
I agree with the need for delegate compensation however the cost of implementing this might be a little high. Can the price of SC implementation be justified ? I find it hard to ... despite this It will somewhat be hopefully money well spent !
0x986efbf4…92bcsent to0xcb162218…f85c·#22,547,370·0x0cd2b08c…0f3aad
Good discussion and good starting point that will be refined within 6 months. See https://community.obol.org/t/oip-4-delegate-compensation-and-delegate-reputation-score-integration-for-stobol/522/44
1-50 of 70