Liquid Democracy Implementations Comparison

So, I asked one of these Deep Research models of late to build a comparison table evaluating all the major liquid democracy implementations I found interesting—Pirate Party Germany, Flux, LiquidFriesland, Rotenburg/Wümme, Synaxon, Google Votes, and Partido de la Red—across six axes:

Governance structure
Number of users reached
Support for per-topic delegation
Support for overriding votes
Support for secret ballot (private voting)
Identity verification method

This is what I got, in summarized form:

Implementation	Gov.	Users	Topic	Ovr	Secret	ID
Pirate Party	Party	14K	Yes	Yes	Public	Member
Flux	Party	7K	Yes	Yes	Secret	Electoral
LiquidFriesland	Local	0.5K	Yes	Yes	Public	GovID
Rotenburg/Wümme	Local	Few	Yes	Yes	Public	GovID
Synaxon	Company	300	Yes	Yes	Pseudo	Internal
Google Votes	Company	4.6K	Yes	Yes	Public	Corporate
Partido de la Red	Party	4K/21K	Yes	Yes	?	GovID

Key:

Gov.: Governance context
Users: Approximate active user count
Topic: Supports per-topic delegation
Ovr: Override delegation options available
Secret: Voting is secret (if “Secret”) or open/public
ID: Identity verification method

And in long form:

Comparison of Real-World Liquid Democracy Implementations

Implementation	Governance Context	Users (approx.)	Per-topic Delegation?	Direct Vote Override?	Vote Privacy	Identity Verification
Pirate Party Germany (LiquidFeedback)	Political party (Germany’s Pirate Party) – used internally for member decision-making ¹ ².	~13,800 registered party members on the platform (as of 2015) ¹.	Yes. Delegations could be assigned per issue or by subject area (LiquidFeedback allowed global, area, or issue-specific proxies) ³.	Yes. A member could always vote directly on any issue, overriding or revoking their delegate at any time ⁴.	Public. All votes and delegations were recorded openly (no secret ballot), enabling transparency but sacrificing anonymity ³.	Party membership credentials. Only verified Pirate Party members received accounts; the platform was restricted to party members ².
Flux (Australia) (Issue-Based Direct Democracy)	Political party in Australia (Flux Party) – intended to have citizens influence legislative votes via an app ⁵.	~6,000–8,000 members at peak (e.g. 6,269 members in 2017; ~8,000 by 2019) ⁶ ⁷.	Yes. Delegation was issue-based – voters could delegate their vote on a per-issue basis or trade votes between issues (the core of Flux’s “Issue Based Direct Democracy”) ⁸ ⁹.	Yes. Voters always retained the right to vote directly on any given issue instead of delegating (delegations could be changed or overridden at will) ⁸ ⁴.	Secret ballot. Votes were anonymized for privacy – Flux’s SecureVote system used blockchain with an “oblivious shuffle” so that individual votes could not be linked to voters ¹⁰ ¹¹.	Government voter roll (electoral) verification. Only whitelisted registered voters could use the app – Flux planned to verify users against the official electoral roll, using a third-party or audit log to confirm identity while keeping votes anonymous ¹² ¹⁰.
LiquidFriesland (Friesland, Germany)	Local government platform (district of Friesland) – official e-participation platform for citizens ¹³.	458 total participants (citizens) were active at least once during the initial run (2012–2014) ¹⁴. Participation was only a few hundred users (under 0.5% of the 100,000 population) ¹⁵.	Yes. By design it followed liquid democracy rules: citizens could delegate their vote per issue/topic to a proxy of their choice (implemented via LiquidFeedback) ¹⁶ ¹⁷.	Yes. Users could always opt to vote directly on any issue themselves, even if they had delegated that topic to someone (delegations were optional and could be overridden) ¹⁷ ⁴.	Public (within platform). Votes were visible to participants on the platform (no secret ballot internally), though results were not publicly posted outside. Only authenticated users could view ballots/vote records ¹⁸.	Government ID / residency. Only eligible district residents (age ≥16) could register. Citizens had to request access and receive a personal login code, ensuring one account per person ¹⁹ ²⁰.
Rotenburg/Wümme (Germany)	Local government platform (district of Rotenburg) – “Bürgerplattform ROW” for citizen input (launched 2015) ²¹.	Unknown (no official figures published; likely a few hundred or fewer active users – usage was reportedly very low, with too few proposals to analyze impact) ²².	Yes. Used LiquidFeedback like LiquidFriesland, so issue-based delegation was supported (platform organized by topic areas for delegations) ²³.	Yes. Citizens could always vote on an issue directly themselves; any delegated vote could be superseded by the user’s own vote (standard liquid democracy practice) ¹⁷ ⁴.	Public (within platform). Likely the same model as LiquidFriesland – votes were recorded openly for participants (delegations and votes visible on the platform; not an anonymous ballot) ³.	Government ID / residency. Open to all district citizens 16+ with verification. Users registered via the official website and received a unique code to log in, ensuring one-person-one-account ¹⁹.
Synaxon AG (Germany)	Private company (IT firm Synaxon AG) – used internally for employee participation in corporate decisions ²⁴.	Entire workforce (~250–300 employees) ²⁴ ²⁵. (Synaxon is a large IT franchise company; all employees were invited to use the system.)	Yes. Implemented via LiquidFeedback for all internal proposals, allowing delegations by issue or topic among employees (the full delegative feature set was available) ²⁶.	Yes. Employees could vote on any proposal directly, even if they had delegated votes – delegations were voluntary and could be retracted by voting themselves ⁴.	Pseudonymous (internal). To reduce peer pressure, Synaxon made user identities semi-anonymous on the platform. Employees participated under pseudonyms, so individual votes/ideas weren’t tied to real names publicly ²⁶.	Internal account (employee login). Only company staff could access the system. Each employee got credentials linked to their identity (but displayed as pseudonyms). The company ensured one account per staff member ²⁶.
Google Votes (Google, Inc.)	Private company (Google) – experimental internal liquid democracy system on the corporate Google+ network ²⁷.	Thousands of employees. For example, in one company-wide test ~4,600 Googlers cast ~62,000 votes on a set of decisions ²⁸. (The platform was available to Google staff enterprise-wide.)	Yes. Delegation could be done by category/issue. Google Votes allowed users to delegate votes on specific topics (e.g. Food issues to a colleague, IT issues to another), reflecting per-topic proxy voting ²⁹ ³⁰.	Yes. Users could override their delegates at any time – they retained the ability to vote directly on any issue, even if a delegation was in place ⁴.	Public (within company). Votes were not secret – Google Votes made all votes visible to the voting group (all participating employees could see how votes were cast) ³¹. This transparency aligned with an internal “Golden Rule” of delegative voting.	Corporate login. Only Google employees on the internal Google+ network could participate. Identity was verified via Google’s employee accounts (company SSO); no external sign-up was possible ²⁷.
Partido de la Red (Net Party, Argentina)	Political party (Buenos Aires, Argentina) – “Net Party” platform for citizens to guide an elected legislator’s votes (hybrid of direct and representative democracy) ³².	Several thousands of users. ~4,000 citizens signed up to found the party in 2013, and the party drew ~21,000 public votes in the 2013 election ³³ ³⁴. (The online platform aimed to engage a broad segment of the city’s residents.)	Yes. Delegation was a core feature: the DemocracyOS-based system let each user either vote on an issue or delegate their vote to a trusted peer, with topic-by-topic specificity (e.g. delegate health issues to one person, economic issues to another) ³⁵ ³⁵.	Yes. Users were free to vote directly on any bill/proposal; a delegated vote could be overridden by the user’s own vote on that issue (delegation was optional per issue) ³⁵.	Unknown. (Not explicitly documented. The platform’s designers emphasized secure identity separation – via the NetIdentity system – so it’s likely individual votes were private or anonymized, but specific details of vote visibility are not publicly confirmed.)	Government ID via NetIdentity. Strong identity validation was required since the online votes were tied to an elected official’s mandate. Users had to verify their real identity (e.g. with official ID) through a separate app called “NetID,” ensuring that each online participant was a unique eligible citizen ³⁶.

Notes: The above implementations all embody liquid democracy principles but in different contexts. For instance, the Pirate Party and Net Party platforms were tied to political organizations and had binding or influential outcomes on policy, whereas Google Votes and Synaxon’s system were internal and consultative. Notably, vote privacy policies varied: some platforms (e.g. Pirate Party, LiquidFriesland) favored transparency by making votes public to participants ³, while others (Flux, Net Party) prioritized secret ballots to mirror official democratic norms ¹⁰. Low participation was a challenge in the local government cases (Friesland, Rotenburg) ¹⁵ ²², whereas the Pirate Party’s and Google’s implementations reached larger user bases. Identity verification ranged from formal (government-issued ID or electoral roll checks) to informal (internal account authentication), reflecting the trust requirements of each setting. Each case offers lessons about the trade-offs between transparency, security, and usability in liquid democracy systems.

Footnotes