Read a proposed protocol change as a transaction
A proposal should be reviewed in terms of the state change it will make, not just its short title. Identify the target contract, parameters, proposer, execution path and the role that authorises execution. Check whether the proposal is queued, challenged, cancelled or already executed, and compare its calldata with the human-readable description where tooling permits.
Context matters because a harmless-looking parameter can affect collateral, permissions or user access across a protocol. Review dependencies and downstream effects, and look for a discussion that explains the rationale and alternatives. A monitoring interface can make review easier, but it does not replace reading the proposal or checking the contract state. The 2019 description cited here is historical and does not verify a present-day service.
A proposal becomes meaningful only through its status
Governance records usually move through stages: discussion, a formal proposal, a voting period and an implementation decision. A forum post can signal an idea without starting a vote; a successful vote can still require a separate transaction or release before code changes on a network.
When reviewing a proposal, record its identifier, author, discussion link, voting dates, quorum or threshold, result and implementation transaction where available. Keep the proposal's stated rationale separate from an independent assessment of its technical effect. A token vote documents a governance process; it does not by itself establish that a change is safe or beneficial.
Record the implementation path after a vote
A governance result is only one point in a change process. Check whether a proposal passed its threshold, whether execution was automatic or required a separate transaction, and whether the deployed code reflects the approved text. Record the implementation address and transaction where the protocol publishes them.
If the vote concerns a parameter or treasury action, compare the requested change with the final on-chain event. This lets a reader distinguish a proposal's intent from what actually occurred. Governance documentation is a record of process; it does not independently determine whether a decision was technically sound.
How to review Ethereum governance proposals
Ethereum governance proposals can describe changes to protocol software, applications or community processes; they do not all share one voting system. A review should identify the proposal author, affected smart contracts, decision process, voting power, execution path and current state. Token-holder sentiment alone may not have authority to change a contract.
For a decentralized governance system, compare the discussion with the transaction or code that would execute. Check whether the proposal is still open, queued, cancelled or already executed, and identify who can pause or upgrade the affected contracts. Spells.fyi was described as a tool for reviewing proposed protocol changes; this historical reference does not establish that a live monitoring service remains available.
From proposal discovery to execution
Governance tools can help a reader find a proposed change, but discovery is only the first step. A reviewer should identify the target contract, the proposer, the exact calldata or state change, the voting system, the decision threshold and any timelock before execution. A title or summary can omit details that materially change the proposal's effect.
The process also has distinct stages: drafting, discussion, voting, approval and execution. A proposal can fail, expire, be replaced or pass without being executed immediately. Readers should verify the final on-chain transaction and compare its parameters with the approved proposal rather than infer execution from a forum post or dashboard badge.
Review technical and economic consequences
A technical review asks which contracts and parameters change, who gains or loses permissions, and whether the change can be reversed. An economic review asks how the change affects incentives, risk allocation, fees or access. These reviews may require different expertise, and one successful vote does not prove that every consequence was understood by participants.
Good review notes distinguish observed code from interpretation. They identify assumptions, affected components and possible failure modes, then explain which questions remain open. When a proposal depends on an oracle, bridge or external service, assess that dependency separately. A governance interface can surface a change but cannot independently certify that it is safe.
Governance is not Bitcoin mining
Protocol governance coordinates decisions about software, parameters or administrative permissions. Bitcoin mining validates proof-of-work blocks under consensus rules. A governance proposal can affect a protocol's operation, while a mining pool manages participant accounting and reward distribution. These activities can intersect in the wider crypto ecosystem but do not perform the same function.
The table below is a separate example of published Bitcoin pool service terms. It does not imply that Spells.fyi reviewed mining pools or that a mining operator governs a protocol. The distinction helps readers understand which records to inspect: proposal and execution data for governance, payout rules and fee terms for a pool.
What ‘spells’ meant in this context
Protocol changes can be consequential even when presented as a small transaction or parameter update. Reviewers need to understand the target contract, proposed state change, proposer, execution conditions, timing and possible downstream effects. An interface can make a proposal easier to inspect, but it cannot replace protocol-specific expertise.
Proposal review is a process
Governance processes differ. Some systems use token voting, delegates, multisignature approvals, timelocks or combinations of mechanisms. A proposal's appearance in a research tool does not mean it passed, executed or was safe. The relevant on-chain and governance records should be checked directly.
A historical research tool
Public software repositories use the Spells.fyi name (Blocklytics public repositories). This provides context for the research-tool concept but does not establish current operation or complete proposal coverage.
Protocol research becomes more useful when it compares mechanisms through shared questions such as incentives, rules and how participants receive value. Governance and mining pools answer those questions differently; this table uses Bitcoin pool payouts and fees as a practical mechanism to examine.
Protocol incentives in practice: Bitcoin pool mechanics
Pool payout rules are separate from protocol proposals and governance decisions.
| Operator | Reward scheme | Pool fee | Read the terms |
|---|---|---|---|
| EMCD | FPPS | EMCD lists a 4% BTC pool fee. Confirm the current terms for your account before connecting hardware. | EMCD reward and fee policy |
| Braiins Pool | FPPS | 2.5% standard pool fee. Braiins OS users may receive a rebate that reduces the effective pool fee to 0%; Braiins OS has a separate 2-2.5% model-dependent development fee. | Braiins payouts and fees; Braiins OS fee terms |
| Foundry USA Pool | FPPS | Fee depends on the group hashrate pricing tier; check current account terms. | Foundry pricing tiers |
Protocol proposals: questions and answers
01Is Spells.fyi still monitoring proposals?
This publication does not confirm that Spells.fyi currently monitors proposals. Its historical role is described from dated material. To review a live proposal, consult the relevant protocol forum, governance contract and execution record.
02Does a listed proposal mean it was approved?
No. A page or forum discussion may describe a proposal before a vote. Check the voting result and, where applicable, the execution transaction or deployed code to determine whether a change took effect.