Eden+Fractal Implementation Plan

Introduction

This implementation plan serves as a technical coordination document for reviving the Eden+Fractal consensus process during the second half of Eden Fractal's first season of Epoch 2. After extensive community discussions during our first five events of the season, we are preparing to implement this proven legislative consensus mechanism that will complete our tripartite governance structure alongside ORDAO (executive) and the Respect Game (judicial).

The purpose of this document is to coordinate the technical requirements, specifications, and implementation details needed to successfully launch Eden+Fractal. This is primarily a planning and coordination resource for those actively involved in building and implementing the process. For a general introduction to Eden+Fractal and information about becoming a delegate, please see our community guide at edenfractal.com/plus.

To implement Eden+Fractal successfully, we need to address several technical requirements and create clear specifications for how the process will work with our current bi-weekly event schedule and Base infrastructure. This document outlines these requirements and provides a space for collaborative problem-solving as we work toward implementation.

Introduction
What is Eden+Fractal?
Historical Context
Technical Requirements and Challenges
Proposed Solutions
Updated Specifications
Benefits and Challenges
Governance Integration
Implementation Discussion Questions
Next Steps
Resources

‣

Yes, I think that the legislative branch would still be independent of the executive branch and be able to determine a new ordao account if the if current ordao account does not confirm it’s decisions. The legislative branch can use the ordao confirmations as a tool to form consensus, not something that they must follow to form consensus. I think the root consensus process of the legislative council is the implicit finalization that you described in the previous iteration. The legislative council can form consensus in conversations during meetings using the spreadsheet and ordao confirmation as tools. It could work like it did in the previous iteration, but now we’d also have the ordao confirmations to make the implicit consensus more explicit. If there is ever a conflict between the ordao confirmations and the implicit consensus of the legislative council, then the legislative council can default back to using the spreadsheet and verbal agreement during meetings to change the ordao account. Most likely the community would detect any conflict with the ordao account within 1 event, so they could still use the ordao confirmations from prior events to help them form consensus on the council formation. In this way the consensus of the legislative process is somewhat similar to the way that bitcoin blocks are confirmed (and less similar to the way that EOS blocks are confirmed), where there is never really 100% certainty that the block is mined but it becomes increasingly confirmed as more blocks get mined (and so I think the standard rule is waiting something like 7 blocks for essentially absolute confirmation). I’m not describing this analogy as well as possible be because I don’t know the right terms and specifics of bitcoin mining, but i sense that the idea is correct. Its something like how both bitcoin and Eden+Fractal confirmations are probabilistic, whereas EOS or ORDAO is absolutely deterministic. The main point is that the Eden+Fractal council could decide on a new ORDAO if they ever wanted to do so, and the ordao confirmations are just a tool to help them determine the state of the council, but their root consensus is achieved during the meeting via conversation (and/or the spreadsheet). The fact that the town hall events are recorded adds more legitimacy and security to the root consensus protocol of the Eden+Fractal Council. Another precedent for this is democratic governments and legislators around the world — I think many have used this kind of process fairly successfully for hundreds of years. obviously there are big improvements needed in these legacy systems (which we’re making with the legislative election process, ORDAO confirmations, and fractal democracy principles), but the core system of gathering together in a room with a video camera and implicitly following a consensus process around who was elected, what are the proposals, etc has worked well in many cases and doesn’t need to be fully reinvented.

What is Eden+Fractal?

Eden+Fractal is an innovative consensus mechanism that elegantly combines two foundational processes from fractal democracy: Eden Elections (also known as upvote elections) and the Respect Game inspired by ƒractally. The process works by having community members both play the Respect Game to measure contributions AND elect delegates during the same breakout room sessions.

Here’s how it works:

During each Eden Fractal event, after playing the Respect Game in breakout rooms, each room elects one delegate.
These delegates form councils that serve for four events, and we always have four councils active at once.
When the community needs to make a decision, it requires approval from at least three of the four councils.

Proposals can only be approved during biweekly Eden Town Hall events, which occur immediately after Eden Fractal Respect Games. This creates a balanced system that is both democratic and efficient, allowing for quick decision-making while ensuring broad consensus.

Historical Context

The Eden+Fractal consensus process was originally proposed by Tadas on October 2nd, 2022, this process was approved by the Eden Fractal community in Meeting 18 and successfully operated for over a year during Epoch 1. The Eden Fractal community successfully implemented the Eden+Fractal process from approximately Meeting 19 through Meeting 80, passing over 10 proposals including meeting time changes, moderator elections, and various community initiatives. You can view the historical record of all delegates and proposals in this spreadsheet, which provides valuable context for our current implementation.

The name "Eden+Fractal" reflects its historical origins, combining the upvote election process pioneered by Eden on EOS with the contribution measurement system the Respect Game (inspired by Fractally). While the original communities that inspired these names have evolved or concluded, the powerful synthesis of their innovations continues to provide value for fractal governance. The comprehensive article at EdenCreators.com/plus provides additional historical context and analysis of the benefits this process has demonstrated.

The process was originally featured in Creator Talk Episode 1, where Dan Singjoy interviewed Tadas about the design philosophy and potential of Eden+Fractal. This conversation, recorded shortly after the initial proposal, explores how the process emerged from months of community discussion and represents a synthesis of the best aspects of various consensus mechanisms.

Recent Developments

More recently, during Eden Fractal Meeting 118, we discussed reintroducing Eden+Fractal as part of our Epoch 2 vision. This discussion highlighted how the process fits into our broader governance framework and explored various options for our legislative needs. In the most recent Eden Town Hall event, we formed consensus on using the Eden+Fractal consensus process. Both of these videos are provided below for context.

Technical Requirements and Challenges

1. Delegate Selection Interface

The Challenge: We currently lack a frontend interface for delegate selection in our Fractalgram implementations. The original EOS version included this functionality directly in the Telegram client, allowing seamless delegate election at the end of each breakout room. However, neither Tadas's current EVM Fractalgram version nor Abraham's web application includes this critical feature.

Why This Matters: Without an integrated interface, the delegate selection process becomes cumbersome and may be forgotten or skipped by breakout rooms. The smooth user experience is essential for consistent implementation and community adoption.

Previous Solution on EOS: The Telegram bot would prompt each room to select a delegate after rankings were complete, recording the selection directly to the blockchain. This created a seamless experience where delegate selection felt like a natural extension of the Respect Game.

Current Status: As of August 2025, we have confirmed that neither Fractalgram implementation includes delegate selection functionality. This represents our most significant technical barrier to implementation.

2. Smart Contract Recording

The Challenge: We need a reliable on-chain mechanism for recording delegate selections on Base. This ensures transparency, prevents disputes, and enables automated proposal tracking.

Previous Implementation: On EOS, smart contracts automatically recorded delegate selections, tracked active councils, and managed proposal voting. This created a trustless system where results were verifiable by anyone.

Current Infrastructure: We have ORDAO deployed on Base, which could potentially handle delegate tracking through custom actions. However, this hasn't been specifically configured for Eden+Fractal's rolling council structure.

Critical Questions: Can ORDAO's existing infrastructure support delegate tracking? Do we need custom smart contracts? How do we ensure the four-council rotation is properly maintained on-chain?

3. Bi-Weekly Event Adaptation

The Challenge: Eden+Fractal was designed for weekly events, where a four-week commitment meant one month of service. With our current bi-weekly schedule, four events span two months, potentially creating a barrier to participation.

Impact on Participation: Asking delegates to commit for two months may discourage participation, especially from community members with uncertain schedules. This could result in incomplete councils and difficulty reaching quorum for decisions.

Design Considerations: The four-council structure is fundamental to Eden+Fractal's balance between efficiency and democracy. Reducing to two councils would fundamentally alter the consensus mechanism and potentially concentrate power too much. We need to carefully consider whether the longer commitment period is acceptable or if we need alternative solutions.

Proposed Solutions

Immediate Workaround (For Potential August 28th Implementation)

Given our technical constraints, we propose the following interim solution that could enable us to begin using Eden+Fractal while we develop more sophisticated infrastructure:

Delegate Selection Process: After completing the Respect Game rankings in each breakout room, participants will navigate to eden.frapps.xyz and create a Custom Signal proposal. The proposal title would follow the format: "Elect [Delegate Name] from Room [Number] - Event 127". All room members would then vote on this proposal before leaving the breakout room.

Tracking and Verification: We'll maintain the existing Google Spreadsheet as our primary tracking mechanism, with on-chain proposals serving as verification. This creates redundancy and allows for easy community review of active councils.

Commitment Flexibility: While we'll ask delegates to commit to four events (two months), we'll establish clear communication channels for delegates who cannot attend specific events. Written votes submitted via Telegram before Eden Town Hall would be accepted, ensuring decisions can proceed even with some absences.

Long-term Technical Development

Fractalgram Integration: Work with Tadas and Abraham to integrate delegate selection directly into both Fractalgram implementations. This would restore the seamless experience we had on EOS and should be prioritized for development during the season.

Smart Contract Enhancement: Develop dedicated smart contracts or ORDAO modules specifically for Eden+Fractal's requirements. This includes tracking rolling councils, managing delegate terms, and automating proposal state changes.

User Experience Improvements: Create a dedicated interface at edenfractal.com that displays current councils, active proposals, and voting records. This transparency will help community members understand the process and hold delegates accountable.

Updated Specifications

The following draft specifications adapt the original Eden+Fractal design to our current context on Base with bi-weekly events:

Breakout Room Process: Each breakout room continues with the standard Respect Game for approximately 50-55 minutes. In the final 5-10 minutes, the group discusses and reaches consensus on selecting one member as their delegate for that event. The delegate selection should consider both the person's contributions and their availability for the commitment period.

Council Formation and Terms: All delegates elected during a single event form that event's council. Each council remains active for four consecutive events (approximately two months with our bi-weekly schedule). At any given time, Eden Fractal has four active councils, creating a rolling governance structure where new voices continuously enter while experienced delegates provide continuity.

Proposal Process: Any community member can submit proposals for consideration in the Eden Fractal Telegram group. Proposals should be clearly written with specific actions and rationale. During Eden Town Hall (18:00-19:00 UTC) following each Respect Game), active proposals are discussed and voted upon by the councils.

Voting Mechanics: For a council to approve a proposal, at least two-thirds of that council's delegates must vote in favor. For a proposal to pass Eden Fractal's governance process, at least three out of the four active councils must approve it. This creates a high bar for consensus while still enabling decisive action when the community broadly agrees.

Delegate Responsibilities: Delegates are strongly encouraged to attend all Eden Town Hall events during their term, including playing the Respect Game Eden Fractal. They should review all proposals posted in the Telegram group before Eden Town Hall and come prepared to discuss and vote. If unable to attend, delegates should communicate with their council and, when possible, submit their perspective in writing before the meeting.

Benefits and Challenges

Key Benefits of Eden+Fractal

Scalability and Decentralization: Unlike many governance systems that become unwieldy as they grow, Eden+Fractal naturally scales through its fractal structure. As the community grows and more breakout rooms form, the council size increases proportionally, maintaining representation without sacrificing efficiency. This creates truly decentralized governance where power distributes across many delegates rather than concentrating in a small group.

Democratic Legitimacy: The combination of peer election and rolling terms ensures that governance power flows from genuine community support. Delegates earn their position through recognition from their peers in small group settings where everyone's voice is heard. The four-council structure prevents any single faction from dominating decisions.

Efficiency with Safeguards: While enabling quick decision-making during Eden Town Hall, the requirement for supermajority approval from multiple councils prevents hasty or poorly considered proposals from passing. This balance allows Eden Fractal to respond rapidly to opportunities while protecting against governance capture.

Continuous Innovation: The weekly rotation of councils brings fresh perspectives while maintaining institutional knowledge. This creates an environment where new ideas can emerge while successful practices are preserved.

Potential Challenges

Time Commitment Burden: The two-month commitment required from delegates may discourage participation, particularly from community members with variable schedules or other obligations. This could lead to incomplete councils and difficulty achieving quorum.

Technical Complexity: Without integrated tooling, the delegate selection and tracking process adds friction that may confuse new participants or lead to errors in recording selections.

Consensus Speed: If multiple delegates are absent, achieving the required supermajorities becomes difficult, potentially stalling important decisions. The bi-weekly schedule compounds this by extending the time needed to form new councils if existing ones become inactive.

Governance Integration

Eden+Fractal serves as the legislative branch in Eden Fractal's tripartite governance structure, complementing ORDAO (executive) and the Respect Game (judicial). This separation of powers creates checks and balances while enabling each component to excel at its specific function. You can learn more about this governance philosophy in this article on tripartite governance and the recent video discussion from EF 117.

The Respect Game provides the foundational layer by measuring contributions and creating a merit-based reputation system. This ensures that those contributing most to Eden Fractal's mission have proportional influence in governance. ORDAO enables efficient execution of approved proposals through smart contracts, removing the need for trusted intermediaries. Eden+Fractal completes this system by providing democratic decision-making that represents the collective will of active contributors.

This governance integration positions Eden Fractal to pioneer genuinely democratic coordination at scale. By demonstrating that complex communities can make collective decisions efficiently without sacrificing legitimacy, we're creating a model that other communities can adopt and adapt.

Implementation Discussion Questions

As we prepare for implementation, several key questions require community input:

Technical Approach: Should we proceed with the ORDAO Custom Signal workaround for delegate selection, or wait until Fractalgram integration is complete? What are the trade-offs between starting immediately with a less elegant solution versus delaying for better infrastructure?

Commitment Period: Is the two-month commitment (four events) acceptable given our bi-weekly schedule, or should we explore alternatives? Could we implement a proxy system where delegates can temporarily transfer their voting power if unable to attend?

Transition Planning: How do we handle the transition period where we're building up to four active councils? Should we temporarily adjust the approval requirements or wait until we have the full structure in place?

Next Steps

We are currently evaluating whether to launch Eden+Fractal at Event #126 (August 28th) or Event #127 (September 11th). This decision depends primarily on confirming our technical approach with Tadas and ensuring we have clear instructions for the community.

If technical requirements can be met, we'll proceed with implementation on August 28th using the ORDAO workaround described above. Otherwise, we'll use the August 28th event for final preparation and community education, with full implementation beginning September 11th.

Community members interested in the technical development should review this document and provide feedback in the Eden Fractal Telegram group. We particularly need input from those with smart contract expertise and frontend development experience.

This is a living document for technical coordination. Please provide feedback and suggestions in the Eden Fractal Telegram group or comment directly on this Notion page.

‣