Skip to content
BlindBid

BlindBid

Bids so sealed, even the blockchain can't peek

Created on 21st February 2026

β€’

BlindBid

BlindBid

Bids so sealed, even the blockchain can't peek

The problem BlindBid solves

The Problem

Every year, $13 trillion in global procurement runs through sealed-bid auctions β€” government tenders, enterprise supply chains, infrastructure contracts. The process is fundamentally broken:

πŸ”“ Bids Aren't Actually Sealed

Traditional e-procurement platforms store bids in a central database. Insiders can peek. Competitors collude. A single compromised admin can leak every bid in the system. Studies estimate bid-rigging costs taxpayers 20-30% in inflated prices on public contracts alone.

🀷 Winners Can't Be Verified

When the award is announced, losers have no way to verify the scoring was fair. Was the formula actually applied? Did the winner really score highest? The process is a black box β€” and disputes drag on for months.

πŸ’Έ Payments Are Disconnected

After the award, settlement happens off-platform β€” wire transfers, invoices, manual reconciliation. There's no programmatic link between "you won the auction" and "here's your payment." Escrow is handled by intermediaries who charge 1-3% fees.


What BlindBid Solves

BlindBid is a privacy-first sealed-bid auction platform where:

1. Bids Are Cryptographically Private

Bidders submit sealed bids on Canton Network using Daml smart contracts. Privacy isn't a feature flag β€” it's enforced at the ledger level. BidderA physically cannot see BidderB's bid. Not through the UI, not through the API, not through the database. The data simply doesn't exist in their view of the ledger.

2. Scoring Is Transparent Without Exposing Data

The seller scores bids using a multi-criteria weighted formula (price, delivery, penalty rate, reputation) locked into the smart contract before bidding opens. The winner receives an explainable award proof showing which criteria were used and weight ranges β€” but actual bid values are never revealed to losing bidders. You know the process was fair without seeing anyone else's numbers.

3. Payments Are On-Chain and Gasless

Winners pay through an ADI escrow smart contract with real on-chain settlement. Bidders don't need tokens or gas β€” an ERC-4337 paymaster sponsors every transaction. The escrow holds funds until the Canton contract confirms all conditions are met, then releases automatically. No intermediaries, no manual wire transfers, no 1-3% fees.

4. Every Step Is Publicly Auditable

At critical moments β€” bidding closed, winner awarded, payment settled β€” a hash commitment is published to Hedera Consensus Service. This creates a tamper-proof public timeline that anyone can verify. The hash proves what happened and when, without revealing any confidential business data.


Who Is This For?

UserHow BlindBid Helps
Government Procurement OfficersRun tenders where bid-rigging is mathematically impossible, not just illegal
Enterprise Supply Chain TeamsScore vendors on multiple criteria privately β€” no more race-to-the-bottom pricing
Construction & InfrastructureSealed bids with automated escrow β€” payment releases when delivery conditions are met
Auditors & RegulatorsVerify the entire auction timeline on Hedera without needing access to confidential bid data
Small BiddersParticipate without holding crypto or paying gas β€” the platform sponsors your transactions

In One Line

BlindBid makes sealed-bid auctions actually sealed, verifiably fair, and settled on-chain β€” with zero gas costs for participants.

Challenges I ran into

Challenges I Ran Into

1. πŸ”’ Canton's Party-Based Privacy vs. Multi-Step Auction Logic

The Problem: Canton's sub-transaction privacy model means each party can only see contracts they're explicitly listed on. This sounds great until you realize that a multi-step auction (create β†’ bid β†’ score β†’ award) involves different parties at different stages. The Seller creates the auction, but Bidders submit bids on separate contracts. When the Seller needs to score all bids, they need visibility into every SealedBid contract β€” but each bid was created by a different party.

How I Solved It: I designed the Daml contract hierarchy so the Seller is listed as an observer on every SealedBid contract at creation time, while other Bidders are explicitly excluded. The scoring choice exercises across all bid contracts in a single Canton transaction, maintaining atomicity. The key insight was that Canton's privacy is per-contract, not per-transaction β€” so one transaction can touch multiple contracts with different visibility rules, and each party only sees the subset they're authorized for.


2. β›½ ERC-4337 Paymaster Integration β€” The "Chicken and Egg" Problem

The Problem: For gasless bidding, bidders need a paymaster to sponsor their gas. But the paymaster needs to validate that the bidder is authorized for this specific auction. The authorization signature has to be generated before the transaction is sent, embedded in

paymasterAndData

, and verified on-chain β€” all without the bidder holding any native tokens.

The Hurdle: Getting the signature encoding right was brutal. The paymaster contract expects a tightly packed

abi.encode(sender, auctionId, validUntil, signature)

inside

paymasterAndData

. One byte off and the entire UserOperation reverts with a cryptic "AA33: reverted" error that gives you zero debugging information.

How I Solved It: I built the sponsor signer as a backend service that generates the exact byte layout the paymaster expects. I wrote the signing logic to match the contract's

getHash()

function byte-for-byte, tested with Foundry's

forge test

to verify signature recovery, and only then wired it into the API. The key was testing the signature flow in isolation before integrating it into the full auction pipeline.


3. πŸ”„ Connecting Two Completely Different Blockchains

The Problem: Canton (Daml/GRPC) and ADI (EVM/Solidity) are fundamentally different systems. Canton uses a ledger model with party-based access. ADI uses an account model with ERC-4337. There's no bridge, no shared state, no native interop. But the auction needs both: Canton for private auction logic, ADI for on-chain payments.

How I Solved It: I built the backend as an orchestration layer that sequences operations across both chains. Canton handles the auction lifecycle (create β†’ bid β†’ score β†’ award). Once Canton confirms the winner, the backend triggers ADI operations (quote β†’ escrow deposit β†’ release). The two chains are linked through the Hedera audit trail β€” each commitment includes both the Canton transaction reference and the ADI transaction hash, creating a verifiable cross-chain timeline.


Tracks Applied (6)

Devtopia

πŸ”“ Bids Aren't Actually Sealed Traditional e-procurement platforms store bids in a central database. Insiders can peek. ...Read More

Best Hiero CLI Plugin (Open Source PR)

Hedera β€” Best Hiero CLI Plugin (Open Source PR) Pull Request: feat(plugin): auctionlog β€” privacy-preserving audit trail...Read More
Hedera

Hedera

Best Privacy-Focused dApp Using Daml

Canton Network β€” Best Privacy-Focused dApp Using Daml Why Auctions Need Canton Sealed-bid auctions have a fundamental ...Read More
Canton Network

Canton Network

ERC-4337 Paymaster Devtools

ADI Foundation β€” ERC-4337 Paymaster Devtools How BlindBid Uses the ADI Paymaster In a sealed-bid auction, bidders shou...Read More
ADI Foundation

ADI Foundation

ADI Payments Component for Merchants

ADI Foundation β€” Payments Component for Merchants The Merchant Payment Problem in Auctions When a bidder wins an aucti...Read More
ADI Foundation

ADI Foundation

Open Project Submission

ERC-4337
ADI Foundation

ADI Foundation

Cheer Project

Cheering for a project means supporting a project you like with as little as 0.0025 ETH. Right now, you can Cheer using ETH on Arbitrum, Optimism and Base.

Discussion

Builders also viewed

See more projects on Devfolio