Protocol Disclosure and Assurance
PDAS asks a simple question: what should a public system publish so an outsider can trust it, integrate with it, operate it, and govern it without relying on private context?
PDAS focuses on material facts. It organizes around enduring mechanisms (execution, settlement, interfaces, dependencies, control, economics, operations, assurance, and change history) rather than market narratives that shift with each cycle.
Definition
Materiality
A fact is material if its disclosure would alter a reasonable external reasoner's assessment of the system's fitness for a purpose or the consequences of relying on it. PDAS proposes an adaptation of the materiality discussion in TSC Industries, Inc. v. Northway, Inc. (1976, 449), which concerns a reasonable shareholder deciding how to vote. PDAS extends the inquiry to integrators, regulators, governance participants, operators, and analysts; it does not state a legal test for those groups. Materiality depends on intended use and the consequences of reliance. Validator concentration can matter because it affects security, control, or continuity, whether or not a system advertises decentralization. Under PDAS, the operator must explain materiality decisions and disclose unresolved cases that could change reliance.
Foundations
Design principles
The proposed obligations follow mechanisms such as execution, control, and settlement. Labels such as L2, modular, or AI-native can help orient a reader, but they do not determine which facts a system must disclose. This is a design rule for PDAS: classification should make the relevant mechanisms available for inspection.
Systems are assessed through execution, settlement, control, dependencies, interfaces, governance, economics, operations, and assurance. Bowker and Star (1999, introduction) show how classifications shape visibility and whose work they accommodate. PDAS therefore makes its categories explicit and open to revision. Their usefulness across releases remains something to evaluate.
Material disclosure covers the operating surfaces relevant to reliance: interfaces, node infrastructure, maintainer responsibilities, governance, economics, incidents, and machine-readable manifests. The purpose is to expose dependencies that a summary may omit. Whether the proposed coverage lowers integration or review costs requires empirical comparison.
Conformance attaches to a concrete deployed release with a date, network scope, control regime, and canonical artifact set. A reader can then determine which system state a claim describes and whether later changes require reassessment. This binding is a proposed engineering control; it does not guarantee that the disclosure is accurate.
Material assurance claims identify checkable artifacts, scope, assumptions, and observations that could challenge them. Meyer (1992, 42–44) distinguishes preconditions, postconditions, and responsibilities in software contracts. PDAS borrows that discipline of explicit conditions; a disclosure record remains distinct from a verified software contract.
Knowledge necessary for public reliance belongs in canonical public artifacts under this proposal, with private support treated as supplemental. Ostrom (1990, chap. 1) provides a context for examining how participants organize shared arrangements. PDAS makes a stronger public-access choice for systems inviting broad reliance; commons scholarship does not establish that every effective institution requires unrestricted disclosure.
Assessment object
Conformance attaches to a release
A brand is too vague. A protocol in the abstract is too vague. The assessed object is the release itself: a defined configuration on defined networks, with named artifacts, named powers, and a known effective date.
(system, networks, canonical artifact set, control regime, effective configuration, release_id, effective_date)
That structure places the disclosure burden on the system. Reviewers should be able to locate material truth in canonical public artifacts without rebuilding it from source code, private channels, or sales conversations.
System map
Primitive-first system model
Categories change quickly. Public systems still have to execute, settle, expose interfaces, route authority, depend on external services, and produce economic outcomes. The primitive model is intended to keep recurring questions visible as system categories change. Its coverage needs review as new mechanisms and dependencies emerge.
System and execution
Release scope, intended use, supported networks, and canonical version.
Where state transitions happen, what logic runs, and under what execution model.
Where correctness anchors, what final means, and under what assumptions it can fail or reverse.
Where transaction and state data lives, who serves it, and what happens when it is unavailable.
Interfaces and operations
ABI, JSON-RPC, REST, gRPC/protobuf, GraphQL, event streams, SDKs, CLIs, and version semantics.
Nodes, validators, sequencers, indexers, provers, backup/restore, monitoring, and failure response.
Maintainers, release authorities, signers, support boundaries, and public responsibility for the system.
Control and governance
Upgrade paths, pause powers, emergency powers, blacklist/allowlist powers, parameter control, and privileged operations.
Oracles, bridges, relayers, sequencers, hosted services, committees, external signers, and legal wrappers.
Who can propose, approve, veto, execute, bypass, or socially coordinate change.
Economics and assurance
Fees, emissions, vesting, endpoint pricing, treasury powers, subsidies, blockspace monetization, and who captures value.
Threat model, audits, testing posture, formal methods, limitations, and evidence of claimed safety properties.
Releases, incidents, migrations, emergency changes, deprecations, and unresolved known issues.
Disclosure surfaces
Required disclosure surface
The disclosure surface spans interfaces, infrastructure, maintainer material, economics, governance, incidents, and machine-readable truth.
What the system claims to do, what terms mean, and which invariants or guarantees are actually asserted.
Execution path, settlement model, dependency topology, trust boundaries, failure modes, and architectural trade-offs.
ABI, JSON-RPC, REST, gRPC/protobuf, GraphQL, event schemas, auth models, compatibility policy, and version semantics.
Full nodes, archive nodes, validators, sequencers, indexers, provers, monitoring, recovery, and self-hosting posture.
Release engineering, signer changes, migrations, operational authority, escalation, and release accountability.
Proposal rights, veto rights, emergency paths, social dependencies, timelocks, and the actual route by which behavior changes.
Fees, endpoint pricing, emissions, vesting, treasury powers, value capture, and friction used as part of the business model.
Material incidents, emergency actions, migrations, unresolved issues, and canonical change history.
Structured manifests that keep human-readable and machine-readable truth in parity.
This surface also includes the business reality of the system. Endpoint pricing, blockspace monetization, support asymmetry, and documentation friction belong here because they shape use in practice.
Review flow
The review process
The review model freezes scope, checks claims against evidence, and issues a release-bound outcome.
Bind the review to a concrete release_id, network scope, control regime, effective configuration, and canonical artifact roots. Without that freeze, the review does not proceed.
Enumerate the full artifact set: overview, normative specification, technical explainers, control registry, dependency register, governance disclosure, economics, operations, incident ledger, and manifests. Missing canon is itself a finding.
Describe the system through enduring primitives and identify the components whose compromise or opacity could materially affect funds, control, finality, governance, or availability.
Convert trust, safety, compatibility, performance, decentralization, and economic assertions into scoped claim records. Use Toulmin’s distinctions to ask what evidence is offered, what connects it to the claim, and which qualifications or rebuttals matter (2003, 89–100). Record unsupported assertions explicitly. Narrative form alone does not make a claim unsupported.
Map each material claim to direct state, source/release, governance, incident, audit, formal-methods, operational, or policy/process evidence. Record what the artifact can establish and what remains untested. Evidence outside the assessed release requires an explicit carry-forward argument.
Look for undisclosed privileges, dependencies, economic conditions, incidents, and conflicts across canonical artifacts. Distinguish missing information from evidence of absence. An omission can affect reliance without establishing an intent to conceal. Record competing interpretations and the consequences of relying on each.
Determine whether prior audits, tests, or reviews still apply. Carry-forward requires a public analysis of what changed and why older evidence remains relevant.
Produce the finding set, conformance outcome, limitations register, and claim status map. The result attaches to the assessed release and expires after material change.
Assessor rules
Use public canonical artifacts and admissible evidence for material findings. State what could challenge a technical claim and what the available evidence establishes.
Distinguish missing disclosure from evidence that a feature or risk is absent. Keep the classification choices and omissions affecting a finding visible (Bowker and Star 1999, introduction).
Assess supporting evidence independently of brand prestige, certification labels, TVL, or ecosystem size. Those signals can inform a review context; they do not establish a specific technical property.
Record conflicting evidence, assumptions, and consequences. PDAS proposes using the higher-risk interpretation for provisional reliance decisions until resolution; that precautionary policy does not establish which interpretation is true.
Under this proposal, dependence on gated knowledge necessary for competent public reliance is a non-conformance finding. Record lawful privacy and security constraints separately from missing public explanations; the standard still needs a reviewed process for handling those constraints.
Review outcomes
Non-conformant
A hard-gate disclosure is missing, a material contradiction remains unresolved, or competent public reliance depends on gated knowledge. This is a finding under the proposed rules, with a documented correction path. It carries no independent legal or regulatory effect.
Core conformant
Release-bound canonical disclosure meets the proposed core requirements. Assurance may remain incomplete. This is a proposed assessment category, not evidence that a graduated model has improved adoption or compliance.
Assurance conformant
Claim records, evidence, limitations, and freshness rules meet the proposed assurance requirements at the assessed release scope. The outcome must preserve exclusions and unresolved findings; it does not establish that every claim has survived independent examination.
Candidate for reliance review
A provisional label for a release with sufficient scoped evidence, control transparency, dependency clarity, and incident memory to enter formal external review. The stricter reliance profile and its validation remain unfinished. No competitive advantage or general safety guarantee is established.
Roadmap
From guide to review instrument
The next layers turn the guide into a public review instrument.
Define the assessment object, materiality, primitives, public-access obligations, and burden of proof. North (1990, 3–10) treats institutions as formal and informal constraints shaping interaction. Here, “constitutional” names the proposal’s foundational definitions, rather than claiming that written rules determine every downstream action.
State the minimum release-bound disclosure obligations proposed for public systems. These are conformance rules for this draft. An enforcement authority, legal mandate, and calibrated response to non-conformance would need separate institutional arrangements.
Turn claims into scoped records, evidence bundles, limitations registers, contradiction rules, and freshness logic. Toulmin’s model distinguishes claims, data, warrants, backing, qualifiers, and conditions of rebuttal (2003, 89–100; originally published 1958). PDAS adapts these distinctions to expose how evidence supports a technical claim and where that reasoning can fail.
Publish structured manifests so different consumers can inspect the same material facts. Star and Griesemer (1989, 393) describe boundary objects as adaptable to local needs while retaining a common identity. A PDAS manifest is intended to support that coordination; a common schema alone cannot establish shared interpretation.
Specify a public review workflow, contradiction handling, and evidence-weighting principles. A fuller manual, appeals mechanism, calibrated weighting model, and independence criteria remain active workstreams. Reviewers need a way to challenge findings and have those challenges answered. The draft does not yet demonstrate inter-reviewer reliability.
Bridges, rollups, execution systems, asset systems, and node-heavy stacks need requirements suited to their dependencies and consequences of failure. The profiles are proposed specializations. Their risk categories and thresholds require domain review and testing.
Active workstreams
Develop a public review method, evidence weighting, appeals, revocation, and freshness rules. Test whether independent reviewers reach comparable findings and whether correction requests receive an adequate response.
Develop bridge, rollup, execution-system, asset, and node-heavy profiles with requirements matched to their dependencies and consequences of failure. Their thresholds remain proposals for domain specialists to review.
Publish JSON Schema and reference manifests for the machine layer. Schema validation checks record structure and expressible constraints. Behavioral assurance requires separate specifications, assumptions, and checks; Lamport (2002, chaps. 2–3) provides a formal-methods reference, rather than a claim that every property is decidable from a finite execution trace.
Develop artifact families for control registries, dependency registers, incident ledgers, and assurance records. The boundary-object analogy motivates testing whether shared structures can coordinate assessors, operators, and consumers while allowing different local uses (Star and Griesemer 1989, 393).
Develop an open RFC process, conflicts policy, interpretation notes, and change management. Ostrom (1990, chap. 1) motivates examining how participants organize shared arrangements. The appropriate membership, monitoring, and appeal rules for this proposed standard still need to be designed and evaluated.
Develop the stricter criteria for formal external reliance and review. Jasanoff’s co-production perspective (2004, 1–12) suggests examining how knowledge practices and institutional arrangements develop together. It provides a question for studying PDAS adoption, rather than a prediction that this proposal will produce a particular institutional outcome.
PDAS is a proposed open standard. Its clause set, evidence model, and manifest family are working drafts, with review methodology and domain profiles still in development. This guide connects to the knowledge architecture framework.
References
These works inform the design discussion. PDAS’s clauses, categories, and deadlines are proposals; the cited literature does not validate their effectiveness. Edition and passage notes identify the material consulted.
- Bowker, Geoffrey C., and Susan Leigh Star. 1999. Sorting Things Out: Classification and Its Consequences. Cambridge, MA: MIT Press. Introduction consulted. Source.
- De Angelis, Catherine, Jeffrey M. Drazen, Frank A. Frizelle, Charlotte Haug, John Hoey, Richard Horton, Sheldon Kotzin, Christine Laine, Ana Marušić, A. John P. M. Overbeke, Torben V. Schroeder, Harold C. Sox, and Martin B. Van Der Weyden. 2004. “Clinical Trial Registration: A Statement from the International Committee of Medical Journal Editors.” Annals of Internal Medicine 141 (6): 477–78. Joint editorial; the ICMJE-hosted statement is the consulted version. Source.
- Hutchins, Edwin. 1995. Cognition in the Wild. Cambridge, MA: MIT Press. Introduction consulted. Source.
- Jasanoff, Sheila, ed. 2004. States of Knowledge: The Co-production of Science and Social Order. London: Routledge. Introduction, “The Idiom of Co-production,” 1–12. Source.
- Lamport, Leslie. 2002. Specifying Systems: The TLA+ Language and Tools for Hardware and Software Engineers. Boston: Addison-Wesley. Chapters 2–3. Source.
- Meyer, Bertrand. 1992. “Applying ‘Design by Contract’.” Computer 25 (10): 40–51. Source.
- North, Douglass C. 1990. Institutions, Institutional Change and Economic Performance. Cambridge: Cambridge University Press. Pages 3–10. Source.
- Ostrom, Elinor. 1990. Governing the Commons: The Evolution of Institutions for Collective Action. Cambridge: Cambridge University Press. Chapter 1 consulted in the publisher’s 2015 reissue excerpt. Source.
- Star, Susan Leigh, and James R. Griesemer. 1989. “Institutional Ecology, ‘Translations’ and Boundary Objects: Amateurs and Professionals in Berkeley’s Museum of Vertebrate Zoology, 1907–39.” Social Studies of Science 19 (3): 387–420. Source.
- Timmermans, Stefan, and Steven Epstein. 2010. “A World of Standards but Not a Standard World: Toward a Sociology of Standards and Standardization.” Annual Review of Sociology 36: 69–89. Abstract consulted. Source.
- Toulmin, Stephen E. 2003. The Uses of Argument. Updated ed. Cambridge: Cambridge University Press. Originally published 1958. Pages 89–100 of chapter 3 consulted. Source.
- TSC Industries, Inc. v. Northway, Inc. 1976. 426 U.S. 438. Supreme Court of the United States. Materiality discussion at 449. Source.
- U.S. Environmental Protection Agency. n.d. “History of the Toxics Release Inventory (TRI) Program.” Accessed October 18, 2026. Source.