The problem ProcureShield solves

Traditional group purchasing forces buyers to reveal their maximum budgets to a central coordinator in order to aggregate demand. That creates three systemic risks.

Price exploitation. Suppliers anchor to visible ceilings instead of bidding competitively.

Competitive intelligence leakage. Buyers in the same pool are often competitors. Exposing procurement budgets creates strategic and contractual risk.

Trust bottleneck. All sensitive data sits with one coordinator. Compromise or distrust them and the entire negotiation collapses.

ProcureShield removes this tradeoff using the privacy model of the Canton Network.

With sub transaction privacy in DAML, buyers pool demand without exposing individual max prices. Each contract defines explicit signatories and observers, and nodes only receive data they are authorized to see. A supplier never receives the bytes representing a buyer’s maxPrice.

In practice, buyers submit sealed purchase orders. The operator aggregates only total volume and batch constraints. The supplier bids on aggregate demand without visibility into individual ceilings. Each buyer’s contract automatically accepts, or rejects based on their private maxPrice. Fulfillment executes without revealing buyer identities or price ceilings.

The result is competitive pricing with privacy guarantees enforced at the protocol level, not by trust in a coordinator.

Challenges we ran into

The hardest challenge was accurately modeling Canton’s node level privacy in a standalone frontend environment.

Canton enforces selective disclosure at the node level. In the mock service, I had to replicate those authorization rules manually in TypeScript for each contract type, party role, and workflow step. Across eight demo steps and multiple contract types, this created many edge cases. Running full end to end simulations surfaced visibility errors where a party could see something they should not, or could not see something they should. The final mock service explicitly enforces redaction rules per party and per contract.

Another challenge was rapid iteration on our web extension and developer docs, specifically refining how it detects a product on a supplier site and transfers it into our system.

We wanted the extension to feel seamless. A buyer should be able to browse normally, click once, and have the product metadata, pricing context, and supplier information pulled into ProcureShield without manual copy paste. Achieving that required reliable product detection across inconsistent page structures.

Different supplier sites structure product data differently. Some expose clean metadata. Others require DOM parsing and heuristic matching. We had to build flexible extraction logic that could handle variations in layout, dynamic rendering, and partial data availability while avoiding false positives. Small selector changes could break detection entirely, so we iterated on a more resilient parsing strategy.

There were also architectural considerations. The extension runs in a constrained browser environment, while ProcureShield operates as a separate application. We needed a secure messaging bridge that passed only the necessary product data into our system without exposing session context or leaking unrelated page information.

From a market fit perspective, the extension significantly reduces friction. Instead of asking buyers to manually recreate purchase orders inside a new system, we meet them where they already operate. That makes adoption more realistic and lowers switching costs. The technical complexity was worth solving because seamless capture is critical to real world usability.

Use of AI tools and agents

No implementation of Agents is physically used in our projects. Our developer docs are tailor made so that other companies purchasing/assistant/miscellaneous assistants can directly make use of our product. We don't use it, but we also have our project built to be AI and developer native with our docs.