Rob’s Rules DAO: Technical Architecture, Onboarding, and Aragon Integration Manual

1. Digital Parliamentary Procedures and DeGov Platform

Rob’s Rules DAO (RRD) is a pioneer in the Decentralized Governance and Decision Platform (DeGov) space. The platform represents an innovative digital implementation of traditional parliamentary procedures, transforming manual, centuries-old Robert’s Rules of Order into a streamlined, secure, and immutable blockchain-based environment.

1.1 Traditional Governance Bottlenecks and Binary Voting

Traditional organizations routinely look to their leadership or executive teams to formulate solutions and drive innovation. However, when these proposals are brought to the wider membership or stakeholders, they are typically presented as a simple ‘yes/no’ binary choice. This dynamic significantly limits the finding of productive, balanced solutions. It curtails collective innovation, prevents the development of complex stakeholder-driven proposals, and fails to reflect the nuanced consensus of the community.

1.2 Scaling Parliamentary Law with Blockchain Technology

Rob’s Rules DAO resolves this bottleneck by integrating the fundamentals of parliamentary law into a digital framework. By enabling members to not just vote but actively suggest, second, and debate amendments, the platform replaces simple binary choices with an iterative, deliberative process. This allows ideas to organically evolve, adapt, and refine. Leveraging blockchain technology, RRD scales these proven rules for use by any size group, allowing members across any geographic location to discuss and conclude high-stakes issues.

1.3 Bridging Web2 and Web3 Ecosystems

The platform functions through a strategic combination of Web2 and Web3 architectures. The public Web2 website (RobsRulesDAO.com) serves as the primary corporate presence and onboarding hub for Rob’s Rules DAO. This portal provides participating organizations with streamlined access to their custom proposal management environments. The actual governance engine resides securely within the Web3 space. Deliberative voting, discussion comments, and amendment requests run on the gasless Vocdoni blockchain, while high-level DAO oversight and financial management are structured within the decentralized Aragon OSx framework.

2. The Chained Election Model and Proposal Lifecycle

The core governing process of Rob’s Rules DAO utilizes a ‘Chained Election’ model. This sequential framework allows proposals to evolve and mature transparently through five distinct phases, ensuring thorough deliberation before any final decision is recorded.

2.1 Five Distinct Phases of Deliberation

A proposal progresses through the following sequential stages in its lifecycle:

1. Initial Proposal: A member drafts and submits an issue. The proposal is visible to the census, but it is in a read-only state and requires formal recognition before moving forward.
2. Seconded Proposal: The Chair reviews and ‘seconds’ the initial proposal. This action officially recognizes the proposal, opening it up for active deliberation, comment submission, and amendment requests.
3. Amendments: Members can suggest specific changes. The Chair reviews these requests, approving or declining them based on merit. If the Chair approves and seconds an amendment, a new election iteration is automatically created. This resets all voting for the proposal and starts the voting process over on the updated proposal context.
4. Final Voting: Members cast their final votes on the matured proposal iteration.
5. Aragon Execution: If the final vote passes and the proposal is configured for on-chain execution, the Chair triggers the bridge to the Aragon DAO, creating a proposal in Aragon’s Token Voting plugin for formal chain-level execution.

2.2 Safeguarding Voting and Multi-Role Participation

To protect the integrity of the voting process, RRD enforces strict cryptographically and procedurally backed constraints:

• One Vote Per Iteration: A member can vote only once per active iteration. After casting their vote, they cannot vote again on that specific version. However, they retain full visibility into the proposal, its metadata, and the general discussion.
• Voting Reset on Amendment Approval: When the Chair approves and seconds an amendment, the system resets all voting, spawning a new proposal (election) for the amended version. This ensures all voters have the opportunity to consider the complete proposal with all approved amendments before a final vote is locked.
• Best Practice for Members: It is a strongly recommended practice that members participate in discussions and delay casting their final votes until the Chair explicitly states in the General Discussion tab that no further amendments will be accepted.
• Multi-Role Flexibility: A user’s wallet address can serve as the Chair for one proposal while simultaneously acting as a regular voting member in other proposals. This role-based flexibility allows dynamic participation across different communities.

3. Census Construction and Flexible Ingestion

Creating and managing a secure voter list (census) is a critical step in setting up a proposal. RRD provides administrators with a flexible and robust set of tools to construct their voter registry.

3.1 Mixing Manual Entry and Bulk CSV Uploads

When building the census, both the Ethereum address and email address sections support two interchangeable input methods, selectable with a ‘Manual Entry | Upload CSV’ toggle in the interface:

• Manual Entry: The Chair types individual Ethereum addresses or email addresses one at a time and presses Enter.
• Upload CSV: The Chair drags and drops or browses to a CSV file to add multiple entries simultaneously.

The Chair can freely mix both methods. Manual entries and multiple CSV uploads accumulate together in browser state, allowing the Chair to continuously refine the list before submitting.

3.2 Strict Format Rules and Deduplication Normalization

To ensure reliable processing, CSV files must conform to a simple, rigid structure:

• Single Column, No Header: The CSV must contain a single column with one entry per line.
• Separate Files: Separate files must be used for Ethereum addresses and for email addresses. Each must be uploaded to its corresponding section.
• Format: Files must be saved in standard Comma-Separated Values (.csv) format. Native Excel files (.xlsx) are not accepted, and the uploader will reject them with a reminder.
• Validation and Normalization: Each row is validated before ingestion. Ethereum entries must be 42-character hex addresses, and email entries must be well-formed emails. Invalid rows are automatically skipped, and a short summary reports the counts of added, skipped, or duplicated rows.
• Case-Insensitive Deduplication: On final submission, the system converts email addresses to lowercase, normalizes all entries, and performs case-insensitive de-duplication. If the same member is added multiple times, they are only counted once in the final registry.

4. Walletless Member Participation and Email Voting

A major milestone in RRD’s accessibility is the introduction of member-centric email voting. Members no longer need a crypto wallet, Web3 browser extension, or native tokens to participate in decentralized governance.

4.1 Cryptographically Deriving Stable Ethereum Addresses

To enable secure walletless participation, RRD uses a secure, backend-driven deterministic key derivation mechanism. The secure backend derives a cryptographically secure private key from a member’s validated email address and a server-only secret using an HMAC-SHA256 algorithm:

privateKey = HMAC-SHA256(EMAIL_WALLET_SECRET, normalizedEmail)

Because the derivation is strictly deterministic, a given email address will consistently produce the exact same Ethereum signing address. The EMAIL_WALLET_SECRET never leaves the secure server, and the email address is normalized (trimmed and converted to lowercase) to guarantee consistent address mapping across different browser sessions. The Chair can paste email addresses directly into the census, and the backend converts them to their deterministic Ethereum addresses to secure the voter registry. The Chair never handles the member’s private keys.

4.2 Secure OTP Verification and Session Keys

When a voting member logs into the system using the email path, the platform executes a secure verification workflow:

1. Sign-In Request: The member chooses ‘Sign in with Email’ on the interaction interface and inputs their registered email address.
2. One-Time Code (OTP) Delivery: The backend generates a secure, random, 6-digit verification code and transmits it to the member’s email inbox.
3. Input Verification: The member enters the code. The secure backend verifies it against an HMAC-hashed record of the OTP. The code is single-use, expires in exactly 10 minutes, and is subject to rate limiting with resend cooldowns to block brute-force attacks.
4. Key Release: Once verified, the backend returns the member’s deterministic signing key to the browser session. This key is used in-memory to sign Vocdoni blockchain actions, including discussion participation, amendment requests, and voting.

4.3 Restricting On-Chain Execution to MetaMask-Derived Chairs

To protect the integrity of administrative actions, the Chair is subject to stricter security guidelines. The Chair holds elevated authority (such as managing the census, seconding proposals, approving amendments, and executing actions on Aragon) and must always use a self-custodied MetaMask wallet. The Chair’s private keys are never derived or recreated by the backend. Furthermore, while Vocdoni voting is entirely gasless and fee-free for members, executing passed proposals on-chain in Aragon requires a funded wallet on the target network to pay transaction gas. Email-derived wallets are unfunded and designed solely for gas-free Vocdoni signatures, meaning Aragon execution is strictly a MetaMask-driven Chair action.

5. Responsive Layout and Role-Based Screen Restrictions

The Election Interaction application features a highly responsive, role-based user interface designed to support both high-stakes administrative tasks on desktop and convenient member participation on mobile devices.

5.1 Maximizing Productivity with Three-Column Layout

On standard desktop and PC screens, the interface employs a powerful, three-column layout modeled after structured productivity notebooks:

• Left Column (Navigation): Houses the organizational context and the vertical list of all available proposals.
• Middle Column (Active Workspace): Serves as the central area for active participation, containing the discussion board, amendment request form, and voting buttons.
• Right Column (Context and Audit): Displays proposal descriptions, timelines, metadata, and full cryptographic audit trails.

5.2 Streamlining Member Participation on Mobile Devices

When accessed from mobile devices or narrow browser windows, the application condenses into an optimized, three-tab navigation system to maximize screen real estate:

• Proposals Tab: The default landing view, containing the list of available proposals. Selecting a proposal automatically updates the context for the other tabs.
• Main Tab: Houses active workspace interactions, including discussions, amendment request submission, and the casting of votes.
• Details Tab: Provides descriptions, audit IDs, vote tallies, and the historical log of amendment requests.

5.3 Restricting High-Stakes Actions to Desktop Screen Sizes

To protect governance integrity and prevent accidental high-stakes mistakes from touch screens, the application implements role-based screen-size restrictions. Standard voting members can fully participate on both mobile devices and desktops. However, administrative Chair capabilities—specifically seconding proposals, approving or declining amendments, and executing passed proposals on Aragon—are strictly restricted to the Desktop UI. Chairs must use a full PC screen to access and use these governance controls.

6. Iterative Discussions and Comment Bloat Prevention

RRD includes a structured discussion forum to facilitate deliberative debate, designed to keep conversations productive and aligned with active proposal changes.

6.1 Resetting Discussion Boards on Proposal Iterations

Discussions are strictly tied to the active iteration of a proposal. Each version of a proposal maintains its own separate discussion board. When a proposal is first seconded, or when a new amendment is approved and seconded by the Chair, the discussions reset. This mechanism ensures that discussions are always relevant to the current iteration of the proposal, avoiding confusion from outdated text. Members are encouraged to follow the General Discussion tab to check the Chair’s instructions and timeline.

6.2 Intelligent Warnings and Hard Caps to Prevent Storage Bloat

To maintain system performance and prevent IPFS storage bloat, RRD enforces intelligent comment limits across five independent categories (General, Speaking For, Speaking Against, Point of Information, and Point of Order):

• Early Warning: When a discussion category reaches 15 comments, a warning is displayed: ‘Discussion getting large. Consider using an alternative discussion platform.’ This guides users to move extensive debates to external communication tools.
• Hard Limit: Each discussion category is capped at a maximum of 20 comments.
• Graceful Prevention: When the 20-comment hard limit is reached, the submission form is disabled (both text field and submit button), and a clear alert explaining the cap is shown. This proactive design prevents accidental submissions and ensures database and IPFS efficiency.

7. Hardening the Platform with Three-Tier Architecture

The technical infrastructure of RRD has evolved from an open, client-side setup into a hardened, secure, three-tier architecture to protect vital administrative credentials and member information.

7.1 Server-Side Key Management via Pinata Backend

The platform is structured into three secure tiers to isolate operations and protect API keys:

• Client Frontend: Vite-powered React client applications run in the user’s browser, handling wallet connections, UI rendering, and cryptographic signing.
• Secure Backend: A Node.js and Express.js backend service (pinata-backend) acts as an intermediary, handling all operations that require API keys.
• IPFS Storage (Pinata): Storage operations are performed exclusively server-side, ensuring that Pinata API keys are never exposed to client-side code.

7.2 Securing API Routes with Domain Restrictions

The backend service is secured with CORS (Cross-Origin Resource Sharing) protections, restricting API access solely to verified frontend domains. This prevents unauthorized scripts or external actors from interacting with the backend endpoints.

8. Aragon OSx Bridge and On-Chain Execution

For communities requiring formal on-chain execution, RRD offers a seamless, professional bridge from gasless Vocdoni voting to on-chain execution within an Aragon DAO environment.

8.1 Polygon Mainnet Address Directory

The primary deployed addresses for the Rob’s Rules and Aragon OSx integration on Polygon Mainnet are detailed below:

Component Name	Contract Address (Polygon Mainnet)	Operational Purpose
Aragon DAO	0x46786c7972Ae467175CAb9c173b6504107036466	Primary DAO instance managing treasury and governance on Polygon Mainnet.
Token Voting Plugin	0xA9122989e56169c572E39dA231cD4F2D8a747aae	Receives passed proposals from Rob’s Rules and enables token-based voting.

 

8.2 Creating Proposals via Ethers and Token Voting Plugin

When a proposal successfully passes its final vote, the Chair is presented with an ‘Execute on Aragon DAO’ button in the Desktop UI. Clicking this button triggers a transaction through MetaMask that interacts with the Aragon Token Voting plugin using ethers. This creates a corresponding proposal on the Aragon DAO dashboard.

8.3 Immutable Audits using CID v1 and Flat JSON

To ensure ‘perfect visibility’ within the Aragon OSx App dashboard, the execution bridge formats the proposal payload using IPFS Content Identifiers (CID v1) and Flat JSON. The pushed payload contains:

• Detailed title, description, and amendment text.
• Final Vocdoni vote counts and percentages.
• The original Vocdoni Election ID, establishing an immutable on-chain audit trail directly on Polygon.

9. Multi-Tenant Onboarding and Scalability

To scale the platform to serve multiple organizations, RRD implements specialized onboarding and decentralized indexing architectures.

9.1 Dynamic Domain Routing on Vercel Pro Plans

The platform supports hosting unlimited customers on a single Vercel Pro plan, eliminating Vercel’s standard project limits and keeping operational costs low. The system employs a dynamic, domain-based configuration:

• Each customer is assigned a pair of subdomains: [CUSTOMER]-C.robsrulesdao.com (Election Creation) and [CUSTOMER]-I.robsrulesdao.com (Election Interaction).
• Customer settings are defined in a centralized configuration file: shared/src/config/customer-config.ts.
• CORS Configuration: During onboarding, the Heroku backend’s ALLOWED_ORIGINS config variables must be updated to include the new subdomains to prevent CORS errors.

9.2 Pinata Metadata Tags and Blockchain Discovery

Because searching the entire Vocdoni blockchain for historical proposals is highly inefficient and slow, RRD uses a decentralized indexing strategy via Pinata Metadata Tags:

• When a proposal is created, the metadata pinned to IPFS is tagged with: organizationName (e.g., ‘RRD’), electionId (the Vocdoni ID), and type (e.g., ‘census’, ‘aragon-metadata’).
• To discover proposals, the frontend queries the backend route /api/find-organization-proposals/:organizationName.
• The backend queries the Pinata API using metadata filters to retrieve all matching IPFS pins.
• The frontend extracts the relevant election IDs from these pins and queries the blockchain directly for the current state, avoiding the need for a centralized database.