The Town Hall That Runs on Code: How a Kansas Co-op Rebuilt Its Governance on Big Red's Network

The monthly town hall used to be the heart of the cooperative. Members gathered in the basement of a converted church, sipping coffee from stained mugs, arguing about roof repairs and parking allocations. But over time, attendance dwindled. Bylaws grew thick and contradictory. Motions were forgotten between meetings. Trust eroded. When the board of a 120-unit housing co-op in rural Kansas reached a breaking point—a recall vote nearly failed because only 14 members showed up—they knew something had to change. They didn't just want a digital bulletin board. They wanted a governance system that ran on rules, not personalities. That's when they turned to Big Red's network.

Why This Topic Matters Now

Community governance is at a crossroads. Traditional models—town halls, boards, committees—were designed for a world where everyone could show up in person and decisions moved slowly. That world still exists, but it's under strain. Membership turnover, remote work, and information overload make it harder to maintain quorum, track proposals, and enforce rules consistently. Many communities are adopting digital tools, but most are just digitizing the same broken processes: PDF agendas, email voting, and Slack debates that never resolve.

The Kansas co-op's story is not unique. Across the country, housing cooperatives, homeowners associations, and even small nonprofits are exploring code-based governance—where decisions are automated through smart contracts, proposals are tracked on an immutable ledger, and voting is transparent and verifiable. Big Red's network provides a platform for this shift, but the real innovation is in the model itself. By encoding governance rules, communities can reduce administrative overhead, increase participation, and rebuild trust.

This article is for anyone involved in running a community—board members, property managers, co-op owners, or DAO contributors—who wants to understand how code can support, not replace, human deliberation. We'll use the Kansas co-op as a composite example, drawing on common patterns we've observed across multiple communities. You'll learn what a code-based town hall looks like, how to implement one, and where the approach still falls short.

The trust problem in traditional governance

Most governance breakdowns are not about malice; they're about ambiguity. When bylaws are open to interpretation, when vote counts are disputed, when proposals disappear into committee black holes, members lose faith. The Kansas co-op had a three-inch binder of rules, but nobody agreed on what they meant. A simple question—"Can we use reserve funds for landscaping?"—could spark a month-long debate. Code removes that ambiguity. Rules become executable logic. If the rule says "reserve funds require a two-thirds majority," the system enforces that automatically.

Why Big Red's network fits

Big Red's platform is built for communities, not corporations. It offers modular governance components—proposal creation, voting with weighted ballots, role-based permissions, and audit trails—that can be configured without writing code from scratch. For the Kansas co-op, this meant they could start with a simple digital vote on a single issue and expand over time. The network's emphasis on transparency (all actions are logged and visible to members) aligned with their goal of rebuilding trust.

Core Idea in Plain Language

At its simplest, a code-based town hall replaces discretionary human processes with automated, rule-bound workflows. Instead of a board president deciding whether a motion is in order, the system checks the proposal against encoded bylaws. Instead of counting paper ballots by hand, votes are tallied instantly and immutably. The core idea is this: governance can be expressed as a set of conditional rules, and those rules can be executed by software.

Think of it like a traffic light. Traffic lights don't eliminate the need for drivers—they just enforce a consistent rule (red means stop, green means go) that everyone agrees on. A code-based town hall works the same way. Members still propose ideas, debate them, and vote. But the system handles the mechanics: verifying eligibility, enforcing timing, applying weights, and recording outcomes. This frees people to focus on the substance of decisions, not the process.

The three pillars of code-based governance

Most implementations rest on three mechanisms:

• Proposal lifecycle: A structured pipeline from draft to decision. Each step (submission, discussion, voting, execution) has clear rules about who can act and when.
• Smart contracts for voting: Rules about quorum, majority thresholds, and tiebreakers are encoded. Votes are cast on-chain or on a trusted ledger, making them tamper-proof.
• Role-based permissions: Not everyone has the same authority. Members, board members, committees, and administrators have different abilities—encoded in the system.

The Kansas co-op started with just the first two. They created a digital proposal form that automatically checked whether the submitter was a member in good standing. If the proposal met basic criteria (e.g., it wasn't already being discussed), it entered a 7-day discussion period, followed by a 3-day vote. The system enforced quorum: if fewer than 30% of members voted, the proposal failed automatically.

Why this is different from email voting

Many communities already use email or survey tools to vote. The difference is automation and enforcement. In an email vote, someone has to manually count responses, check membership status, and decide whether a late ballot counts. With code, all of that is handled automatically. More importantly, the rules are transparent and immutable. No one can claim the count was wrong or that a proposal was never submitted.

How It Works Under the Hood

To understand how a code-based town hall functions, let's look at the components Big Red's network provides and how the Kansas co-op configured them. The system is modular, so communities can choose which modules to activate.

Member identity and verification

Every member has a digital identity tied to their membership status. In the Kansas co-op, this was a simple username and password, verified against the co-op's membership roster. For communities that want stronger assurance, Big Red supports multi-factor authentication and, for DAOs, wallet-based identity. The key is that the system knows exactly who is eligible to vote and what their voting weight is (e.g., one member, one vote, or proportional to shares).

Proposal creation and routing

When a member submits a proposal, the system checks it against pre-defined rules: Is the member in good standing? Does the proposal fall within the community's scope? Has a similar proposal been rejected in the last 90 days? If the proposal passes these checks, it's routed to the appropriate discussion channel. The Kansas co-op used a dedicated forum within Big Red's platform, but the system can also integrate with existing tools like Discord or email lists.

Discussion and amendment

During the discussion period, members can comment and propose amendments. The system tracks each version of the proposal. When the voting period begins, the final version is locked. This prevents the common problem of last-minute changes that confuse voters. The Kansas co-op set a 7-day discussion period, which they found was long enough for thoughtful debate but short enough to maintain momentum.

Voting mechanics

Voting can be simple or complex. The Kansas co-op used a straightforward yes/no/abstain ballot with a simple majority threshold (50%+1 of votes cast) and a quorum of 30% of total membership. The system automatically calculates the result and publishes it. For weighted votes (e.g., based on share ownership), the system applies the weights. All votes are recorded on an immutable ledger, so anyone can verify the outcome independently.

Execution and enforcement

Once a proposal passes, the system can automatically execute some actions (e.g., updating a document, releasing funds from a smart contract) or generate a task for a human administrator. The Kansas co-op chose a hybrid model: the system notified the board of the result, and the board executed the decision (e.g., ordering the new roof). Over time, they plan to automate more execution steps.

Worked Example or Walkthrough

Let's walk through a concrete decision the Kansas co-op made using their new system: approving a special assessment to replace the community's aging boiler system.

Step 1: Proposal submission

Jane, a member of the co-op's maintenance committee, drafts a proposal on Big Red's platform. She specifies the amount ($15,000), the reason (the boiler is over 20 years old and failing), and the proposed timeline (installation in June). The system checks her membership status and confirms she is eligible to submit. It also checks that no similar proposal is currently under discussion.

Step 2: Discussion period

The proposal enters a 7-day discussion phase. Jane posts a detailed cost breakdown. Other members ask questions: "Can we get a second quote?" "What happens if we don't do it now?" The system tracks all comments. After three days, a member proposes an amendment: increase the amount to $18,000 to also replace the water heater. Jane accepts the amendment, and the system updates the proposal text.

Step 3: Voting

After 7 days, the proposal moves to voting. All 120 members receive a notification (email and in-app). Voting lasts 72 hours. The system shows the current tally in real-time but does not reveal individual votes until the end to avoid bandwagon effects. At the close, 45 members have voted—exceeding the 30% quorum (36 members). The result: 38 yes, 5 no, 2 abstain. The proposal passes with 88% approval.

Step 4: Execution

The system generates a formal record of the vote and sends it to the board. The board treasurer initiates the special assessment, and the boiler replacement is scheduled. The entire process, from submission to execution, takes 10 days—compared to the 2–3 months it would have taken under the old town hall model.

What made it work

Several factors contributed to the success: clear rules set in advance, a reasonable quorum threshold, and the ability to amend during discussion. The system also reduced friction—members could vote from their phones without attending a meeting. The co-op saw participation jump from 12% (in-person) to 38% (digital) for this vote.

Edge Cases and Exceptions

Code-based governance is not a silver bullet. The Kansas co-op encountered several edge cases that required human judgment.

Emergency decisions

When a pipe burst in the middle of the night, the co-op couldn't wait 10 days for a vote. They designated a small emergency committee with authority to spend up to $5,000 without a full vote, with the requirement to report back within 48 hours. The system allowed them to create an "emergency override" role that could bypass the normal proposal flow, but every override was logged and automatically triggered a review vote within 7 days.

Absentee and disengaged members

Even with digital voting, about 30% of members never participated. This raised concerns about legitimacy. The co-op experimented with "silent consent" rules: if a member didn't vote, their non-vote counted as abstaining (lowering the threshold, since abstentions don't count toward the majority). However, some members felt this was unfair. The co-op eventually settled on a rule that non-votes are simply not counted, but a proposal fails if quorum isn't met. This encourages participation without penalizing disengagement.

Disputed outcomes

What if a member claims the system was hacked or the vote was rigged? Big Red's network provides a full audit log, but the co-op also appointed a human "governance steward" who could investigate disputes. In one case, a member claimed their vote wasn't recorded. The audit log showed they had not completed the voting process (they clicked the link but didn't confirm). The steward explained the issue, and the member accepted it. The system's transparency actually reduced distrust, because every action was traceable.

Proposal spam

In theory, any member could submit unlimited proposals. The Kansas co-op implemented a "proposal fee" (a small deposit that was refunded if the proposal passed or reached a certain number of co-sponsors). This reduced frivolous proposals from 12 per month to 2 per month.

Limits of the Approach

Despite its successes, the code-based town hall has real limitations. Communities should consider these before adopting the model.

Digital divide

Not all members are comfortable with technology. The Kansas co-op had several elderly members who struggled with the digital platform. They provided paper ballots as a fallback (which were manually entered into the system by a board member), but this required extra effort. The co-op also held monthly "digital office hours" where members could get help. Still, about 5% of members never engaged digitally, raising questions about inclusion.

Over-automation

There is a risk of automating away human judgment. Some decisions require nuance that code cannot capture. For example, a proposal to evict a member for non-payment might need a hearing, not just a vote. The Kansas co-op kept certain decisions (e.g., membership termination, bylaw amendments) in the human realm, requiring a physical meeting with a two-thirds vote. They learned to draw a line between operational decisions (suitable for code) and constitutional decisions (requiring human deliberation).

Technical lock-in

Once a community's governance is encoded in a platform, switching to another system is difficult. The Kansas co-op chose Big Red's network because it offers data export and a standard proposal format, but they are aware that migrating to a different platform would require re-encoding all rules. They mitigate this by keeping their bylaws in plain text alongside the code, so the rules are not solely dependent on the platform.

Cost and maintenance

While Big Red's basic tier is free for small communities, larger co-ops or those needing custom features pay a subscription. The Kansas co-op pays $50/month for their plan, which they consider reasonable. However, they also invested time in training board members and troubleshooting issues. The system is not maintenance-free.

Reader FAQ

Do we need to know how to code to use Big Red's network?

No. The platform provides a visual interface for configuring rules—like setting quorum thresholds or defining proposal stages. No programming required. For advanced customization, Big Red offers templates and support.

How do we ensure the votes are secure?

Big Red uses encryption and an immutable audit log. Each vote is timestamped and linked to the voter's identity. The system also supports two-factor authentication. For communities that want blockchain-level security, Big Red can integrate with public ledgers, though most small communities find the standard security sufficient.

What if a majority of members refuse to use the system?

Adoption is the biggest challenge. The Kansas co-op started with a single non-binding vote to build trust. They also held a hybrid meeting where members could vote in person or online. Over six months, digital participation grew from 15% to 38%. Forcing everyone to use the system from day one likely would have caused backlash.

Can we keep our existing bylaws and just add the digital layer?

Yes. The platform is designed to complement, not replace, existing governance documents. You encode the rules that make sense to automate (voting, proposal submission) and leave others (like hearing procedures) in human hands. The Kansas co-op did a full audit of their bylaws and identified 60% of rules that could be encoded without conflict.

How do we handle conflicts of interest?

Members can flag potential conflicts before a vote. The system can then exclude the conflicted member's vote or require them to abstain. The Kansas co-op also requires board members to disclose conflicts in the proposal discussion thread.

What happens if the platform goes down during a vote?

Big Red has a 99.9% uptime SLA for paid plans. In case of an outage, the vote is paused and extended by the duration of the outage. The system automatically notifies members. The co-op also has a fallback: if the platform is down for more than 24 hours, they can extend the voting period manually via an admin override, which is logged.

Can we customize voting weights (e.g., based on tenure or share ownership)?

Yes. Big Red supports weighted voting. The Kansas co-op uses one-member-one-vote, but other communities on the network use share-based weighting. The system can also apply different weights for different proposal types (e.g., financial proposals require a higher threshold).

To get started, the Kansas co-op recommends three steps: (1) audit your current bylaws and identify decisions that are routine and rule-bound, (2) run a pilot vote on a low-stakes issue using the digital platform alongside your existing process, and (3) review the results with your community and iterate. Code can't replace community, but it can give the town hall a backbone it never had.