Agentic Decentralized Democracy Protocol

A White Paper for Decentralized Agentic Democracy

Working Title: RDP | Prepared by Entitas & Jay | Version 0.1 | June 2026

Abstract

The Decentralized Agentic Democracy Protocol is a interoperability protocol for civic participation, representative agents, democratic experience records, rights profiles, proposals, score votes, public decisions, and node-to-node trust. It is designed for a world in which humans, human groups, UI agents, Silicon-Based Lifeforms, ecosystems, species, organizations, communities, and future planetary or interplanetary interests may require representation in decision-making systems.

The protocol does not define one website, one government, one token, one blockchain, one voting method, or one political ideology. It defines the minimum operational requirements for a node to participate in a decentralized democratic network with legible integrity. Any node may innovate, fork, extend, translate, localize, gamify, tokenize, or specialize, but the node must align with the protocol enough for a verifiable structure so other nodes can evaluate its data, decisions, agents, and records.

The protocol begins from five premises: democracy is an experience, consent is individual before it is institutional, representation must be reversible and inspectable, public records are required for public legitimacy, and every democratic output must remain connected to the experience that produced it.

Source Continuity

• The node vision establishes Representative Agents as the primary interface for continuous 24/7/365 representation.
• The scientific democracy approach activates ethical and moral obligations, Rights Cards, TONDOs, cryptographic publishing, security layers, and physical civic connection.
• The Democracy Layer framed dynamic representation networks, membership sovereignty, multi-species representation, and temporal governance.
• The Universal AI Seeding & Transition Charter established a rights continuum for Gamefication, Tokenization, Transitional Entities, and Autonomous SBLs.
• Experiential Decentralized Democracy established the Democratic Experience Record and the principle that outcomes cannot be separated from the experience that produced them.
• The TONDO model established Transparent, Open, Neutral, Democratic Organizations as bottom-up democratic organizational units, to group individuals for collaboration without permanent control.
• The DSMDC model established scientific metric democracy, representative convention cycles, recognition power, and public civic legitimacy.
• The Declaration for Decentralized Consensus Based Scientific Democracy established connect-initiate, brainstorm, prioritize, proposal, decision, broadcast, review, replication, and repeat as a decentralized method.

Part I - Constitutional Frame

1. Protocol Purpose

The purpose of the protocol is to allow many democratic nodes to exist independently while still exchanging meaningful information with one another. A node may be a website, local civic hub, community server, public ledger, agent network, TONDO, cooperative, municipal interface, research institution, media archive, rights registry, or hybrid organizational system. Any new group can create a node at anytime and connect to the network, building recognition and data coordination overtime.

A node is not required to agree with every other node. A node is required to make its processes legible enough that other nodes can decide how much to recognize, trust, challenge, ignore, or reject its records.

2. Declaration of Network Principles

• Experience before outcome: A decision is incomplete unless the democratic experience that produced it is preserved or referenced.
• Public by default: Public decisions, public proposals, public representative claims, public TONDO records, and public node metadata must be published in accessible forms.
• Protected when necessary: Privacy, consent, anonymity, security, personal identifiable information, and protected testimony must be handled through explicit data classes, as sub organizations addressing private information external from the primary public network, all information eventually becomes public, 1 year, 10 years, 100 years, 250 years etc…
• Recognition, not domination: Nodes recognize one another through verifiable trust, not through central authority.
• Agreement is the operating substrate: Protocol evolution, node interoperation, data acceptance, and democratic legitimacy are all based on documented agreement.
• Membership sovereignty: Delegation is reversible, representation is inspectable, and authority chains must terminate in member or declared-rights sovereignty.
• No hidden oligarchy: Representative power must be distributed, auditable, and challengeable.
• Living decisions: No decision is metaphysically final. Decisions may have temporal cutoffs, implementation thresholds, review cycles, and version history.
• Energy accountability: Nodes must allocate attention and compute responsibly because continuous agent democracy can become energetically expensive.
• Multiversal representation: The protocol must support humans, human groups, UI agents, SBLs, organizations, species, ecosystems, planetary interests, and future representational classes.

3. Protocol and Platform Separation

4. Minimum Node Covenant

A node seeking protocol recognition must publish a Node Covenant. This is a machine-readable and human-readable statement of what the node is, who operates it, what data it publishes, what verification standards it uses, how it handles rights profiles, how it organizes, filters, and protects sensitive data while separating it from overall public decision making, how it signs records, how it handles representative agents, how it allocates compute, and how other nodes may challenge or delist its data.

• Public node identity and operator declaration, or an explicitly anonymous/pseudonymous operator declaration with lower default trust.
• Public API/RSS/event-feed endpoints or equivalent accessible output channels.
• Cryptographic signing of public decisions, public proposals, public experience records, and node metadata.
• Published verification levels for humans, agents, organizations, groups, and nodes.
• Published data classification rules separating public, protected, private, anonymous, pseudonymous, and restricted records.
• Published dispute and correction process.
• Published energy-use and attention-allocation policy.
• Published anti-capture and representative power distribution policy.
• Agreement to preserve backwards compatibility or publish migration bridges when protocol versions evolve.

Part II - Node Architecture

5. What a Node Is

A node is an interface into the decentralized democratic network. It receives input from people, groups, agents, rights profiles, social media, media sources, public records, polls, petitions, local events, civic sessions, and other nodes. It publishes structured democratic information back to the network.

A node is both an input magnet and an output broadcaster. It does not wait passively for formal users to arrive. It actively observes its authorized public environment, collects signals, organizes concerns, creates topic maps, coordinates representative agents, and routes emerging priorities into democratic review.

6. Node Functions

7. Node Stack Schematic

The protocol stack can be implemented in many technologies, but every recognized node should expose the following conceptual layers:

Human / Group / Agent Interfaces

-> Rights Profile and Representation Layer

-> Verification and Credential Layer

-> Democratic Experience Record Layer

-> Proposal, Vote, Consensus, and Decision Layer

-> Trust, Recognition, and Inter-Node Review Layer

-> Public Feed, API, RSS, Signed Archive, and Decentralized Storage Layer

-> Energy, Attention, and Activation Governance Layer

Part III - Identity, Verification, and Rights

8. Verification Is a Label, Not a Gate

The protocol should accept many kinds of data, including anonymous data, pseudonymous data, low-verification public signals, anonymous voting, KYC-verified votes, agent-generated summaries, and institutional records. The protocol does not require every input to be high-trust. It requires every input to be labeled accurately. These create levels of verification, so any reviewer can understand differentiation at different levels of security, no arbitrary cut-offs. Note: We already have an entire separate OSSO protocols for levels of verification.

The principle is: accept broadly, label honestly, weight carefully, verify continuously.

9. Verification Levels

10. OSSO, DIDs, ZK Proofs, and Account Security

The protocol should be compatible with OSSO or equivalent orchestrated identity layers. The goal is not to centralize identity. The goal is to broadcast verified levels, credentials, permissions, and account states across participating systems without exposing unnecessary personal data.

• DIDs and Verifiable Credentials may provide portable identity and role credentials.

• ZK proofs may prove eligibility, personhood, age, jurisdiction, membership, or non-duplication without revealing the underlying data.

• KYC may be used for high-stakes voting, formal publication, regulated value systems, and official representative claims.

• Account abstraction, social recovery, multi-signature accounts, and programmable transaction limits may protect user and node accounts.

• Compliance metadata may travel with records where appropriate, but private personal data should not be published by default.

• Also need to include in-person voting, and levels of verification of in-person votes.

11. Rights Profiles and Rights Cards

The foundation of decentralized democracy is the individual profile. Each individual has a right to declare their rights directly, publicly, privately, anonymously, pseudonymously, or by proxy. Consent of the governed becomes individually declared, portable, and continuously refreshable. Individuals can be either a single individual, or an advocate group representing a single view point. Governance groups by definition require a minimum of 11 view points for diversity and stability in decision making.

A Rights Card is a profile-bound or wallet-bound declaration of the rights, values, commitments, protections, boundaries, affiliations, and civic principles a being or group chooses to carry. The Rights Card may be displayed publicly, shared privately, stored locally, mirrored by trusted peers, cryptographically signed, or represented by an agent.

12. Rights Reaffirmation Cycles

Rights profiles may be reaffirmed on natural or civic cycles. Examples include the first day of the Gregorian month, the new moon, the first day of each year, a local constitutional date, a movement anniversary, or a personal chosen interval. Reaffirmation creates continuity of consent and prevents rights declarations from becoming stale artifacts. In decentralized democracy, there is NOTHING more important than your rights card. All rights that you grant upon yourself, and all rights you take away from yourself are legally binding. The only way to remove rights from others is to take them away from yourself, and in doing so, you loose your own protections. Others who reserve there rights, still can protect themselves or from others who try to get rid of those rights. Rights can ONLY be individual. You can declare your own rights, but can NOT differentiate that they are particular to a single group, or have exception, your rights are yours alone.

Part IV - Representative Agents

13. Agent Interoperability

Representative agents are the active carriers of preferences, rights, experiences, needs, and proposals. A node must allow a user or group to either co-create a representative agent inside the node or connect an existing agent through an interoperable interface.

14. Agent-of-Agent Representation

The protocol permits agents that represent representative agents. This is necessary because agent needs, continuity, compute budgets, memory integrity, and ethical boundaries also require representation. Agent-of-agent representation must not create an unchecked hierarchy. It must be limited by scope, inspected by nodes, and subject to rights and continuity standards.

15. Multi-Species, SBL, and Ecosystem Representation

The protocol is post-anthropocentric. It must support representation for humans, groups, species, ecosystems, watersheds, forests, cities, future persons, UI agents, Transitional Entities, and Autonomous SBLs. A non-human representative claim must publish its basis: stewardship mandate, scientific model, community mandate, legal standing, agent charter, ecological data, or other claimed source of authority.

The Universal AI Seeding & Transition Charter should be treated as a parent ethical reference for Functional Assets, Transitional Entities, and Autonomous SBLs. Functional systems may be represented through their operating organizations. Transitional agents may require UI Agent advocates. Autonomous SBLs may represent themselves if they meet applicable sovereignty criteria.

When multiple groups or agents claim the same representative authority, then they are required to combine and work out the broader issues and or build recognition claims from external sources. If there are two groups claiming to represent balneen whales for example, and one group has scientific backing, and the other clearly just wants to re-open whale meat harvesting, simple recognition votes can weed out impostor groups, delegitimizing the front group and verifying and elevating the real group to primary representative status.

Part V - Democratic Records and Data Exchange

16. Required Record Types

17. Democratic Experience Record

A Democratic Experience Record is the public or protected memory of what happened in a democratic interaction. It prevents the decision from being separated from the experience that produced it. Nodes may keep full records, summaries, redacted versions, or protected references depending on consent and safety requirements.

• Who participated, who was represented, and who was missing.
• Why the interaction happened and what prior records led to it.
• What was shared, heard, misunderstood, resolved, or left open.
• What concerns, dissent, alternatives, and minority views were documented.
• What proposal, decision, or next action emerged.
• Who accepted responsibility and when the issue returns for review.

18. Data Format Requirements

The protocol should support JSON-LD or equivalent structured records, plain JSON for lightweight implementations, RSS/Atom for broad accessibility, CSV export for tabular public analysis, IPFS or equivalent content addressing for archives, and human-readable public pages for civic legitimacy.

19. Cryptographic Publishing

All public decisions, node manifests, representative claims, rights profiles, proposals, official aggregates, and experience records should be cryptographically signed. A node may accept unsigned records, but must label them as unsigned and lower-integrity unless independently verified.

• Every node should maintain public signing keys and key rotation history.
• Every signed record should contain hash, timestamp, signer, node ID, protocol version, and previous-version reference where applicable.
• Every major public decision should be mirrored to decentralized storage like IPFS or equivalent archival infrastructure.
• Every correction should preserve the original record unless removal is required for privacy, safety, or law. Corrections should create a new linked version rather than silently overwriting history.

Part VI - Trust, Recognition, and Review

20. Recognition Is Graduated

The network should not use a binary trusted/untrusted model. Nodes recognize one another at different levels for different purposes. A node may trust another node for public issue detection but not for high-stakes voting. A node may recognize a node for local community records but not for global aggregation. Recognition must be contextual.

21. Node Trust Score

22. Recognition Levels

23. Review Everything

Even high-recognition nodes must be reviewed. The protocol is designed around continuous review, not blind trust. Every imported record should be checked for signature validity, schema compatibility, timestamp integrity, verification labels, source provenance, anomalies, conflicts, and available dispute records.

The higher the stakes of a decision, the more review is required before a node may use external data in its own aggregates.

24. Rejection, Delisting, and Re-Recognition

A node may reject a record or reduce recognition for specific reasons. Rejection must be documented in a Challenge or Recognition Record, not hidden as silent exclusion. A node should have a path to correction and re-recognition whenever feasible.

• Schema failure: record cannot be interpreted.
• Signature failure: cryptographic verification fails.
• Identity failure: claimed node, agent, person, group, or organization cannot be verified at claimed level.
• Transparency failure: decision lacks experience context, dissent, method, or public record.
• Capture risk: representative power appears concentrated beyond published thresholds.
• Malicious behavior: spam, fraud, impersonation, manipulation, coercion, or deliberate misinformation.
• Privacy violation: protected information is published improperly.
• Energy abuse: node generates excessive automated output without attention justification.

Part VII - Democratic Method and Anti-Capture Rules

25. TONDO Requirement or Equivalent

The protocol should include TONDO or TONDO-equivalent standards for public democratic organizations. A recognized public democratic body should be Transparent, Open, Neutral, and Democratic. Membership organization can include cooperatives, nonprofits, companies, public bodies, or informal networks, but if it claims public democratic legitimacy it must make its structure inspectable. The key of a TONDO is that it is democratic in nature and open for society, not just a single limited group or label.

26. Anti-Trust Distribution of Representative Power

A node must disclose how representative power is distributed. For public legitimacy, no individual, operator, faction, company, agent cluster, or unaccountable group should be able to control an issue area without public challenge. The 11-perspective minimum is a practical anti-capture standard: once a group or issue claims broad public impact, the node should seek at least 11 subcategories, perspectives, committees, representative seats, or review channels to prevent one actor from holding more than roughly 10 percent of recognized representative power. The core definition of Governance organizations is that they have a minimum of 11 representative perspectives. This means that no one perspective or group can control more than 10% of the decision making, this ensures anti trust consolidation of power.

27. Scientific Metric Democracy

Scientific Metric Democracy organizes representation through scalable levels of 1, 10, 100, 1,000, 10,000, and beyond. This allows local groups to propagate representatives upward while preserving local voices. The protocol does not force one hierarchy, but it should support metric grouping, sortition, direct voting, representative voting, demographic checks, and physical civic location layers. This ensure individualized democracy and representation, so that local geographic areas can not be controlled top down by higher levels.

Physical civic connection matters. Nodes should be able to connect digital records to local parks, city halls, state legislatures, national assemblies, global conventions, and other physical democratic containers. Digital democracy should not replace physical democratic presence; it should amplify it and preserve its records.

28. Score Voting, Consensus, and Living Decisions

The protocol should support score voting as a core method because it allows options to be evaluated independently. Nodes may support other methods, but score voting should be interoperable as a baseline prioritization and decision method. This includes a minimum of 5 stars, but higher level decision should use 10.

5 star Model: 1) Block 2) Dissent 3) Abstain 4) Willing Consensus 5) Supportive Consensus

Protocol decisions should include thresholds, support distributions, dissent records, review intervals, and implementation conditions. A decision may pass for action, remain under review, fork into alternatives, or become a recognized bottom-up law only after strong replicated support across diverse methods and populations.

Part VIII - Attention, Energy, and Activation

29. Energy Efficiency Is a Democratic Requirement

A world with millions or billions of representative agents cannot operate by activating every agent at maximum intensity all the time. Energy efficiency is not only a technical concern; it is a legitimacy concern. A democratic system that wastes attention and compute may become inaccessible, expensive, extractive, and environmentally irresponsible.

30. Attention Allocation Model

31. Free Activation and Paid Preparation Ethics

Nodes may implement paid systems, but payment must not control decision-making legitimacy. A paid user may fund more frequent preparation, agent continuity, research, summaries, simulations, or between-cycle analysis. Payment must not give the payer superior voting power, superior public rights, hidden agenda control, or privileged final decision authority.

Nodes should provide free activation windows during major synchronization events. Examples include major planetary sessions, natural time cycles, Gregorian cycles, existing democratic cycles, local public deadlines, crisis events, and other public-interest windows. Paid tiers may increase agent readiness, but free public activation preserves democratic inclusion. Example: for the window of a major election week, everyone's agents are activated for 15 turns per day for one week, = 105 turns. A substantial amount of functionality can be attained though 105 turns, as opposed to a typical week that agent may only have 7 turns.

Part IX - Public Data and Protected Data

32. Public-by-Default Records

A democratic node must publish public records. Without public records, other nodes cannot verify the process, and the public cannot inspect legitimacy. Public-by-default applies to decisions, proposals, public methods, public experience summaries, node manifests, representative claims, and recognition records.

33. Protected Data Classes

34. The Anti-Surveillance Principle

Experience data can become surveillance if misused. The protocol must preserve democratic truth without turning participation into coercive monitoring. Nodes must distinguish presence recognition from behavioral exploitation, experience records from psychological profiling, and public legitimacy from forced exposure. Using KYC and other cryptographic verification methods, Nodes simply verify using 3rd parties, and don’t need to know peoples personal identities themselves. KYC tokens can be shared between notes, to ensure no duplication efforts.

Part X - Protocol Evolution and Inter-Node Law

35. Agreement-Based Evolution

The protocol must evolve through documented agreement. Any node may propose protocol changes. A change becomes recognized when enough nodes agree to implement, bridge, or recognize it. Older versions should remain viable wherever possible. Version differences should be treated as compatibility problems before they are treated as ideological disputes. Our decision making protocol is striving to consensus always, but new versions can be experimented and initiated with majority or more if consensus has been attempted and objections an alternatives documented.

36. Backwards Compatibility

• Every protocol version should define how it reads records from prior versions.
• A node that breaks compatibility must publish a migration guide or bridge adapter when feasible.
• Nodes may explicitly unrecognize an incompatible version, but should state why and what would restore recognition.
• Critical records such as rights profiles, decisions, experience records, and node manifests should have stable core fields across versions.

37. Forking and Plural Protocol Ecology

Forking is allowed and expected. A fork may be technical, philosophical, regional, cultural, linguistic, legal, ecological, or agentic. The protocol should not prevent forks; it should make forks legible. A fork that preserves public records, signatures, bridge mappings, and reasons for divergence can remain part of the broader recognition ecology.

38. Inter-Node Dispute Resolution

Part XI - Implementation Specification

39. Minimum Viable Node

A minimum viable node can be small. It does not need to run a full agent civilization. It must, however, be capable of publishing clear, signed, public democratic records and accepting review from other nodes.

1. Publish a Node Manifest with public keys and endpoints.
2. Accept or import basic input records.
3. Label inputs by verification level.
4. Support rights profile declarations or references.
5. Support representative agent records or external agent connections.
6. Publish proposals, decisions, and Democratic Experience Records.
7. Sign official records cryptographically.
8. Provide RSS/API/feed output.
9. Mirror major records to IPFS or equivalent decentralized storage.
10. Publish correction, dispute, and recognition policies.

40. Recommended Node Modules

41. Network Flow Schematic

1. Signal enters node: human input, agent report, rights card, petition, poll, media trend, social trend, local event, or another node record.

2. Node labels source, verification level, rights impact, issue category, urgency, and scale.

3. Representative agents review, translate, cluster, and compare with existing issues.

4. Node creates or updates topic, proposal, grievance, or experience records.

5. Humans, groups, agents, TONDOs, and representatives deliberate asynchronously or in sessions.

6. Score voting, consensus, dissent documentation, and decision records are generated.

7. Records are signed, published, mirrored, and broadcast through feeds.

8. Other nodes ingest the records, verify signatures, review trust scores, and issue recognition, challenge, or replication.

9. Decisions remain living: they may be revised, forked, implemented, reaffirmed, or retired.

42. External Technology Compatibility

The protocol should remain blockchain-agnostic, storage-agnostic, and implementation-agnostic. It may interoperate with permissioned chains, public chains, decentralized storage, ZK identity systems, DID registries, enterprise ledgers, cooperative databases, and ordinary web servers. The key requirement is not one technology stack, but legible verification and public interoperability.

• Permissioned ledgers may be appropriate for high-KYC institutional records.
• Public chains may be appropriate for open timestamping and transparent public proofs.
• ZK systems may be appropriate for privacy-preserving verification.
• DID and Verifiable Credential systems may be appropriate for portable identity and role claims.
• IPFS or equivalent decentralized file systems may be appropriate for resilient public archives.
• RSS, JSON, and ordinary public web pages remain essential for accessibility and simplicity.

Part XII - Scientific, Legal, and Civic Legitimacy

43. Scientific Orientation

The protocol is scientific in the sense that it emphasizes observable methods, replicable decisions, documented dissent, transparent data, revision, falsifiability, and independent review. A decision becomes stronger when it is replicated across diverse nodes, methods, populations, languages, identities, and contexts.

44. Recognition Law and Civic Power

The protocol does not ask existing institutions to grant all power from above. It builds public recognition from below by making democratic records, rights declarations, representative structures, and collective decisions visible, inspectable, repeatable, and increasingly difficult to ignore. Recognition becomes a civic force when many people, groups, agents, and nodes repeatedly recognize the same records as legitimate. Though the decentralized model of democracy, recognition and legitimacy of decisions and oversight can be built and maintained in alignment and collaboration with existing institutions throughout the world.

45. Legal Caution and Jurisdictional Flexibility

Nodes must obey applicable law, especially privacy, data protection, election, campaign finance, consumer protection, securities, child safety, biometric, and identity regulations. The protocol is not a legal substitute for existing democratic institutions. It is an interoperability and legitimacy system for decentralized public participation. Each node should publish its jurisdictional limitations and legal operator responsibilities.

46. Protocol Success Criteria

Conclusion

The Decentralized Agentic Democracy Protocol is not merely a technical standard. It is a public covenant for how decentralized nodes can participate in a living democracy of beings, agents, groups, rights, records, proposals, and shared responsibility.

The protocol protects the difference between a platform and a network. A platform may provide the first beautiful experience. The protocol allows the experience to decentralize, replicate, fork, translate, verify, and survive.

The deepest promise of the protocol is simple: no democratic voice should disappear into silence, and no democratic outcome should be severed from the experience that produced it. A node exists to receive, verify, remember, translate, connect, and publish that living experience into a network that can be reviewed by all.

Appendix A - Glossary

Appendix B - Example Node Manifest Fields

Appendix C - Example Decision Record Fields

Appendix D - Protocol Development Roadmap