-
-
logo
-
-
-
-
-
-
Inspiration
OpenContract
Making public contracts verifiable.
About the Project
In my country, public procurement involves some of the largest flows of public money and yet understanding what happened to a contract can be surprisingly difficult sometimes.
A tender is published. Bids are submitted. A supplier is selected. A contract is signed. Payments are made. Amendments happen. Work is eventually completed.
But these events often exist as separate pieces of information.
What if a citizen, journalist, auditor, or contractor could follow the entire story of a public contract in one place — and independently verify that important documents and records had not been silently altered?
That question is what made me think of OpenContract.
OpenContract is a blockchain-backed public procurement transparency and verification platform. It creates a structured, publicly explorable record of a procurement process, while using cryptographic fingerprints and an EVM blockchain to provide an independent verification layer for important events and documents.
It is not intended to replace an existing government procurement system.
Instead, OpenContract acts as an accountability and verification layer around procurement data.
The idea is simple:
Publish → Structure → Fingerprint → Anchor → Verify → Understand.
Why We Built It
We wanted to explore a problem that goes beyond simply putting information on a blockchain.
A blockchain can make a record difficult to alter after it has been anchored.
But that alone does not answer the questions people actually have:
- What was originally published?
- Who was awarded the contract?
- How much was the contract worth?
- Did the value change?
- How much has been paid?
- What milestones have been completed?
- Were there unusual procurement patterns worth reviewing?
- Can a document be independently verified?
- What exactly is stored on-chain?
- Can an AI system explain the record without inventing information?
That led us to a broader architecture.
OpenContract combines:
- Structured procurement data
- Open Contracting Data Standard (OCDS) concepts
- PostgreSQL
- SHA-256 document fingerprinting
- EVM blockchain anchoring
- Deterministic integrity signals
- Grounded Gemini AI analysis
- A public procurement explorer
The blockchain is therefore not the entire product.
It is one part of a larger verification system.
What OpenContract Does
A procurement record moves through a lifecycle:
Planning → Tender → Bidding → Evaluation → Award → Contract → Amendments → Payments → Implementation → Inspection → Completion
OpenContract turns that lifecycle into an accessible public dossier.
A citizen can open a procurement and see its history.
An auditor can inspect amendments, payments, documents and review signals.
A contractor can understand the procurement record surrounding a contract.
A journalist can search across procurements and investigate unusual patterns.
A document can be hashed locally in the browser and compared against a registered fingerprint.
And an AI analyst can answer questions about the procurement using verified application data rather than freely inventing facts.
The Web3 Component
The central Web3 question we asked was:
What information actually belongs on a blockchain?
The answer was deliberately conservative.
We do not put entire procurement documents, private bids, personal information, or sensitive procurement data on-chain.
Instead, OpenContract creates cryptographic fingerprints of relevant records and documents and anchors those fingerprints to an EVM-compatible registry.
The blockchain becomes a tamper-evident reference point.
Conceptually:
$$ Document \xrightarrow{SHA-256} Fingerprint \xrightarrow{} Blockchain\ Anchor $$
Later:
$$ Document_{submitted} \xrightarrow{SHA-256} Fingerprint_{current} $$
If:
$$ Fingerprint_{current} = Fingerprint_{anchored} $$
the document matches the anchored version.
If they differ, the platform can report that the submitted document does not match the registered fingerprint.
This distinction matters.
OpenContract does not claim that a blockchain proves the original document was truthful.
It provides evidence that the document being checked matches—or does not match—the fingerprint that was previously anchored.
That makes the system useful for verification without pretending blockchain solves every governance problem.
What We Built
1. Public Procurement Explorer
OpenContract provides a searchable public explorer for procurement records.
Users can search and filter procurement records by things such as:
- Procurement stage
- Status
- Procurement method
- Organization
- Contract
- OCID
Each procurement has a unique identifier following an OpenContract OCID convention:
ocds-demo-2026-000001
The explorer is designed to make procurement information feel more like a public information system than a blockchain dashboard.
2. Contract Dossiers
Each procurement gets a detailed contract dossier.
Instead of forcing users to understand blockchain transactions or database records, OpenContract presents the procurement as a chronological story.
The dossier can surface:
- Procuring organization
- Supplier
- Contract value
- Procurement status
- Bids
- Award
- Amendments
- Payments
- Milestones
- Documents
- Integrity review signals
- Blockchain anchors
The result is a single place where someone can understand the lifecycle of a public contract.
3. Cryptographic Document Verification
One of our core features is the document verifier.
A user can provide a document and OpenContract calculates its SHA-256 fingerprint directly in the browser.
The document does not need to be uploaded to a server simply to calculate its hash.
The resulting fingerprint can then be compared against registered document fingerprints.
We also built demonstration cases for:
- A matching document
- A registered and blockchain-anchored document
- A modified/tampered version
The modified version intentionally produces a different fingerprint, demonstrating how a seemingly small change can result in a cryptographically different document identity.
4. Blockchain Proof
OpenContract uses Solidity smart contracts and Foundry for the blockchain layer.
The prototype includes:
AccessController.solOpenContractRegistry.sol
The registry is designed to anchor procurement-related fingerprints against an OCID.
The smart-contract test suite currently passes all five tests.
For the prototype, we use Base Sepolia rather than a production network.
This lets us demonstrate the complete flow without pretending that a hackathon prototype is already a national procurement infrastructure.
5. Integrity Review Signals
We wanted OpenContract to do more than display information.
It should also help people notice where they may want to look closer.
We therefore built deterministic integrity signals.
Examples include:
- Single bidder
- Significant contract amendment
- Supplier concentration
- Missing or delayed updates
- Other explainable procurement anomalies
These are deliberately called review signals, not corruption detections.
For example:
Single Bidder — Review Signal
is fundamentally different from:
Corruption Detected
The first tells a human reviewer where to investigate.
The second would make a legal or factual conclusion that our system cannot establish.
Every signal is therefore designed to be explainable and connected to underlying procurement evidence.
6. Grounded AI Procurement Analyst
We also wanted to explore a practical use of AI.
Large language models are excellent at explaining complicated information, but they can also hallucinate.
That is particularly dangerous when discussing public money.
So OpenContract's AI analyst is intentionally constrained.
The analyst retrieves procurement information from the application's live database and uses that structured context to answer questions.
It is designed to:
- Reference real procurement records
- Use OCIDs as evidence identifiers
- Explain amendments and payments
- Discuss integrity signals
- Say when a requested project does not exist
- Avoid inventing procurement facts
For example, instead of asking an AI:
"Tell me everything you know about government contracts in Ghana."
a user can ask:
"What changed in the Tema Motorway Interchange contract?"
The analyst can then work from the actual OpenContract record.
We tested the system with unknown projects and near-matching queries to ensure it does not simply invent an answer when a procurement cannot be found.
7. OCDS-Compatible Data Layer
Procurement transparency requires more than a visually attractive dashboard.
The underlying data needs structure.
OpenContract therefore uses concepts from the Open Contracting Data Standard (OCDS) to structure procurement information across the contracting lifecycle.
This allows OpenContract to expose procurement information through an OCDS-oriented API rather than locking the information inside the frontend.
Our prototype exposes OCDS records with OpenContract-specific extensions for:
- Blockchain information
- Integrity signals
This means the project is designed around interoperable procurement data rather than a proprietary dashboard format.
The Challenges We Faced
1. Making blockchain useful instead of decorative
One of the biggest challenges was resisting the temptation to simply put "blockchain" into the project because the hackathon was Web3-focused.
We had to answer:
What does blockchain actually improve?
That led us to document fingerprints and event anchoring instead of putting entire datasets on-chain.
The result was a much more practical architecture.
2. Preventing AI hallucinations
A procurement analyst that confidently invents a contract value is worse than having no analyst at all.
We therefore had to constrain the AI's information source.
Instead of giving Gemini unrestricted access to the database or allowing it to invent context, the application retrieves controlled procurement information and provides that context to the model.
This also created a useful design principle:
AI explains evidence. AI does not become the evidence.
3. Designing for public trust
Government and procurement interfaces can become overwhelming very quickly.
There are contracts, amounts, dates, organizations, amendments, documents, transactions and technical blockchain information.
We therefore designed the UI around progressive disclosure.
A citizen should be able to understand the basic story.
An auditor should be able to go deeper.
A technically experienced user should be able to inspect the cryptographic and blockchain evidence.
The same record therefore has multiple layers of detail.
4. Handling cryptographic verification correctly
We wanted document verification to be more than a fake "Verified" badge.
The browser calculates the document's SHA-256 fingerprint.
That fingerprint is compared with a registered fingerprint.
The system can therefore distinguish between:
MATCH
and
MISMATCH
rather than simply trusting a UI label.
5. Building a believable demonstration without pretending it is production government data
A hackathon prototype cannot simply connect to every government procurement system and claim nationwide coverage.
So we created a controlled demonstration dataset covering several procurement scenarios, including transportation, healthcare, financial software, education and rural electrification.
The records are designed to demonstrate different lifecycle states and review signals while remaining clearly identifiable as demonstration data.
This allowed us to build the complete technical experience without misrepresenting fictional records as real government transactions.
What We Learned
Blockchain is most valuable when it solves a specific trust problem.
We learned that "putting data on-chain" is not itself a product.
The interesting question is:
What should become independently verifiable, and why?
For OpenContract, the answer is primarily the integrity of published records and documents.
Transparency is a UX problem as much as a data problem.
Even perfectly structured data is useless if ordinary people cannot understand it.
A public transparency system needs to translate technical records into a comprehensible story.
AI needs stronger boundaries around high-stakes information.
The more consequential the information, the less acceptable it is for an AI system to improvise.
Our analyst therefore treats database records and evidence as the foundation and language generation as the explanation layer.
Red flags should invite investigation, not manufacture conclusions.
A single bidder is not automatically evidence of wrongdoing.
A contract amendment is not automatically evidence of wrongdoing.
Supplier concentration is not automatically evidence of wrongdoing.
These patterns can, however, help a reviewer decide where to look.
That distinction influenced the entire integrity engine.
Why OpenContract Is Different
There are many dashboards.
There are many blockchain projects.
There are many AI assistants.
OpenContract brings the three together around a specific workflow:
Discover → Understand → Verify → Investigate
A person can discover a contract.
They can understand its lifecycle.
They can verify the integrity of a document.
They can investigate review signals.
They can then ask an AI analyst to explain the evidence.
The blockchain is not the interface.
The AI is not the source of truth.
The dashboard is not the evidence.
The system connects all three.
What We Would Build Next
The hackathon prototype is intentionally focused.
A production version could extend the platform with:
- Integration with existing public procurement systems
- Official procurement data ingestion
- More comprehensive OCDS coverage
- Institutional publishing workflows
- Digital signatures
- Stronger identity and role management
- S3-compatible document storage
- Independent auditor tooling
- Public API access
- Notification and subscription systems
- Advanced supplier and organization analysis
- Cross-contract analytics
- Additional blockchain networks
- Formal governance around who can publish and anchor records
The long-term vision is not to replace existing procurement infrastructure.
It is to make procurement records easier to inspect, verify, understand and independently audit.
For judges, the fastest way to experience OpenContract is:
- Open the landing page.
- Search for Tema Motorway Interchange.
- Open the procurement dossier.
- Follow the procurement lifecycle.
- Inspect the contract amendment.
- Open the integrity signal explaining the review flag.
- Open the blockchain proof.
- Go to Verify and test a matching document.
- Test the modified document and demonstrate the mismatch.
- Open the AI Analyst.
- Ask: "What changed in the Tema Motorway Interchange contract?"
- Follow the OCID/evidence references in the answer.
This demonstrates the complete OpenContract proposition in a few minutes:
public data → lifecycle → signal → cryptographic verification → blockchain proof → grounded AI analysis.
Built With
- base
- css
- foundry
- gemini
- neon
- next.js
- ocds
- openzeppelin
- postgresql
- prisma
- react
- sepolia
- sha-256
- solidity
- tailwind
- typescript
- viem
- zod
Log in or sign up for Devpost to join the conversation.