← Back to list
EN RU

[SEP 55] Fund Safenet Beta for SAFE Token Utility

File: report-snapshot-0xb85ed0346bb07196786df5145e57f5e3e5054d35ba7d5f67594faaa6b7a98bcd.json

Source Information

URL: https://snapshot.org/#/s:safe.eth/proposal/0xb85ed0346bb07196786df5145e57f5e3e5054d35ba7d5f67594faaa6b7a98bcd

Fetched at: 20.04.2026, 18:50:38

Source type: snapshot

Extracted Data

[SEP 55] Fund Safenet Beta for SAFE Token Utility

Abstract

This proposal requests 5M SAFE tokens from the SafeDAO treasury to subsidise "Safenet Beta" staking rewards over a 6 month period.

Safenet Beta is a permissioned validator network that attests Safe transactions onchain, in order to enforce transaction security and protect users from high-risk threats and malicious actors e.g. phishing, UI compromises.

The requested rewards are intended to:

- incentivise and bootstrap a minimum viable validator set
- activate SAFE token utility through staking & open delegation
- de-risk the consensus and incentive design before full decentralisation

---

Proposal details

Purpose and Background

Safenet was originally announced at the end of 2024 with a focus on solving cross-chain fragmentation. It has since pivoted towards a security-focused architecture in 2025, given the rising threat of sophisticated attacks and malicious organisations.

The Problem

Since 2017, more than $20 billion in digital assets have been stolen through wallet compromises, malicious applications, and supply-chain exploits. These attack vectors increasingly affect:

- individuals managing personal assets
- DAOs and foundations managing treasuries
- protocol operators managing governance keys
- companies managing operational wallets

While wallets and security firms have improved user control over the years, transaction verification remains fragmented and manual, relying on local heuristics coming from a centralised database or UI-based trust. The EVM and non-EVM ecosystem lacks a scalable and transparent layer that can validate transaction safety in realtime, and truly prevent users from signing off on malicious transactions.

What is Safenet?

Safenet is a validator-based network that enables wallet transaction security checks to be enforced onchain.

It replaces centralized transaction security infrastructure (single KMS servers, UI warnings) with a resilient network of independent validators who attest to transaction safety.

Safenet's long-term goal is to provide a scalable, transparent enforcement layer that prevents high-risk or malicious transactions from being executed - even if a user signs them by mistake. See Safenet Documentation.

What is Safenet Beta?

Safenet Beta is the first production iteration of Safenet. It launches with a small permissioned validator set and focuses on validating Safenet's core assumptions under real-world load, specifically:

- whether the validator network can reliably process transaction checks at scale
- whether validator participation can be measured and incentivized
- whether SAFE staking and delegation can bootstrap economic security

The Beta itself intentionally launches with:

- A trusted permissioned validator set consisting of 6 validators run by Gnosis, Core Contributors, Greenfield, Safe Labs, Rockaway and Blockchain Capital with a minimum stake of 3.5M SAFE tokens
- A UI enabling SAFE holders to stake / unstake to Safenet validators
- Basic transaction checks implemented in the consensus protocol
- A transaction attestation explorer
- DAO-funded rewards (if SEP-55 passes)

Advanced checks, slashing, and long-term sustainable fee-based rewards will follow in later phases.

Who is this Network for?

- Web3 users wanting protection from blind-signing, phishing, and UI exploits
- Wallet operators looking to offer enforced onchain security rather than offchain warnings.
- Security providers looking to be rewarded for their transaction checking expertise
- Validators who want to run nodes, secure transactions, and earn fees for providing security.

Type of Tx Checks

Safenet Beta Checks (Static)

- No unexpected delegatecalls
- Upgrade only to trusted singletons
- Only allow to add trusted modules
- Only trusted fallback handlers can be set
- Only trusted guards can be set

Future Checks (Context Specific)

- Transfer/swap volumes & slippage management
- Allow/deny lists of transfer recipients/custom smart contracts
- Custom constraints around calldata and parameters that can be passed to smart contracts
- Actively exploited protocols/contracts

Why this Proposal is needed

Safenet Beta delivers on a direction SafeDAO has been building toward since 2024. SEP-21, which passed with 96.4% approval and 1,323 voters, introduced five foundational layers for SAFE token utility, with Security Abstraction being one of the focus areas. It explicitly described SAFE staking as "formalized staking for economic security across protocol components, governed through SafeDAO". SEP-23 then funded a working group to research and prioritize token utility use cases, with staking as one of the stated focus areas.

More recently, community members have been pushing for concrete progress. Dennison Bertram's June 2025 forum proposal on decentralizing Safe's transaction service outlined a model where SAFE holders stake tokens to operate infrastructure nodes, with community members explicitly naming Safenet as the right venue to build this. Meanwhile, multiple token holders have raised concerns on the forum that token utility remains theoretical two years after SEP-21 passed. Safenet Beta answers these calls. It implements the staking and security abstraction model the community voted for in SEP-21, puts the SEP-23 research into practice, and gives SAFE a concrete utility function beyond governance for the first time.

Safenet's long-term objective is for validator and delegator rewards to be funded by transaction fees paid by users / integrators and network usage. However, Safenet Beta's system is not yet mature enough to rely on organic fee demand. So in order to:

- bootstrap validator participation
- ensure reliable uptime and attestation coverage
- kickstart token utility

Safenet Beta requires temporary reward subsidies for the next 6 months. As without subsidies, the Safenet Beta risks insufficient validator participation, low stake participation and weaker economic security signals.

!image

Relationship to SEP-54 (Resource Allocation Pause)

SEP-54 paused all SafeDAO resource allocation to allow the Foundation to focus on structural changes, including the launch of Safe Labs and Safe Research. More than six months have passed since the pause took effect, meaning it can now be lifted by either the SEF Council or a SafeDAO governance vote. This proposal requests a narrow, one-time lift of the pause, scoped exclusively to the Safenet Beta allocation described herein. Approval of SEP-55 does not reopen general resource allocation. However, the experience of running this allocation, from reward design to distribution and evaluation, should feed directly into the design of whatever replaces OBRA as SafeDAO's resource allocation framework going forward. A successful Safenet Beta would also establish the foundation for a more targeted approach to SafeDAO resource allocation, one that is tied to concrete protocol infrastructure rather than broad ecosystem grants.

---

Requested Funding

This proposal requests:

5,000,000 SAFE tokens

where:

- 4.5M tokens will be allocated for Safenet Beta staking rewards for a 6-month period with rewards distributed every 2 weeks.
- 0.5M tokens will be allocated to run an open RFP for Safenet staking interfaces.
- Any portion of the 0.5M SAFE tokens approved under this proposal that remains unspent or undisbursed, at the conclusion of the applicable program periods shall be retained by the SEF.

---

Reward Design

Full reward details can be found here

The proposed reward design follows these principles:

Validators

- Validators earn rewards based on:
- stake delegated to them
- participation rate in attestations
- Validators receive a fixed commission on delegator rewards of 5%
- Commission is due to added costs associated with reputation risk, infra cost, large SAFE exposure.
- Validators receive rewards relative to their participation rate.
- No rewards are awarded below a minimum participation threshold of 75%
- Validator stake concentration is discouraged by penalising rewards growth beyond the average validator stake.
- Validators need to maintain minimum validator stake of 3.5M SAFE in order to be remain eligible for rewards.

Delegators

- SAFE holders may delegate SAFE to validators
- Delegators earn rewards proportional to delegated stake
- Delegators do not need to run infrastructure

Rewards distribution

- Rewards will be eligible for those who stake from April 7th, 2026 00:00:00 UTC onwards
- Calculated offchain every two weeks
- Distributed via a Merkle drop contract every two weeks
- Rewards distributed every 2 weeks
- Users must actively claim their rewards
- Rewards below 1,000 USD per two weeks will NOT require KYC (cf. full compliance requirements)

---

Goals and Success Criteria (6 months)

The objective of the Safenet Beta rewards subsidy is to prove that:

Technical

- the validator network can process Safe transaction checks at scale
- validator participation is measurable and enforceable via reward eligibility
- onchain tx attestations are reliably produced and visible

Economic

- SAFE token staking and delegation can bootstrap significant economic security
- incentives align validators toward consistent performance
- the DAO can credibly point to SAFE token utility as a live mechanism

---

Alternative Solutions?

No rewards subsidy - Considered but not pursued

Without subsidies, Safenet Beta risks low validator participation and weak network learnings.

SEF-only funding - Considered but not pursued

While SEF may support ecosystem initiatives, Safenet is a SafeDAO-level token utility initiative and should be validated through SafeDAO governance.

Smaller reward allocation - Considered but not pursued

A smaller allocation risks being insufficient to incentivise consistent validator participation and meaningful delegation, especially given minimum stake expectations and the requirement to secure the network credibly.

---

Implementation

Timeline

- Safenet Beta staking UI: live today
- SAFE Rewards launch: From April 7th, 2026 (if DAO proposal is approved)
- Reward Distribution: Begins after the proposal is ratified but rewards will be calculated retroactively from April 7th, 2026 for a total of 6 months.

Resourcing

- [x] Own implementation possible
- [ ] Own implementation but with funding
- [ ] Request for technical support through Safe matter experts

Additional Funding Request: UI RFP

While a minimal staking interface, based on the code in this repository, is operated by Core Contributors, relying on a single interface introduces several risks:

- centralisation risk
- operational dependency
- single point of failure

To align with SafeDAO's principle of resilient decentralised infrastructure, this proposal includes an additional request of 500,000 SAFE tokens to:

1. run an open RFP for Safenet Beta staking interfaces
2. fund independent operators to provide a UI to stake/unstake SAFE and claim rewards
3. ensure Safenet Beta has multiple reliable frontends available to SAFE holders
- Each UI would receive a max amount of 96k SAFE per year (8k SAFE per month)

The Safe Ecosystem Foundation (SEF) will:

- manage the RFP process
- evaluate submissions
- select suitable providers
- execute the grants and payout

---

Effects & Impact Analysis

Effects of this Proposal

If passed, SEP-55 will have the following direct effects:

- 5M SAFE tokens will be transferred from the SafeDAO treasury to the SEF for distribution over a 6-month period
- A live, DAO-funded staking and delegation mechanism will be operational for the first time, giving SAFE a concrete utility function beyond governance
- Six permissioned validators will attest Safe transactions onchain, replacing centralised security warnings with an enforceable, transparent layer

Pros

- Delivers on prior DAO mandates: SEP-21 (96.4% approval) and SEP-23 explicitly committed SafeDAO to staking and security abstraction as token utility pillars.
- Low trust assumptions for delegators: SAFE holders can participate without running infrastructure, lowering the barrier to meaningful network participation.

Cons

- Treasury cost with no immediate revenue offset: The 5M SAFE subsidy is funded entirely by the DAO treasury with no fee income during Beta, before fee-based sustainability can be implemented.
- Permissioned validator set introduces some centralisation: The initial 6 validators are selected rather than open, which limits decentralisation during Beta. While intentional and time-bounded, it represents a trust assumption before full decentralisation.

Risks

- Validator underperformance: Validators who fall below the 75% participation threshold earn no rewards. If multiple validators underperform simultaneously, network attestation coverage could degrade, undermining the core security proposition.
- Fee transition risk. Safenet Beta assumes that organic fee demand will replace subsidies after 6 months. If wallet operator adoption or user transaction volume is insufficient by that point, the DAO may face pressure to extend subsidies.

---

Governance Process & Compliance

This proposal is submitted on behalf of the Safe Ecosystem Foundation represented by the Foundation Council, and is intended to comply with SafeDAO governance requirements, including:

- forum discussion period
- snapshot vote
- SEF compliance requirements for treasury execution

This proposal follows the standard SEP-7 governance process as amended by SEP-53, which removed sprint-type restrictions and allows any proposal to be submitted in any sprint. Given that no active governance season calendar has been in effect during the SEP-54 pause period, this proposal is submitted independently of a specific sprint cycle. It will go through the full SEP-7 process: forum discussion, maturity signaling by three delegates or Guardians holding a combined minimum of 60,000 SAFE, and a Snapshot vote including a "Make no changes" option. The Foundation Council members named in the disclaimers section will abstain from both signaling and voting.

---

Disclaimers

The validators were determined based on technical expertise, pro-active outreach, as well as ability to show sufficient token holdings in order to provide the minimum stake of 3.5M tokens. It is planned that the validator set is updated and expanded in the future up until it is open and permissionless.

Safe Labs GmbH, Berlin, is a wholly owned subsidiary of SEF and the operator of Safe Wallet by Safe Labs interface, which creates a potential conflict of interest. The Foundation and its foundation council members will abstain from voting on this proposal.

Stefan George is a member of the SEF foundation council and founder of Gnosis who is running a Safenet Beta validator which creates a potential conflict of interest. GnosisDAO as largest Safe token holders is considered as legitimized to be a running one of the initial validators. Stefan will abstain from voting on this proposal.

Richard Meißner is a member of the SEF foundation council and shareholder of Core Contributors GmbH, Berlin, which creates a potential conflict of interest. Core Contributors worked on Safenet Beta based on a grant agreement and is therefore considered to be invaluable in gaining first-hand experience in operating a validator. Richard will abstain from voting on this proposal.

The minimum validator stake amount of 3.5M SAFE applies to all validators alike.

---

Open Questions

None

---

Copyright

Copyright and related rights waived via CC0.

Voting Options

  • Accept
  • Make No Changes
  • Abstain

Analysis

Summary

SEP-55 requests 5M SAFE tokens (4.5M for staking rewards over 6 months, 0.5M for staking interface RFP) to subsidize Safenet Beta, a permissioned validator network with 6 pre-selected validators that attest Safe transactions onchain. The proposal aims to bootstrap SAFE token utility through staking and delegation, but introduces significant centralization during the Beta period.

Key Changes

  1. Transfer 5,000,000 SAFE tokens from SafeDAO treasury to Safe Ecosystem Foundation (SEF)

  2. Allocate 4,500,000 SAFE for staking rewards distributed over 6 months via bi-weekly Merkle drops

  3. Allocate 500,000 SAFE for open RFP to fund independent staking interface operators

  4. Establish 6 permissioned validators (Gnosis, Core Contributors, Greenfield, Safe Labs, Rockaway, Blockchain Capital) each requiring 3.5M SAFE minimum stake

  5. Implement validator reward eligibility based on 75% participation threshold

  6. Create SAFE token utility through staking and open delegation to validators

⚠️ Risks

  • Permissioned validator set of 6 pre-selected entities limits decentralization for the Beta period, contradicting the user's high decentralization priority

  • 5M SAFE treasury allocation with no immediate revenue offset - subsidy funded entirely by DAO treasury with no fee income during Beta

  • Fee transition risk: if wallet operator adoption or user transaction volume is insufficient after 6 months, DAO may face pressure to extend subsidies

  • Validator underperformance risk: if multiple validators fall below 75% participation threshold simultaneously, network attestation coverage could degrade

  • SEF controls RFP process for staking interfaces and manages fund distribution, creating centralization of administrative power

  • Multiple conflicts of interest disclosed: Stefan George (SEF council, Gnosis founder), Richard Meissner (SEF council, Core Contributors shareholder), Safe Labs (SEF subsidiary)

⚠️ Benefits

  • Implements staking and security abstraction model mandated by prior SEP-21 (96.4% approval) and SEP-23 votes

  • Creates first concrete SAFE token utility function beyond governance through staking and delegation

  • Delegators can participate without running infrastructure, lowering barrier to network participation

  • Validates core assumptions under real-world load: validator network scalability, participation measurement, staking incentive alignment

  • Clear reward distribution schedule: bi-weekly Merkle drop distributions for 6 months starting April 7, 2026

  • Validator performance requirements enforce participation (75% threshold) and discourage stake concentration through reward penalties

❓ Unknown Factors

  • Exact formula for reward calculation is referenced externally (docs.safefoundation.org/safenet/staking/rewards) but not provided in proposal

  • Slashing conditions mentioned for future phases but not specified for Beta period

  • Full KYC compliance requirements mentioned but details referenced externally

  • No explicit roadmap or criteria for transitioning from permissioned to permissionless validator set

  • Criteria for RFP selection and evaluation for staking interface providers not detailed

  • No specification of what happens to unclaimed rewards or undistributed funds after 6-month period (0.5M RFP portion states unspent returns to SEF, but staking rewards portion unclear)

  • Validator selection criteria beyond 'technical expertise, pro-active outreach, and ability to show sufficient token holdings' not specified

Evidence Quotes

This proposal requests 5M SAFE tokens from the SafeDAO treasury to subsidise Safenet Beta staking rewards over a 6 month period.

A trusted permissioned validator set consisting of 6 validators run by Gnosis, Core Contributors, Greenfield, Safe Labs, Rockaway and Blockchain Capital with a minimum stake of 3.5M SAFE tokens

The 5M SAFE subsidy is funded entirely by the DAO treasury with no fee income during Beta, before fee-based sustainability can be implemented.

The initial 6 validators are selected rather than open, which limits decentralisation during Beta.

If wallet operator adoption or user transaction volume is insufficient by that point, the DAO may face pressure to extend subsidies.

Stefan George is a member of the SEF foundation council and founder of Gnosis who is running a Safenet Beta validator which creates a potential conflict of interest.

Richard Meißner is a member of the SEF foundation council and shareholder of Core Contributors GmbH, Berlin, which creates a potential conflict of interest.

Safe Labs GmbH, Berlin, is a wholly owned subsidiary of SEF and the operator of Safe Wallet by Safe Labs interface, which creates a potential conflict of interest.

Recommendation

Suggested option: Make No Changes
Confidence level: medium

Reasoning

This is a well-specified proposal with clear parameters (5M SAFE, 6 months, 6 validators, 75% threshold, bi-weekly distributions), but it has two fundamental tensions with the user's principles. First, the permissioned validator structure directly conflicts with HIGH decentralization priority - the proposal explicitly states the 'initial 6 validators are selected rather than open, which limits decentralisation.' Second, the 5M SAFE treasury allocation with no revenue offset conflicts with HIGH treasury risk sensitivity. While the proposal acknowledges these trade-offs as intentional and time-bounded, and has clear success criteria and prior mandate from SEP-21/SEP-23, the centralization introduced is structural rather than merely transitional. Multiple conflicts of interest among SEF council members and validator operators add governance risk. The proposal passes the 'needs_strict_spec' requirement but fails on alignment with decentralization and treasury risk principles.

⚠️ Conflicts with user principles

  • decentralization_priority (HIGH): Permissioned validator set of 6 pre-selected entities contradicts decentralization goals

  • treasury_risk_sensitivity (HIGH): 5M SAFE allocation with no immediate revenue offset and potential subsidy extension pressure

⚠️ Limitations and Warnings

  • This is not legal or financial advice.

  • The tool may have failed to extract all proposal parameters.

  • Critical parameters must be checked manually.

Verification

Verified: No

Validators: Verified by 3 validators

Model: zai-org/GLM-5-FP8

Merkle root: 8db9838f52b04ee7a7424add8c3d8664bd4174946c11f7638cfbe9f26e824834

Request ID: d4d60a349ce343b0941a44d682b1854d

Auction

Status: Done

Bids placed: 3

Bids revealed: 3

Auction address: https://explorer.ambient.xyz/address/Szq1HZXhcDoNWHuf7N7Vbh5RBw3CqARcHfZvTZiFZy7

Bidder: https://explorer.ambient.xyz/address/98WKDq5HzneuZycJiCSM5ajuKzscQMop2GsRdxK95q2m

Verification Boundary

Deterministic (verifiable)

  • analysis.summary
  • analysis.key_changes[0]
  • analysis.key_changes[1]
  • analysis.key_changes[2]
  • analysis.key_changes[3]
  • analysis.key_changes[4]
  • analysis.key_changes[5]

Interpretive (requires review)

  • analysis.risks[0] (interpretive) "Permissioned validator set of 6 pre-selected entities limits decentralization for the Beta period, c..."
  • analysis.risks[1] (interpretive) "5M SAFE treasury allocation with no immediate revenue offset - subsidy funded entirely by DAO treasu..."
  • analysis.risks[2] (interpretive) "Fee transition risk: if wallet operator adoption or user transaction volume is insufficient after 6 ..."
  • analysis.risks[3] (interpretive) "Validator underperformance risk: if multiple validators fall below 75% participation threshold simul..."
  • analysis.risks[4] (interpretive) "SEF controls RFP process for staking interfaces and manages fund distribution, creating centralizati..."
  • analysis.risks[5] (interpretive) "Multiple conflicts of interest disclosed: Stefan George (SEF council, Gnosis founder), Richard Meiss..."
  • analysis.benefits[0] (interpretive) "Implements staking and security abstraction model mandated by prior SEP-21 (96.4% approval) and SEP-..."
  • analysis.benefits[1] (interpretive) "Creates first concrete SAFE token utility function beyond governance through staking and delegation..."
  • analysis.benefits[2] (interpretive) "Delegators can participate without running infrastructure, lowering barrier to network participation..."
  • analysis.benefits[3] (interpretive) "Validates core assumptions under real-world load: validator network scalability, participation measu..."
  • analysis.benefits[4] (interpretive) "Clear reward distribution schedule: bi-weekly Merkle drop distributions for 6 months starting April ..."
  • analysis.benefits[5] (interpretive) "Validator performance requirements enforce participation (75% threshold) and discourage stake concen..."
  • analysis.unknowns[0] (uncertainty) "Exact formula for reward calculation is referenced externally (docs.safefoundation.org/safenet/staki..."
  • analysis.unknowns[1] (uncertainty) "Slashing conditions mentioned for future phases but not specified for Beta period..."
  • analysis.unknowns[2] (uncertainty) "Full KYC compliance requirements mentioned but details referenced externally..."
  • analysis.unknowns[3] (uncertainty) "No explicit roadmap or criteria for transitioning from permissioned to permissionless validator set..."
  • analysis.unknowns[4] (uncertainty) "Criteria for RFP selection and evaluation for staking interface providers not detailed..."
  • analysis.unknowns[5] (uncertainty) "No specification of what happens to unclaimed rewards or undistributed funds after 6-month period (0..."
  • analysis.unknowns[6] (uncertainty) "Validator selection criteria beyond 'technical expertise, pro-active outreach, and ability to show s..."
  • recommendation.reasoning (interpretive) "This is a well-specified proposal with clear parameters (5M SAFE, 6 months, 6 validators, 75% thresh..."
  • recommendation.conflicts_with_user_principles[0] (interpretive) "decentralization_priority (HIGH): Permissioned validator set of 6 pre-selected entities contradicts ..."
  • recommendation.conflicts_with_user_principles[1] (interpretive) "treasury_risk_sensitivity (HIGH): 5M SAFE allocation with no immediate revenue offset and potential ..."

Uncertainty Flags

  • unknowns:Exact formula for reward calculation is referenc...
  • unknowns:Slashing conditions mentioned for future phases ...
  • unknowns:Full KYC compliance requirements mentioned but d...
  • unknowns:No explicit roadmap or criteria for transitionin...
  • unknowns:Criteria for RFP selection and evaluation for st...
  • unknowns:No specification of what happens to unclaimed re...
  • unknowns:Validator selection criteria beyond 'technical e...

Method

Kind: heuristic

Version: 2

  • Deterministic layer is based on direct matching to extracted fields and evidence_quotes, plus presence of hard literals (numbers, addresses, option strings).
  • Interpretive layer includes summary, risks, benefits, and recommendation reasoning.
  • This is a boundary labeling aid, not a proof of truth.

Week 9 - Verification Hooks

Mixed categories detected: true

Requires separation: true

Strict mode: false

Strict rejection triggered: false

Routing action: WARN

Segments

  • analysis.summary deterministic

    SEP-55 requests 5M SAFE tokens (4.5M for staking rewards over 6 months, 0.5M for staking interface RFP) to subsidize Safenet Beta, a permissioned validator network with 6 pre-selected validators that attest Safe transactions onchain.

    Reasons: contains_hard_literal
  • analysis.summary unverifiable

    The proposal aims to bootstrap SAFE token utility through staking and delegation, but introduces significant centralization during the Beta period.

    Reasons: not_anchored_to_source_material
  • analysis.key_changes[0] deterministic

    Transfer 5,000,000 SAFE tokens from SafeDAO treasury to Safe Ecosystem Foundation (SEF)

    Reasons: contains_hard_literal
  • analysis.key_changes[1] deterministic

    Allocate 4,500,000 SAFE for staking rewards distributed over 6 months via bi-weekly Merkle drops

    Reasons: contains_hard_literal
  • analysis.key_changes[2] deterministic

    Allocate 500,000 SAFE for open RFP to fund independent staking interface operators

    Reasons: contains_hard_literal
  • analysis.key_changes[3] deterministic

    Establish 6 permissioned validators (Gnosis, Core Contributors, Greenfield, Safe Labs, Rockaway, Blockchain Capital) each requiring 3.5M SAFE minimum stake

    Reasons: contains_hard_literal
  • analysis.key_changes[4] deterministic

    Implement validator reward eligibility based on 75% participation threshold

    Reasons: contains_hard_literal
  • analysis.key_changes[5] unverifiable

    Create SAFE token utility through staking and open delegation to validators

    Reasons: not_anchored_to_source_material
  • analysis.risks[0] probabilistic

    Permissioned validator set of 6 pre-selected entities limits decentralization for the Beta period, contradicting the user's high decentralization priority

    Reasons: contains_hard_literal interpretive_field
  • analysis.risks[1] probabilistic

    5M SAFE treasury allocation with no immediate revenue offset - subsidy funded entirely by DAO treasury with no fee income during Beta

    Reasons: interpretive_field
  • analysis.risks[2] probabilistic

    Fee transition risk: if wallet operator adoption or user transaction volume is insufficient after 6 months, DAO may face pressure to extend subsidies

    Reasons: contains_hard_literal contains_inference_language interpretive_field uncertainty_language
  • analysis.risks[3] probabilistic

    Validator underperformance risk: if multiple validators fall below 75% participation threshold simultaneously, network attestation coverage could degrade

    Reasons: contains_hard_literal contains_inference_language interpretive_field
  • analysis.risks[4] probabilistic

    SEF controls RFP process for staking interfaces and manages fund distribution, creating centralization of administrative power

    Reasons: interpretive_field
  • analysis.risks[5] probabilistic

    Multiple conflicts of interest disclosed: Stefan George (SEF council, Gnosis founder), Richard Meissner (SEF council, Core Contributors shareholder), Safe Labs (SEF subsidiary)

    Reasons: interpretive_field
  • analysis.benefits[0] probabilistic

    Implements staking and security abstraction model mandated by prior SEP-21 (96.4% approval) and SEP-23 votes

    Reasons: contains_hard_literal interpretive_field
  • analysis.benefits[1] probabilistic

    Creates first concrete SAFE token utility function beyond governance through staking and delegation

    Reasons: interpretive_field
  • analysis.benefits[2] probabilistic

    Delegators can participate without running infrastructure, lowering barrier to network participation

    Reasons: interpretive_field
  • analysis.benefits[3] probabilistic

    Validates core assumptions under real-world load: validator network scalability, participation measurement, staking incentive alignment

    Reasons: interpretive_field
  • analysis.benefits[4] probabilistic

    Clear reward distribution schedule: bi-weekly Merkle drop distributions for 6 months starting April 7, 2026

    Reasons: contains_hard_literal interpretive_field
  • analysis.benefits[5] probabilistic

    Validator performance requirements enforce participation (75% threshold) and discourage stake concentration through reward penalties

    Reasons: contains_hard_literal interpretive_field
  • analysis.unknowns[0] unverifiable

    Exact formula for reward calculation is referenced externally (docs.safefoundation.org/safenet/staking/rewards) but not provided in proposal

    Reasons: not_anchored_to_source_material
  • analysis.unknowns[1] unverifiable

    Slashing conditions mentioned for future phases but not specified for Beta period

    Reasons: not_anchored_to_source_material
  • analysis.unknowns[2] unverifiable

    Full KYC compliance requirements mentioned but details referenced externally

    Reasons: not_anchored_to_source_material
  • analysis.unknowns[3] unverifiable

    No explicit roadmap or criteria for transitioning from permissioned to permissionless validator set

    Reasons: not_anchored_to_source_material
  • analysis.unknowns[4] unverifiable

    Criteria for RFP selection and evaluation for staking interface providers not detailed

    Reasons: not_anchored_to_source_material
  • analysis.unknowns[5] deterministic

    No specification of what happens to unclaimed rewards or undistributed funds after 6-month period (0.5M RFP portion states unspent returns to SEF, but staking rewards portion unclear)

    Reasons: contains_hard_literal uncertainty_language
  • analysis.unknowns[6] unverifiable

    Validator selection criteria beyond 'technical expertise, pro-active outreach, and ability to show sufficient token holdings' not specified

    Reasons: not_anchored_to_source_material
  • recommendation.reasoning probabilistic

    This is a well-specified proposal with clear parameters (5M SAFE, 6 months, 6 validators, 75% threshold, bi-weekly distributions), but it has two fundamental tensions with the user's principles.

    Reasons: contains_hard_literal interpretive_field
  • recommendation.reasoning probabilistic

    First, the permissioned validator structure directly conflicts with HIGH decentralization priority - the proposal explicitly states the 'initial 6 validators are selected rather than open, which limits decentralisation.' Second, the 5M SAFE treasury allocation with no revenue offset conflicts with HIGH treasury risk sensitivity.

    Reasons: contains_hard_literal contains_inference_language interpretive_field
  • recommendation.reasoning probabilistic

    While the proposal acknowledges these trade-offs as intentional and time-bounded, and has clear success criteria and prior mandate from SEP-21/SEP-23, the centralization introduced is structural rather than merely transitional.

    Reasons: contains_hard_literal interpretive_field
  • recommendation.reasoning probabilistic

    Multiple conflicts of interest among SEF council members and validator operators add governance risk.

    Reasons: contains_inference_language interpretive_field
  • recommendation.reasoning probabilistic

    The proposal passes the 'needs_strict_spec' requirement but fails on alignment with decentralization and treasury risk principles.

    Reasons: contains_inference_language interpretive_field
  • recommendation.conflicts_with_user_principles[0] probabilistic

    decentralization_priority (HIGH): Permissioned validator set of 6 pre-selected entities contradicts decentralization goals

    Reasons: contains_hard_literal interpretive_field
  • recommendation.conflicts_with_user_principles[1] probabilistic

    treasury_risk_sensitivity (HIGH): 5M SAFE allocation with no immediate revenue offset and potential subsidy extension pressure

    Reasons: interpretive_field

Mixed segments

  • analysis.summary: deterministic unverifiable

Method

Kind: heuristic

Version: 1

  • Deterministic segments are anchored to extracted title/body/options, evidence quotes, or hard literals.
  • Probabilistic segments include recommendation, risk, benefit, and uncertainty language.
  • Unverifiable segments are vague or unsupported without clear anchors.

Refusal Handling

Refusal Detected: Yes

Signals

  • unknowns_present:7

Routed To: HUMAN_REVIEW

Refusal detection is heuristic and conservative. It routes ambiguous or underspecified cases to human review.

Prompt Used

Structured governance analysis prompt. Must output ONLY valid JSON. Must not guess missing options/results; use UNKNOWN.


You are given:

URL:
https://snapshot.org/#/s:safe.eth/proposal/0xb85ed0346bb07196786df5145e57f5e3e5054d35ba7d5f67594faaa6b7a98bcd

EXTRACTED_DATA (may be incomplete):
{
  "source_type": "snapshot",
  "fetched_at": "2026-04-20T18:50:38.324Z",
  "title": "[SEP 55] Fund Safenet Beta for SAFE Token Utility",
  "body": "## Abstract\n\nThis proposal requests **5M SAFE tokens** from the SafeDAO treasury to subsidise **\"Safenet Beta\"** staking rewards over a 6 month period.\n\nSafenet Beta is a perm...

Model: zai-org/GLM-5-FP8