New editorial guide, published 16 October 2026. The historical sources linked below are preserved separately and are not represented as current product or service information.
BTCJP's governance notes describe several experiences under the broad heading DAO: creating an experimental token, looking at voting interfaces and comparing participation in different communities. The records also contain the author's judgments about how those systems felt to use. They do not establish one universal governance model. A new reader needs to ask a more specific question: how does an expressed preference become an action that changes a system? This guide follows a hypothetical proposal through membership, voting and execution. It does not assert current parameters for the projects named in the archive or turn the original author's opinions into verified findings about those organisations.
Membership and decision authority are different things
Joining a community, holding a token, making a proposal and executing an approved action can involve different requirements. A friendly invitation to participate does not explain all of them. Start with the action the participant wants to perform and identify the rule that permits it. A hypothetical member might be allowed to discuss a proposal but not submit one, or to vote without controlling any execution mechanism. These distinctions are ordinary design choices that should be documented rather than hidden behind the statement that everyone can join.
Create a small role map for the system being studied. Include the proposer, voter, delegate, executor and any administrator with exceptional powers. One person may occupy several roles, but the map should still distinguish the capabilities. Then ask what evidence establishes each capability at the relevant time. A token balance, a membership record and an appointed role are not interchangeable. Keeping them separate makes it possible to explain a failed attempt accurately: the participant may lack a specific permission rather than be excluded from every form of community participation.
A proposal needs an identifiable action
A discussion can express an intention such as improving a product or changing a fee. An executable proposal needs a more exact description of what will change. OpenZeppelin's governance guide describes a modular system in which proposal and execution behaviour depend on the chosen components. A research note should therefore identify the actual mechanism rather than infer it from the appearance of a voting page. The relevant question is what the proposal authorises, which target is affected and which data specifies the intended action.
Consider a hypothetical proposal to change a configuration value from one number to another. Record the target system, the current value, the proposed value and the authority that can apply it. If the voting interface contains only a prose summary, determine where the authoritative action description lives. A mismatch between the prose and the executable action is a substantive finding. The notebook should preserve it instead of assuming that an attractive title guarantees that every later transaction will implement the intention a casual reader took from the title.
Voting power belongs to a rule and a moment
A governance system needs a way to determine voting power and a time at which to measure it. Current holdings do not automatically establish the weight a participant had for a past vote. Delegation, snapshots and the chosen voting token can matter, depending on the implementation. The research question is not simply how many tokens an account has now. It is which rule the specific proposal uses and which observation establishes the participant's relevant power under that rule. A historical screenshot may preserve a display without exposing every underlying calculation.
In a hypothetical test, give one account a role in discussion, another a delegated vote and another a direct holding. Follow the rules rather than assume the accounts have identical powers. Record the observation point and any changes during the proposal's lifetime. This can reveal why a displayed balance and an accepted vote differ without either necessarily being erroneous. It also makes the result reproducible. Another reader can inspect the relevant rule and moment instead of trying to reconstruct a past decision from a present-day wallet screenshot.
Passing a vote is not yet completing an action
A proposal can pass its voting condition while still awaiting another stage. The mechanism may require a queue, an execution transaction or action by an identified group. The correct description depends on the system. A note should distinguish the voting result from the state change the proposal intended to cause. A green passed label proves something about the interface's reported decision state; it does not automatically establish that the target system now has the proposed configuration. That second claim needs evidence from the execution path and resulting state.
Extend the hypothetical configuration proposal into a sequence: it is submitted, voting ends, any required waiting condition is met and the authorised action is attempted. Record the identifier and outcome of each stage. If execution fails, the failed attempt is not the same event as a rejected vote. If execution succeeds but changes a different target from the prose description, the voting result has not resolved the discrepancy. This separation produces a more useful governance history because it shows where a decision stopped and which consequential action actually occurred.
Inspect exceptional powers and dependencies
Governance can coexist with powers that pause, cancel, upgrade or replace parts of a system. These capabilities should be described alongside the ordinary voting route. Their existence does not, by itself, answer whether the design is suitable for a particular purpose. It does change the authority map. A community vote might govern one set of parameters while a separate role controls another important component. A complete research note identifies those boundaries rather than assume that the existence of any vote means every consequential decision follows the same process.
Use a hypothetical incident to test the map. A proposal is pending when an administrator invokes an emergency function, or the interface becomes unavailable before the vote ends. Which actions remain possible? Which actor can cancel or resume the process? Which records show what happened? The exercise should use the actual published mechanism and avoid assigning invented powers to named projects. It is useful because exceptional situations often reveal dependencies that ordinary participation screens do not emphasise, including reliance on an interface, a particular executor or a small approval group.
Write a governance history in stages
A strong proposal record retains the initial action description, applicable rules, voting observation, result, execution evidence and final state. It separates the researcher's interpretation from the system's own recorded events. If a stage is missing, say which evidence is unavailable. A discussion post, a signed preference and a successful state-changing transaction are different documents. Linking them carefully is more informative than collecting screenshots that all use the same proposal title while leaving the relationship between the screenshots unexplained.
The BTCJP archive offers a useful starting point because it records early encounters with several governance interfaces rather than one polished theory of DAOs. A current companion can make the common questions explicit. Who may propose, whose preference counts, when is power measured and how does the action execute? Follow those questions through the exceptional paths too. The result is a practical way to read governance as a sequence of permissions and events, keeping the community's expressed decision distinct from the authority and evidence required to turn that decision into a completed change.
Technical references
From the recovered archive
- DAO UX · captured 5 February 2023
- DEFI: maker Governance, Migrate and Sai CDP Portal · captured 22 April 2021
- Ethereum: Token and DAO creation by togen.io (PROOF) · captured 22 April 2021