BlockProcure

BlockProcure started from a frustratingly common problem in public infrastructure projects:

Payments are often trusted more than the work itself.

Invoices get duplicated, milestones get approved without proper verification, and audit trails live in spreadsheets controlled by the same parties being audited.

So instead of relying on manual approvals and opaque workflows, I built a procurement system where payment release becomes mathematically constrained by smart contracts.

No hidden approvals.
No editable records.
No central intermediary deciding when funds move.

The problem

Infrastructure procurement workflows are still heavily dependent on paperwork and centralized approval chains.

That creates predictable failure points:

• duplicate invoice submissions
• forged quality certificates
• milestone payments released without verification
• audit trails that can be altered after the fact

Most systems discover fraud months later during audits — after the money has already moved.

What we built

• On-chain escrow vault — government funds stay locked until milestone conditions are satisfied.
• Multi-inspector approval system — payments require M-of-N independent inspector signatures before release.
• Immutable audit trail — every approval, invoice submission, and payment release emits permanent on-chain events.
• Duplicate invoice detection — suppliers submit invoice hashes that are checked against previous submissions automatically.
• Role-based procurement workflow — separate permissions for governments, contractors, suppliers, inspectors, and regulators.

The contract surface

Three contracts handle the entire workflow:

contract PaymentVault {
    function lockFunds(uint256 projectId) external payable { /* ... */ }
 
    function logInvoice(
        uint256 projectId,
        bytes32 invoiceHash
    ) external { /* ... */ }
 
    function release(
        uint256 projectId,
        uint256 milestoneId
    ) external { /* ... */ }
}

The contracts coordinate milestone verification, escrow management, and role-based access across the procurement lifecycle.

Decisions worth calling out

• Polygon over Ethereum mainnet — lower fees made repeated approval flows practical during demos and testing.
• Hashing documents instead of storing files on-chain — invoices and reports stay off-chain while their hashes provide tamper detection.
• M-of-N approval thresholds — a single compromised inspector can't unilaterally release payments.
• Event-heavy architecture — regulators can reconstruct the entire procurement timeline directly from emitted events without trusting backend databases.

Trade-offs I made

I intentionally kept document storage off-chain because putting PDFs directly on-chain would have been prohibitively expensive and unnecessary.

I also avoided adding DAO governance or dispute arbitration logic initially. Those systems become complicated very quickly, and I wanted the core escrow + milestone workflow to stay understandable and demoable first.

What it taught me

This project made me think differently about smart contracts.

The hard part usually isn't writing Solidity — it's designing systems where incentives, permissions, and state transitions cannot accidentally break under real-world usage.

A lot of blockchain engineering is really about reducing trust assumptions and making business logic enforceable by code instead of policy.