Proof of Concept Template

Use this template to document a proof-of-concept before any institutional pilot. Assess against CROPS and the walkaway test. EPIC publishes the template; filling it does not imply EF endorsement of a deployment.

See example: Carbon MRV PoC

Reference

Specification format is inspired by COSS/zkspecs (e.g. Anon-Aadhaar spec). Use RFC 2119 keywords (MUST, SHOULD, MAY) in normative sections.

CROPS

EPIC uses CROPS as non-negotiable design properties for public-interest work. They are assessed together — not traded off for adoption speed, institutional convenience, or market share. Censorship resistance: No actor with ordinary control over the system can selectively block a user from verifying or exiting with their data and keys. Resilience: The system survives operator, vendor, or steward failure without trapping users — technically and procedurally. Openness: Specs, formats, and reference code needed to verify and fork are public; no hidden rules or source-available lock-in. Privacy: Data exposure is minimised by default; privacy is not an optional overlay on a surveillance core. Security: The system does what it claims — no more, no less — with explicit threat models and falsifiable claims. Worked failure examples 1. Censorship resistance failure: A national credentials app verifies only against one government-hosted API; users cannot present the same credential via any other wallet. The registry may be "decentralised" on paper; the user is not. 2. Privacy failure: Hashes of daily benefit claims are anchored on a public ledger; the chain reveals timing, frequency, and correlation across programmes — re-identification risk for named individuals even without raw data onchain.

Walkaway test (user-side exit)

A design passes the walkaway test when a user (or independent verifier acting on public data) can, without permission from EPIC, the original operator, or the issuer: 1. Verify the claims the system makes about their data or status; 2. Export or continue using their credentials, keys, or evidence in another client or registry supported by the public spec; 3. Understand what breaks if the original operator disappears — and whether essential services remain accessible without re-enrolment under coercion. Operator-side walkaway alone is insufficient. A file-based registry that any engineer can re-host passes operator walkaway while users remain locked to a single issuer wallet with no portable keys — that fails user-side walkaway. Worked failure examples 1. Passes operator walkaway, fails user walkaway: An attestation registry publishes an open spec and multiple hosts run append-only mirrors. Users received credentials only through a proprietary app with no key export; when the app shuts down, users cannot prove prior status. 2. Fails both: A single hosted backend must approve every verification request; the vendor holds all signing keys; neither users nor independent verifiers can validate without that backend.

1Problem exploration and existing solution research

Describe the public-sector or institutional problem in concrete terms: who is affected, what fails today, and why it matters. Summarise existing solutions (policy, legacy systems, pilots, standards) and their limitations. Include citations to official sources, standards bodies, or multilateral guidance (e.g. UNFCCC, World Bank, OECD) where relevant. The goal is to establish a shared understanding of the problem space and the gap that an Ethereum-based approach could address.

Acceptance criteria

  • Problem statement is specific and cites affected stakeholders (e.g. verifiers, registries, beneficiaries).
  • At least two existing solutions or frameworks are described with strengths and limitations.
  • Sources are linked (URLs or references) and authoritative where possible.
  • The gap or limitation that motivates an Ethereum-based solution is clearly stated.
  • The self-sovereign user is named; harms from coerced enrolment or surveillance are acknowledged where relevant.

2Ethereum relevance and value proposition

Explain why Ethereum (or public blockchain / verifiable data) is relevant to this use case. Describe the value proposition in terms of coordination, transparency, auditability, or programmable trust. Call out which Ethereum primitives apply (e.g. attestations, commitments, registries, smart contracts) and how they map to the problem. Avoid generic blockchain claims; focus on concrete benefits (e.g. tamper-evident audit trail, verifier attestations, milestone-based disbursement) and any trade-offs or constraints (e.g. data offchain, privacy). Include a paragraph titled "When Ethereum is not appropriate" with a concrete negative example — a problem for which Ethereum is the wrong primitive, and what should be used instead.

Acceptance criteria

  • Value proposition is stated in one or two clear sentences.
  • At least one Ethereum primitive (e.g. attestations, registries, commitments) is named and linked to a problem or requirement.
  • Trade-offs or constraints (e.g. scalability, privacy, regulatory) are acknowledged where relevant.
  • Language is accessible to both technical and policy readers.
  • A documented negative outcome is included where Ethereum is not the appropriate primitive, with rationale.

3Requirements gathering and listing

Provide a structured list of functional and non-functional requirements for a proof of concept or pilot. Group by category (e.g. functional, security, compliance, operational). Requirements should be testable (e.g. "The system SHALL record verifier attestations with a timestamp and verifier identity"). Use MUST/SHOULD/MAY (RFC 2119) or equivalent if appropriate. Include any regulatory, interoperability, or institutional constraints (e.g. data residency, access control, alignment with UNFCCC or national MRV frameworks).

Acceptance criteria

  • Requirements are listed in a structured way (e.g. numbered list or table).
  • At least five functional requirements and at least two non-functional (e.g. security, auditability) are included.
  • Each requirement is specific and verifiable.
  • Regulatory or institutional constraints are explicitly called out where they exist.

4Architecture diagram for a proof of concept

Provide a diagram (or link to a diagram) that shows the main components of the proof of concept: data sources, processing steps, blockchain/verifiable layer, and any external systems or users. Describe the flow in short captions or bullet points. The diagram should make it clear what runs onchain vs offchain, who submits data, who verifies, and how integrity is maintained. Use standard notation (e.g. boxes for components, arrows for data/control flow) and keep it readable for both technical and non-technical stakeholders.

Acceptance criteria

  • A diagram or link to a diagram (e.g. Mermaid, draw.io, image) is provided.
  • Onchain vs offchain components are clearly distinguished.
  • Data flow (inputs, processing, outputs) and main actors (e.g. prover, verifier, registry) are indicated.
  • A short narrative (paragraph or bullet list) explains the flow and design choices.

5Sample code of the proof of concept and GitHub repository

Include or link to sample code that demonstrates the core logic of the proof of concept (e.g. attestation format, commitment scheme, smart contract interface, or verifier workflow). Provide a link to a public GitHub (or equivalent) repository with a README that explains how to build, run, and test the code. The code should be minimal but runnable and aligned with the architecture diagram. Document dependencies, environment setup, and any test or demo scripts.

Acceptance criteria

  • At least one code snippet or module is shown that illustrates a key part of the PoC.
  • A public GitHub (or equivalent) repository URL is provided.
  • Repository README includes: purpose, setup instructions, and how to run tests or a demo.
  • License and contribution guidelines are stated or linked.

6Associated documentation (technical and non-technical)

List and link all documentation that supports the use case: technical docs (API, contracts, data formats), user or operator guides, policy briefs, and any non-technical explainers for decision-makers. For each document, give a one-line summary and the audience (e.g. developers, verifiers, policy). Technical documentation should cover interfaces, data schemas, and deployment; non-technical documentation should explain the problem, solution, and benefits without assuming protocol expertise.

Acceptance criteria

  • At least one technical document (e.g. API spec, schema, contract doc) is linked or summarized.
  • At least one non-technical document (e.g. overview, policy brief, user guide) is linked or summarized.
  • Each linked document has a short description and target audience.
  • Links are valid and publicly accessible where possible.

7Visual demo and video explanation of user flow

Provide a visual demo (screens, wireframes, or recording) that shows the main user flow: e.g. how a prover submits data, how a verifier attests, how a registry or dashboard displays results. Include a short video (or link to a video) that walks through the flow and explains each step in plain language. The goal is to make the proof of concept tangible for stakeholders who will not read code or specs. Captions or narration should highlight where Ethereum or verifiable data adds value.

Acceptance criteria

  • A demo (link, embed, or downloadable asset) is provided—e.g. video, interactive prototype, or screenshot walkthrough.
  • The main user flow (e.g. submit → verify → record) is clearly shown.
  • A video or narrated walkthrough explains the flow in under ~5 minutes, with plain-language description.
  • Where relevant, the moment(s) where blockchain/verifiable data is used are pointed out.

8Call to action to develop this further

State clearly what you are asking from the reader or community: e.g. pilot partners, feedback on the spec, contributions to the repo, or funding. Specify contact points (email, forum, GitHub issues), timelines if relevant, and what kind of input or commitment you need. Make it easy for interested parties to take the next step (e.g. "Open an issue with the label pilot-interest" or "Contact [email] with subject line Use Case PoC").

Acceptance criteria

  • A single, clear call to action is stated (e.g. join pilot, contribute code, review spec).
  • At least one concrete contact or channel is provided (email, GitHub, Discord, etc.).
  • Next steps or timeline are indicated where appropriate.
  • The ask is realistic and scoped (e.g. "feedback on Section 3" rather than "adopt the system").

9List of potential features that can be added

List potential features or extensions that are out of scope for the current proof of concept but could be added in a later phase. For each, give a short description and why it would add value (e.g. "Multi-registry reconciliation to prevent double-counting"). Prioritisation (e.g. high/medium/low) or dependency order is optional but helpful. This section helps roadmap discussions and sets expectations about what is not in v1.

Acceptance criteria

  • At least three potential features are listed.
  • Each feature has a one- or two-sentence description and rationale.
  • Features are clearly marked as future or out-of-scope for the current PoC.
  • Where relevant, dependencies between features or phases are noted.

10Specification document (technical spec, zkspecs-style)

Provide a formal specification document that follows a structure similar to [Ethereum improvement specs or COSS-style specs](https://github.com/privacy-ethereum/zkspecs/blob/main/specs/2/README.md): frontmatter (slug, title, name, status, category, editor, contributors, tags), Abstract, Motivation, Specification (with subsections for data formats, protocol flow, security considerations), Implementation notes, References, and optional appendices. Use normative language (MUST, SHOULD, MAY per RFC 2119) for requirements. The spec should be implementation-neutral where possible but precise enough for interoperability.

Acceptance criteria

  • Document includes frontmatter or header with: title, status, category, editor/contributors, tags.
  • Sections include: Abstract, Motivation, and at least one Specification subsection (e.g. data format, protocol flow).
  • Normative keywords (MUST, SHOULD, MAY) are used consistently for requirements.
  • Security considerations and references (standards, prior art) are included.
  • Link to the full spec (e.g. GitHub, HackMD) is provided if the spec lives elsewhere.

Next step

Use this template to create a new use case page for a domain or subdomain from the Map Explorer. Fill in each section with extended descriptions and meet the acceptance criteria for proof of concepts.

Example: Explore Climate & MRV on the map (or view the domain page), then open the Carbon MRV proof of concept from the Proof of concepts tab, or go directly to Carbon MRV PoC for the full documentation and spec.