Blockchain for Local Government: How to Run a Pilot Without Creating a New Silo

Short description: Local governments can trial blockchain credibly—without lock‑in—by anchoring pilots on open digital‑credential standards, trust registries, and security baselines already used by industry and major platforms. This guide shows the exact stack, procurement language, and 90‑day plan we use at 7Block Labs to deliver measurable results while future‑proofing interoperability.

What “no silo” really means in 2026

A no‑silo blockchain pilot is one that:

Uses open, widely adopted standards for issuance, presentation, and revocation so any compliant wallet, verifier, or ledger can be swapped in later.
Keeps personal data off‑chain, stores only tamper‑evidence or revocation artifacts, and aligns with public‑records and retention laws.
Integrates with your IAM, case‑management, and document systems via stable APIs—not a vendor’s proprietary SDK only.
Can pass third‑party security authorizations (e.g., GovRAMP/StateRAMP) and map to NIST digital identity requirements. (govramp.org)

The good news: as of 2025 the core credential and transport standards needed to do all of this are finalized and shipping in mainstream platforms.

The standards stack that prevents silos

If you remember one section, make it this. These are the minimums we specify in every public‑sector pilot to guarantee interoperability next year and five years out.

Data model: W3C Verifiable Credentials Data Model v2.0 (Recommendation, May 15, 2025). This is the canonical way to express digital credentials across issuers, holders, and verifiers. (w3.org)
Cryptographic packaging:
- “Securing VCs using JOSE and COSE” (W3C Recommendation, May 15, 2025) for JSON/CBOR signatures and selective disclosure alignment. (w3.org)
- Selective Disclosure for JWTs, now IETF RFC 9901 (Nov 2025), to minimize data disclosed per transaction. (rfc-editor.org)
Status and revocation: W3C Bitstring Status List v1.0 (Recommendation, May 15, 2025), a compact, privacy‑preserving approach that works at population scale. (w3.org)
Protocols:
- OpenID for Verifiable Credential Issuance (OID4VCI) 1.0—finalized by the OpenID Foundation in 2025 and already in conformance programs and vendor products. (github.com)
- OpenID for Verifiable Presentations (OID4VP) as implemented in major platforms (e.g., Android DigitalCredential API) so any compliant wallet can present to any compliant verifier. (androidcentral.com)
Identifiers: W3C Controlled Identifiers (CIDs) v1.0 (part of the VC 2.0 family), enabling cryptographically verifiable identifier documents with service endpoints. (w3.org)
Trust registries: Trust Over IP (ToIP) Trust Registry Query Protocol v2.0, so verifiers can ask, “Is this issuer authorized to issue credential type X under governance Y?” The protocol is registry‑agnostic and supports federation. (trustoverip.org)
Security baselines: NIST SP 800‑63‑4 (final, July/August 2025), which explicitly adds guidance for subscriber‑controlled wallets, phishing‑resistant auth, and fraud controls; use it to set assurance levels for proofing and presentations. (nist.gov)

Why this matters: with these pieces, you can change wallets, ledgers, or even vendors without re‑issuing every credential or rewriting every verifier.

Real‑world momentum you can reuse

California DMV titles on Avalanche: 42 million vehicle titles digitized with a DMV‑run chain, shifting title transfers from weeks to minutes. The key lesson isn’t “use blockchain everywhere” but “abstract the ledger behind open APIs and credential standards so your DMV app and future verifiers aren’t tied to one vendor or chain.” (reuters.com)
British Columbia’s OrgBook BC: a production deployment issuing and verifying organization credentials at scale (millions of VCs), built on open source and standards—showing how registries can publish verifiable organization data others can rely on. (digital.gov.bc.ca)
Utah’s statutory approach: Utah created a legal framework and a statewide pilot mandate for digital verifiable credentials, with a central support function (DTS) and agency help channels. This is a model for state‑led support of county and city pilots. (law.justia.com)
EU EBSI and EUDI Wallet pilots: multi‑country public‑sector pilots issuing cross‑border VCs (education, public services) on a public‑governed infrastructure—evidence that VC/OID4VC interop is working at continental scale. Even if you’re U.S.‑focused, it’s a great source of patterns for trust registries, wallet attestations, and conformance testing. (interoperable-europe.ec.europa.eu)
U.S. federal interest: DHS S&T’s 2025 awards fund wallets and verifiers that natively support W3C VCDM and DID standards—proof that federal pilots and grants increasingly expect open‑standard credentials. (dhs.gov)
Platform support: Android now exposes native APIs that support OID4VCI and OID4VP, eliminating the “which wallet?” dead‑end in RFPs. (androidcentral.com)

A 90‑day pilot plan that won’t box you in

Day 0–10: problem framing and scope

Choose one high‑volume, low‑controversy use case with 1–2 authoritative data sources. Proven examples:
- Business license proof from the city or county registrar, verified by procurement and zoning.
- Contractor permit credential verified by inspections and procurement.
- Parking permit or fleet credential verified by enforcement devices.
Define success metrics up front: issuance time, verification time, fraud case rate, call‑center deflection, and opt‑in rate.

Day 11–20: governance and data guardrails

Map data classes: PII vs. non‑PII; what is retained and where (wallet vs. agency systems). Commit that no PII is written on‑chain; only integrity artifacts (hashes) or non‑personal status lists are referenced. Use Bitstring Status Lists for revocation. (w3.org)
Set assurance levels by referencing NIST SP 800‑63‑4 for identity proofing and authenticator assurance; choose phishing‑resistant methods where appropriate. (nist.gov)
Document public‑records implications early. In states like Vermont, blockchain‑registered digital records are recognized as self‑authenticating evidence—useful for audits and court admissibility, while still respecting Public Records Acts for disclosure/retention. (legislature.vermont.gov)

Day 21–45: architecture and build

Standards first, vendors second:
- Issuance: OID4VCI 1.0 with SD‑JWT VC and/or VCDM 2.0 Data Integrity credentials (choose based on verifier audience). (github.com)
- Presentation: OID4VP, test with at least two wallets (e.g., Android‑native and an open‑source wallet via OpenWallet Foundation projects like Credo). (androidcentral.com)
- Status: Bitstring Status List 1.0 hosted under your domain. (w3.org)
- Trust and authorization: Integrate a ToIP Trust Registry (or federation) to assert which issuers are authorized for which credential types. (trustoverip.org)
Integration:
- Use your existing IAM (OIDC/SAML) for staff apps; do not stand up a separate identity silo.
- Expose issuer and verifier endpoints under well‑known paths and your existing API gateway; log to your SIEM.
- If a ledger is required, keep it minimal. An enterprise‑operated EVM network (e.g., Hyperledger Besu) or a public chain subnet is fine—but only anchor integrity proofs or registry pointers, never citizen PII. California’s title project shows how to abstract the chain behind APIs. (reuters.com)
Security:
- Keys in FIPS 140‑validated HSM/KMS; JOSE/COSE suites per W3C rec; plan for cryptographic agility. (w3.org)

Day 46–70: usability, inclusion, and conformance

Inclusion plan: provide printable paper credentials with QR‑coded verifiable data for residents without smartphones. Frameworks such as MOSIP’s Inji show how to support paper and USSD without breaking verification. (biometricupdate.com)
Wallet choice: allow any conformant wallet; don’t mandate a single vendor app. Test Android DigitalCredential flows and at least one independent wallet via OID4VP. (androidcentral.com)
Conformance: run OID4VCI/OID4VP interop tests (OpenID Foundation), and verify SD‑JWT compliance (RFC 9901). Track defects in a public test report. (biometricupdate.com)

Day 71–90: pilot operations and measurement

Measure the agreed KPIs with a real unit/department and 100–1,000 credentials.
Publish the credential schema, status list URL, issuer metadata, and trust‑registry entry so external verifiers can self‑serve.
Prepare the “off‑ramp”: a Playbook section that lists exactly how another wallet, verifier, or ledger could be added without re‑issuance.

Copy‑paste procurement language we’ve seen work

When you issue an RFP or SOW, include requirements like these to avoid future lock‑in:

Standards compliance
- Must issue and accept W3C VC Data Model v2.0 credentials, using either Data Integrity or JOSE/COSE security suites, and must support SD‑JWT selective disclosure per RFC 9901. (w3.org)
- Must implement OpenID for Verifiable Credential Issuance (OID4VCI) 1.0 and OpenID for Verifiable Presentations (OID4VP), with discovery metadata hosted under the agency DNS. (github.com)
- Must publish credential status using W3C Bitstring Status List v1.0, hosted by the agency. (w3.org)
- Must integrate with a ToIP‑compatible Trust Registry (TRQP v2.0) or provide an adapter. (trustoverip.org)
Data and privacy
- No PII or sensitive data may be written to any blockchain. On‑chain writes, if any, are limited to non‑personal integrity proofs and public status artifacts.
- Wallet‑held data must be exportable to other compliant wallets without vendor mediation.
- Must provide printable (paper) credentials with verifiable QR for residents without smartphones. (biometricupdate.com)
Security and operations
- Keys must be managed in FIPS‑validated modules and operations must map to NIST SP 800‑63‑4 assurance levels specified by the agency. (nist.gov)
- Cloud services must meet GovRAMP/StateRAMP requirements appropriate to data classification. (govramp.org)
Exit and interoperability
- The agency owns schemas, status lists, and trust‑registry entries. Vendor must supply migration tooling and documentation so a second wallet/verifier can be added within 60 days without re‑issuance.

Architecture pattern: how to wire this into what you already have

Issuer service
- Connects to authoritative systems (licensing, permitting, registries) via existing APIs.
- Issues credentials via OID4VCI, signs with JOSE/COSE or Data Integrity depending on verifier audiences.
- Publishes a Status List credential for revocation/suspension without touching PII. (w3.org)
Wallets
- Residents may use Android‑integrated or third‑party wallets; staff testers can use an OWF‑based wallet to validate flows. (androidcentral.com)
Verifier service
- Embedded in your case‑management portal or handheld enforcement devices; uses OID4VP and consults trust registries for issuer authorization. (trustoverip.org)
Optional ledger
- If policy requires an audit anchor, write a hash of the credential template or registry entry (not the credential itself) to a permissioned EVM chain or a public subnet run under your governance. California’s DMV example shows how to abstract ledger specifics behind agency APIs. (reuters.com)

Practical example: a city business license that works across departments

What we deploy

Credential type: CityBusinessLicenseCredential v1
Subject: organization or sole proprietor
Issuer: City Business Licensing Authority
Binding: SD‑JWT VC signed with ES256; holder binding for replay protection; expiry 1–3 years. (rfc-editor.org)
Status: Bitstring Status List v1.0 updated on issuance, suspension, revocation. (w3.org)
Issuance: OID4VCI authorization‑code flow with the city’s existing OIDC login for business reps. (github.com)
Presentation: OID4VP; verifiers include procurement portal, zoning, inspections, and parking enforcement handhelds. Android DigitalCredential routing means staff do not care which wallet presents. (androidcentral.com)
Authorization: Procurement verifiers call the regional trust registry: “Is City A authorized to issue CityBusinessLicenseCredential?” If yes, the result is cached and logged. (trustoverip.org)

Why it avoids silos

Any department or nearby municipality can verify without an API to your back‑office system.
A business can switch wallets later without re‑issuing.
If you later move revocation from your cloud to a state‑run service, verifiers just follow the status list URL in the credential metadata.

Lessons from the field (what not to do)

Don’t mint credentials in a bespoke JSON shape “because it’s simpler.” You’ll force every verifier to custom‑code and block cross‑jurisdiction reuse. Use VCDM 2.0 contexts and JOSE/COSE or Data Integrity suites. (w3.org)
Don’t put names, addresses, or any PII on‑chain. Put only revocation/status or integrity proofs on a ledger. California’s experience shows how to keep ledger specifics behind APIs. (reuters.com)
Don’t lock to a single wallet vendor. Test against at least two, and leverage platform‑level support like Android’s DigitalCredential API to keep options open. (androidcentral.com)
Don’t invent your own trust list. Use ToIP TRQP so others can query who’s authorized without point‑to‑point agreements. (trustoverip.org)

Measuring value: concrete targets for a 12‑week pilot

Issuance time: reduce from multi‑day to under 10 minutes (compare with DMV title‑transfer targets moving from weeks to minutes). (reuters.com)
Verification time: under 2 seconds online; sub‑second with cached trust‑registry lookups. (trustoverip.org)
Fraud signal: detect and block revoked/suspended credentials instantly via bitstring status updates rather than mailing lists and batch exports. (w3.org)
Inclusion: at least 10% of verifications handled via printable QR credentials or non‑smartphone flow. (biometricupdate.com)
Interop: pass OID4VCI/OID4VP interop suite with two independent wallets. (biometricupdate.com)

Emerging practices to watch in 2026

Wallet and verifier support in mainstream IAM: open‑source IAM like Keycloak is implementing OID4VCI issuer roles aligned with the final spec, making it easier to wire issuance into your existing login stack. (github.com)
Government wallet reference stacks: OpenWallet Foundation projects such as Credo are adding high‑assurance profiles, KMS integrations, and EU/ISO alignment—handy for agencies that want an open baseline rather than a black‑box app. (openwallet.foundation)
Stronger privacy by default: with RFC 9901 for SD‑JWT and platform‑level support, selective disclosure is becoming table stakes for PII minimization in public services. (rfc-editor.org)

Checklist: your “no‑silo” pilot in one page

VCDM 2.0 data model; JOSE/COSE or Data Integrity suites; SD‑JWT selective disclosure. (w3.org)
OID4VCI/OID4VP implemented and tested with two independent wallets (incl. Android routing). (androidcentral.com)
Status via Bitstring Status List v1.0; no PII on any ledger. (w3.org)
Trust registry lookups using ToIP TRQP; publish issuer authorization entries. (trustoverip.org)
NIST SP 800‑63‑4 mapping for IAL/AAL/FAL; phishing‑resistant authentication; keys in FIPS‑validated HSM/KMS. (nist.gov)
Printable credentials with verifiable QR for residents without smartphones. (biometricupdate.com)
GovRAMP/StateRAMP‑aligned security posture for any cloud components. (govramp.org)
Published schemas, metadata, and migration plan so a second wallet/verifier/ledger can be added without re‑issuance.

How 7Block Labs can help

Our public‑sector blueprint packages the above into a 12‑week engagement:

Week 1: scope, metrics, and public‑records mapping.
Weeks 2–6: build issuer, verifier, and status services with your IAM and APIs.
Weeks 7–10: multi‑wallet conformance testing (OID4VCI/OID4VP), Android flows, and accessibility/inclusion options.
Weeks 11–12: pilot ops, metrics dashboard, and an off‑ramp plan documenting how to add or replace wallets, verifiers, or ledger components without re‑issuance.

If you’re evaluating a county or city use case, we’ll start with business licensing, contractor permitting, or parking—whichever gives you measurable ROI fastest while creating reusable components for the next department.

Bottom line

The difference between a flashy blockchain demo and a lasting modernization win is whether you design for portability on day one. Anchor your pilot on VCDM 2.0, OID4VCI/OID4VP, SD‑JWT, Bitstring Status Lists, NIST 800‑63‑4, and a trust‑registry model. That’s how you deliver results in 90 days—and ensure your next wallet, verifier, or even ledger can plug in without uprooting everything you just built. (w3.org)