Can you trust a digital file?
Vera is a decentralized platform that lets anyone instantly verify whether a document, dataset, or media file is genuine — no middleman, no fees, no blockchain expertise required.
The problem with trusting digital files
Every day, contracts are signed, research datasets are shared, and images are used as legal evidence. Yet recipients often have no reliable way to confirm whether a file is genuine, whether it has been altered, or whether it came from a legitimate source. AI-generated content and powerful editing tools have made convincing forgeries cheaper and faster to produce than ever.
Current solutions rely on centralized institutions — a notary, a platform, an email chain — that introduce delays, costs, and single points of failure. Early blockchain approaches can prove a file existed at some point, but they can't answer the questions that actually matter:
🔒 Centralized verification
Requires trusting a third party (notary, platform, institution). Introduces recurring fees, delays, and a single point of failure. The verifier must trust the intermediary, not the evidence itself.
⛓️ Simple blockchain (before Vera)
Stores a hash on-chain as a timestamp. Proves a file existed — but can't confirm who registered it, whether they were authorized, or whether it is still valid today.
Vera closes these gaps. It records cryptographic fingerprints — not the files themselves — on the Ethereum blockchain, alongside issuer identity and a live validity status. Anyone can verify in seconds for free. Issuers can revoke or update records anytime. The full audit history is permanently preserved on-chain.
Who is Vera for?
Vera is designed for three groups that currently lack a reliable, low-cost verification option:
Institutions & Issuers
Universities issuing credentials, agencies certifying compliance documents, companies distributing signed datasets — any authorized entity needing a tamper-proof record.
Asset Holders
Individuals who receive a credential or certified file and need to share proof of its validity with employers, regulators, or partners.
Third-Party Verifiers
Anyone who receives a file and needs to confirm it's genuine — a hiring manager checking a certificate, a journal reviewing a dataset, a journalist verifying an image. No account required.
Scope: what Vera does and doesn't do
In scope
- Hash registration on public EVM blockchains
- Documents, datasets (CSV), images, video
- Issuer authorization & role-based governance
- Revocation and lifecycle state management
- Free, wallet-free third-party verification
- Multi-network deployment (3 test networks)
Out of scope
- Storing raw files on-chain (privacy by design)
- Mainnet production deployment (test nets only)
- Legal enforceability of on-chain records
- Fully on-chain role management (current: partial)
- Cross-chain bridging between networks
How the project evolved from Quarter 1 to Quarter 2
Verification without a middleman
Vera's core insight: you don't need to store a file to prove it's real — just its fingerprint. A cryptographic hash is a unique fixed-length string computed mathematically from a file's exact contents. Change one byte, and the hash changes completely. Vera stores these fingerprints on-chain so anyone can verify them forever.
Built with (tools and frameworks used):
Built by the team: smart contracts, mobile app, database layer, deployment. External dependencies: Supabase (backend-as-a-service), WalletConnect (wallet integration), OpenZeppelin (contract security patterns), Expo (React Native toolchain).
System architecture
Fig. 1 — High-Level System Architecture of Vera. Three layers: (1) web interface with application logic handling local hashing and wallet connections, (2) Ethereum smart contracts for on-chain verification, (3) off-chain Supabase database for user metadata and role governance. Raw files never leave the user's device.
Three roles, one infrastructure
🏛️ Issuers
Authorized organizations who register, update, or revoke assets. Connect a crypto wallet (via WalletConnect) to sign blockchain transactions. Responsible for governance of their registry.
🙋 Asset Holders
Individuals assigned a verified asset. Can view verification details and share a proof link with anyone who needs to confirm the asset's current status.
🔍 Verifiers (open access)
Anyone, anywhere — no account, no wallet, no fees. Upload a file, get an instant answer: Active, Revoked, or Not Registered.
How an issuer registers an asset
The raw file never leaves the issuer's device. Only the SHA-256 hash and metadata go to the blockchain:
Fig. 2 — Asset Registration Workflow. SHA-256 hashing runs locally on the device (no file upload). The 256-bit hash digest and structured metadata (issuer address, timestamp, asset type, status flag) are committed to the appropriate registry contract after the smart contract confirms issuer authorization.
Technical detail: SHA-256 hashing and what gets stored on-chain
SHA-256 (NIST FIPS 180-4) produces a 256-bit digest with two properties that make it ideal here:
- Collision resistance: computationally infeasible to find two different files with the same hash.
- Pre-image resistance: the original file cannot be reconstructed from its hash — privacy is preserved even for sensitive documents.
Each on-chain record stores: the SHA-256 hash, issuer wallet address, registration timestamp (block time), asset type flag, and a validity status (Active/Revoked/Superseded). For datasets, an optional version identifier is included. For media, format metadata is stored alongside. Raw file content is never on-chain — even a 4 GB video produces the same 32-byte on-chain footprint as a short text file.
How anyone can register a file (free, no account needed)
Fig. 3 — Third-Party Verification Workflow. All verification is a read-only blockchain call — zero gas fee, no wallet, no account required. The system returns one of three states: Active (valid), Revoked (invalidated by issuer), or Not Registered (no record found).
Smart contract architecture
A RegistryFactory contract spawns separate registries for each asset type. Each registry maps SHA-256 hashes to structured verification records. Modular design means registries for different asset types can evolve independently.
Fig. 4 — Multi-Registry Smart Contract Architecture. One access control layer governs three independent registries. All three share a common revocation mechanism. Registry templates enforce an onlyOwner modifier for state-changing operations.
Technical detail: hybrid on-chain / off-chain governance
Vera uses a two-layer governance model:
- On-chain (EVM-enforced):
onlyOwnermodifier restricts registration and revocation to the contract owner's wallet. Cannot be bypassed. - Off-chain (Supabase RLS): Admin vs. User role distinctions enforced at the database layer. Admins can register and revoke; standard users can only view and verify. Registry owners can add/remove admins without any contract redeployment.
Tradeoff: more flexible governance, but not fully decentralized. Future work will migrate role management on-chain using OpenZeppelin AccessControl patterns to eliminate the Supabase dependency.
Asset lifecycle: more than a timestamp
Vera models verification as a dynamic state. Assets transition between states; records are never deleted, preserving a full audit trail at every point in time.
Fig. 5 — Asset Lifecycle State Model. The Active → Revoked transition updates a status flag rather than deleting the record. Historical queries for any point-in-time status remain possible, supporting compliance and audit workflows.
Deployed on three public test networks
Contracts were validated on three EVM-compatible public test networks to confirm cross-chain portability and real-world behavior under live network conditions:
Polygon PoS was selected as the primary network: ~$0.01 transaction fees, ~5-second finality, 92+ TPS sustained — well-matched to a system that writes infrequently (registration, revocation) and reads constantly (free verification queries).
What we proved it can do
All evaluation was conducted on live public test networks — not local simulation — with real network latency, gas variability, and concurrent traffic. This validates that the system works under production-like conditions, not just in a controlled lab environment.
✅ 100% Registration Accuracy
Across all three asset types, computed SHA-256 hashes consistently matched on-chain records post-confirmation. Identical files always produced identical hashes; any single-byte modification produced a completely different fingerprint — zero collisions observed.
🔒 Governance Enforcement Confirmed
Unauthorized users were blocked from restricted operations by the combined onlyOwner on-chain check and Supabase RLS policy. Authorized admins successfully completed full registration and revocation workflows in all tested scenarios.
🔄 Lifecycle Transitions Reliable
Assets were registered, assigned, updated, and revoked across all test networks. Revoked assets remained queryable for audit purposes but returned a clear "Revoked" status. No destructive overwrites — full history preserved on-chain.
⚡ Free Third-Party Verification Works
Verifiers confirmed authenticity with zero gas fees and no wallet. Modified files returned "Not Registered"; unregistered files returned negative responses; revoked assets returned "Revoked" — all without requiring any authentication or account.
📱 End-to-End Workflows Validated
Full user workflows — Supabase auth → WalletConnect wallet signing → RegistryFactory creation → asset registration → third-party verification — executed successfully on all three test networks inside the React Native mobile app.
👤 Usable Without Blockchain Knowledge
Test participants completed both issuer and verifier workflows with no prior blockchain experience. Cryptographic operations and transaction signing were fully abstracted behind clear guided UI steps, confirmed through usability testing.
Network performance: why Polygon?
Measurements taken on live public test networks. Polygon was chosen for finality speed and cost — critical for a system where verifiers need near-instant results.
| Metric | Polygon PoS ✓ Selected | Arbitrum |
|---|---|---|
| Real-time throughput (TPS) | ~92.6 TPS | ~34.9 TPS |
| Max observed throughput (100-block window) | 537.5 TPS | 2,036 TPS (burst) |
| Average block time | ~2 seconds | ~0.25 seconds |
| Transaction finality | ~5 seconds | ~13 min 48 sec * |
| Avg. transaction fee | ~$0.01 USD | Variable |
| 24-hour transaction volume | 9.7 million | — |
| Network utilization (headroom) | 65% (35% remaining) | — |
| Total ecosystem addresses | 569 million | — |
* Arbitrum's ~14-minute finality is due to its optimistic rollup settlement mechanism: a ~7-day fraud-proof challenge window with practical finality at ~14 minutes. Unsuitable for real-time verification use cases.
Known limitations — acknowledged honestly
Current limitations
- Partial off-chain governance: Fine-grained role management depends on Supabase RLS. If Supabase is unavailable, admin workflows break (on-chain records remain intact and publicly queryable, but new registrations cannot be authorized). Full decentralization requires on-chain role logic.
- Test network only: Validated on test networks with free test tokens. Mainnet deployment faces real gas costs and requires a professional security audit before production use.
- Gas variability on writes: Registration and revocation costs are ~$0.01 on Polygon but are subject to congestion spikes during peak network usage.
- No content search or discovery: Vera verifies a specific file you already have. It does not provide search, browsing, or retrieval of registered files.
- Factory pattern upgrade complexity: The RegistryFactory abstraction requires careful coordination during contract upgrades to avoid orphaned registries without migration paths.
Conclusion: what this means
Vera demonstrates that a decentralized verification system can simultaneously achieve correctness, usability, and governance flexibility — three properties prior systems have consistently struggled to combine. It advances beyond static proof-of-existence to support full lifecycle management across heterogeneous asset types on live public blockchains.
The key contribution is the hybrid governance architecture: on-chain ownership constraints provide tamper-proof anchoring, while off-chain RLS policies enable the dynamic, institution-friendly governance that real-world deployments require — without redeploying contracts for every governance change.
Deployment implications: Vera is ready for pilot deployment in institutional contexts (university credential issuance, research data certification) pending two prerequisites: (1) a smart contract security audit, and (2) migration of role management logic on-chain for full decentralization. Polygon's ~$0.01 registration cost makes it economically viable for high-volume issuers.
Next steps: On-chain role management via OpenZeppelin AccessControl; mainnet cost benchmarking; IPFS integration for off-chain storage to reduce Supabase dependency; ZK-proof extensions for selective attribute disclosure.
Full discussion: design tradeoffs and architectural decisions
RegistryFactory pattern: Dynamic instantiation allows any issuer to create their own registry without the team redeploying contracts. Tradeoff: additional gas at registry creation and more complex version management for upgrades.
Why Supabase auth instead of on-chain identity (ENS / DIDs)? On-chain identity would add friction for non-crypto-native institutions. Supabase email/password lowers the barrier for adoption; WalletConnect handles the cryptographic transaction signing that actually matters for security. Decentralized identity is identified as a future improvement.
Why not store files on IPFS? The current prototype uses Supabase object storage for off-chain file hosting. IPFS would improve decentralization and reduce vendor lock-in, but adds complexity around content availability guarantees (pinning). Identified as a future improvement.
Why Polygon over Ethereum mainnet? Ethereum mainnet fees would make registration economically impractical (~$5–50 per transaction vs. ~$0.01 on Polygon). Polygon's PoS architecture provides sufficient decentralization (105 validators, Nakamoto coefficient of 4) for a verification use case.
Demo Video
The Team Behind Vera
Contact the team
Tools, libraries & citations
Smart contract security patterns: OpenZeppelin. Backend auth & storage: Supabase. Wallet integration: WalletConnect. Mobile framework: Expo / React Native. Cryptographic standard: NIST FIPS 180-4 (SHA-256). Architecture influenced by Blockcerts (MIT Media Lab) and the W3C Verifiable Credentials Data Model v2.0. Ethereum platform: Ethereum Foundation. Layer-2 deployment: Polygon and Arbitrum.