TradePactID Lookup Privacy: How Hash-Only Verification Protects Invoice Data

When a business counterparty looks up a TradePactID on tradepact.network, the public verification system operates under strict cryptographic and architectural data minimisation rules. The public lookup surface is permanently restricted to five non-sensitive operational fields: the canonical TradePactID, a publisher-masked invoice number, an invoice issue date, a tripartite settlement status, and the identity of the managing network participant. TradePact Network never ingests, stores, indexes, or displays commercial trade secrets such as counterparty corporate identities, invoice currency, line-item itemisations, monetary totals, banking coordinates, or collection correspondence history.

This technical governance guide is written for accounts payable leads, financial controllers, corporate treasurers, and enterprise legal counsels evaluating how TradePactID verification functions. It examines the architectural seam between participant enterprise systems and the public status projection, the SHA-256 cryptographic digests ensuring immutable state verification without database leaks, the publisher-side masking protocol, and the anti-enumeration protections guarding against commercial scraping.

Key Takeaways

• Strict Five-Field Closed Contract: The public status projection renders exactly five metadata fields (tradePactId, invoiceNumber, invoiceDate, status, and participant). It is architecturally prohibited from holding or rendering creditor names, debtor names, monetary values, line items, or payment details.
• Publisher-Side Masking Enforced at Ingestion: Invoice numbers are masked by the managing participant before crossing the network seam (e.g. INV-••••-89). Unmasked invoice numbers are rejected outright with an ingestion error, ensuring cleartext identifiers never touch public storage.
• SHA-256 Cryptographic Projection Digests: State reconciliation relies on a 32-byte hexadecimal publishedRecordDigest. When an invoice state remains unchanged, reconciliation sweeps execute zero database writes, preventing unnecessary audit churn and ensuring tamper evidence.
• Zero-Callback Content-Addressed Logos: Participant brand logos are stored and served immutably via participantLogoKey content hashes at /participant-logo/<hash>. The status site makes zero network callbacks to private participant infrastructure, preventing IP tracking or visitor reconnaissance.
• Byte-Identical Anti-Enumeration Oracles: All query misses—whether malformed identifiers, unregistered references, or internal lookup failures—return a byte-identical 404 response with noindex and no-store headers, preventing brute-force enumeration of registered commercial accounts.

---

What is the Five-Field Public Contract on TradePact Network?

The public status projection at tradepact.network is governed by a strict, closed schema that explicitly defines everything the network can say about a registered invoice. Under TradePact Protocol v1.0, the projection server does not operate an invoice lifecycle engine, does not track bilateral chaser communications, and does not record commercial balance sheets. Instead, it serves as an authoritative public ledger projection of an already computed state supplied by an authorised network participant.

In the core codebase of TradePact Network (specifically within codebase/TradePact/src/public-record.ts), the public interface TradePactPublicRecord is assembled field-by-field. The application is architecturally prevented from spreading database rows or reflecting additional attributes into the HTTP response. If a participant's internal database contains proprietary trade secrets, those fields cannot reach the public projection because the network parser enforces a hard structural constraint.

Because the contract is closed at both the database schema level (via SQL column constraints) and the application layer, the network cannot be modified to display sensitive commercial figures without breaking protocol compilation.

---

What Commercial Information is Never Exposed on TradePact Network?

Enterprise finance teams and procurement directors routinely express valid concerns regarding commercial surveillance, competitive intelligence leaks, and customer list exposure. When an invoice notice references a TradePactID, the counterparty must be assured that verifying the reference will not expose their commercial dealings to competitors or the wider public.

TradePact Network guarantees that the following sensitive data points are never ingested, stored, processed, or rendered on tradepact.network:

1. Creditor and Debtor Corporate Identities: The public status page never discloses the issuing supplier, the buyer, the parent group, or individual employee contacts. A stranger inspecting a TradePactID lookup cannot determine who owes money to whom.
2. Monetary Amounts and Currencies: Neither the face value of the invoice, the remaining outstanding balance, partial payment instalments, collection fees, nor the underlying transaction currency are ever stored or displayed.
3. Commercial Line Items and Contract Specifications: Descriptions of deliverables, software license counts, hourly service rates, product SKUs, project milestones, and contractual delivery terms remain strictly within private accounting systems.
4. Banking Coordinates and Settlement Accounts: Bank account numbers, SWIFT/BIC codes, sort codes, and IBANs are never published. Payment directions remain governed by bilateral invoices and accredited brand portals (pay.<domain>), eliminating public surface vector tampering.
5. Communication Logs and Dispute Notes: Bilateral emails, telephone notes, reminder intervals, and dispute flags exchanged under the protocol are never reflected on the public lookup surface.

---

How Does Publisher-Side Masking Enforce Invoice Number Privacy?

A common vulnerability in public status tools is client-side masking, where an application fetches cleartext data over an API and visually conceals characters using JavaScript or CSS styling. In such flawed architectures, any visitor can inspect browser network traffic to read unmasked corporate identifiers.

TradePact Network eliminates this vulnerability through mandatory publisher-side masking. The public projection host refuses to accept cleartext invoice numbers. Under codebase/TradePact/src/seam/validate.ts, the network seam inspects every inbound projection row and confirms that invoiceNumber includes TRADEPACT_MASK_CHAR (Unicode bullet \u2022). If an unmasked invoice number is supplied, the ingestion seam rejects the update immediately.

The masking character TRADEPACT_MASK_CHAR is defined as Unicode bullet character •. The participant's upstream system must redact the interior identifying digits—for example, converting INV-849201-UK into INV-••••-01-UK—prior to transmission across the seam. If a participant attempts to publish an unmasked identifier, the ingestion seam rejects the entire update with a protocol validation error. Cleartext invoice numbers never cross the seam, never enter the database, and cannot be retrieved through memory dumps or network interception.

This design guarantees that a counterparty holding the original commercial invoice can instantly correlate the masked reference with their internal accounts payable ledger, while an unauthorised third party possessing only the TradePactID cannot reconstruct the issuing organisation's invoice nomenclature.

---

How Do Cryptographic Hashing and Seam Reconciliation Work?

To maintain synchronisation between participating enterprise platforms and the public network without exposing underlying databases to continuous write locks, TradePact Network implements dual SHA-256 cryptographic hashing mechanisms: the publishedRecordDigest and the participantLogoKey.

1. State Idempotency via publishedRecordDigest

Every five minutes, the network reconciler executes a background synchronization sweep across registered invoice records. To prevent database thrashing and eliminate the risk of race conditions, the reconciler evaluates the cryptographic digest of the record rather than inspecting individual column strings.

As implemented in codebase/TradePact/src/db/records.ts, the digest is generated using SHA-256 over a canonical JSON array containing the exact rendered fields (tradePactId, invoiceNumber, invoiceDate, status, participantName, and participantLogoKey).

By comparing the 32-character hexadecimal digest of the incoming record against the existing stored digest, the system achieves perfect idempotency: a reconciliation sweep over a network of 500,000 unchanged invoices results in read-only verification with exactly zero database write operations. When an invoice transition occurs (such as an overdue balance being marked Paid), the digest changes, causing an atomic update to the projection row.

2. Zero-Callback Privacy via Content-Addressed participantLogoKey

In conventional web architectures, displaying a partner's logo often involves linking to a remote URL hosted on the partner's infrastructure (e.g. https://participant-brand.com/assets/logo.png). In an invoice status verification context, this creates a severe privacy leak: whenever an accounts payable clerk looks up an invoice, their browser would fetch the image from the participant's private server. The participant could log the clerk's IP address, referer header, timestamp, and geolocation, effectively creating an unmonitored tracking mechanism.

TradePact Network eliminates visitor tracking through content-addressed asset ingestion. When a participant registers its brand identity, its raw image bytes (PNG, SVG, or WebP up to strict size thresholds) are transmitted across the authenticated seam. The database generates a content hash of the MIME type and image data.

The public website serves the resulting image directly from its own origin under an immutable content path: /participant-logo/<hash>. Because the image URL changes only when the underlying image bytes change, the asset is cached indefinitely by intermediate proxies and web browsers (Cache-Control: public, max-age=31536000, immutable). The status projection never initiates an outbound network callback to third-party servers, guaranteeing that counterparty verification lookups remain completely private.

---

How Does Anti-Enumeration Prevent Scraping and Debtor Oracles?

A critical risk for public verification portals is automated scraping. Malicious actors or aggressive credit searchers might attempt to query sequential references (e.g. testing 20260813000001A through 20260813000999A) to compile a registry of active corporate disputes or debt collection volumes.

TradePact Network neutralises automated enumeration through three defensive layers:

1. Byte-Identical 404 Not Found Responses

In standard web applications, a missing database row often yields a generic error, while a malformed request yields a syntax error, and an unauthorized request yields an authentication prompt. Attackers exploit these subtle differences—known as timing or error oracles—to determine whether an entity exists in a database.

Under TradePact Network (codebase/TradePact/src/site/pages.ts), the lookup router implements a parameterless renderNotFoundPage() function. Every non-existent record—whether an unassigned TradePactID, a syntactically invalid input, an internal query exception, or an unregistered internal record—renders the exact same byte-for-byte HTML payload without reflecting user-supplied input. Attackers receive zero contextual clues regarding database contents.

2. Search Engine Indexing and Archive Prohibitions

Every lookup response (both 200 OK record pages and 404 Not Found responses) carries strict HTTP security headers that prevent search engine web crawlers from indexing transaction lookups:

• X-Robots-Tag: noindex, nofollow, noarchive, noimageindex
• Cache-Control: no-store, max-age=0
• Referrer-Policy: no-referrer

Furthermore, individual TradePactID record routes are programmatically excluded from tradepact.network/sitemap.xml. Only public educational guides under /learn and static root informational pages are submitted for search engine indexing. A business's invoice reference can never appear in public search engine result pages.

3. Sparse, Non-Sequential Identifier Spaces

TradePactIDs utilize high-entropy identifier construction incorporating timestamp seeds, randomised batch segments, and check characters (e.g. 20260813000001A). Attempting to guess valid identifiers across the network's sparse keyspace yields an overwhelming ratio of 404 responses, which are subject to automated rate limiting and edge-level firewall throttles.

---

Why is TradePact Network Non-Custodial?

Commercial finance departments frequently confuse shared receivables frameworks with payment gateways, escrow agents, or debt collection agencies. A fundamental tenet of the TradePact Protocol is its non-custodial structure.

Under TradePact Protocol v1.0 (effective 1 January 2026):

• Zero Fund Custody: TradePact Network, its operating company (ChaseFlow Pte Ltd, Singapore), and its accredited participant brands never hold, route, or intermediate invoice settlement funds. Debtors and paying counterparties transfer settlement funds directly to the creditor's bank account or through the creditor's designated payment merchant.
• Absence of Contingency Enforcement: TradePact participants are strictly prohibited from purchasing debt portfolios, charging contingency percentage commissions on recovered debts, or providing legal enforcement services. This separation guarantees that the network remains an objective, neutral verification protocol rather than an adversarial collection apparatus.
• Decoupled Verification vs. Payment Relays: The public status projection exists solely to provide truth in invoicing. When a paying entity verifies an invoice as Unpaid, they are directed to resolve payment through official bilateral channels or accredited participant portals (pay.<domain>), ensuring complete isolation of monetary settlements from public directory lookups.

---

Frequently Asked Questions

Does searching a TradePactID notify the creditor or create a collection record?

No. Querying a TradePactID on tradepact.network is a passive, read-only lookup against the public projection table. The status site does not require user authentication, does not set tracking cookies, and does not broadcast notifications to the creditor or participant when a record is viewed.

Why does the status lookup show 'Unknown' instead of 'Paid' or 'Unpaid'?

In the TradePact Protocol, Unknown is not an application failure; it is an honest protocol state. It indicates that the managing participant has not received an authoritative bank reconciliation file or confirmation of payment from the creditor. Rather than making unverified assumptions, the protocol explicitly communicates that settlement status cannot be definitively confirmed.

Can our competitors look up our company name or transaction volume on TradePact?

No. TradePact Network never stores or publishes creditor names, debtor names, commercial contract values, or aggregate invoicing counts. Even if a third party obtained a valid TradePactID, the lookup page displays only the masked invoice number (e.g. INV-••••-89), the issue date, and the managing participant, leaving the underlying commercial transaction entirely confidential.

Is TradePact Network compliant with data protection regulations?

TradePact Network operates under strict data minimisation principles designed to respect international privacy frameworks, including the Singapore Personal Data Protection Act (PDPA). The public lookup displays zero personally identifiable information (PII) and no corporate identities. However, in accordance with team governance rules, TradePact does not issue blanket claims of compliance (such as declaring the platform 'fully compliant' or 'GDPR compliant'); legal counsels should review the specific protocol data architecture outlined in this guide.

How quickly does an invoice status update on the network once paid?

Once the managing participant reconciles a payment in its primary ledger, the update is queued for transmission across the authenticated seam. The network reconciler runs background sweeps every five minutes. Most status updates reflect publicly within minutes of reconciliation, subject to a protocol staleness cutoff of six hours if synchronization is interrupted.

What should an accounts payable team do if a TradePactID returns 'No record found'?

A 'No record found' result indicates that the reference was either typed incorrectly, belongs to an internal invoice not registered under the TradePact Protocol, or has been purged. Because many invoices are handled through bilateral ERP systems without network registration, a missing record does not imply invalidity or fraud. Counterparties should verify the reference with the invoice issuer.

---

Next Steps and Protocol Specifications

For enterprise finance teams, software vendors, and platform operators seeking deeper technical specifications on the TradePact Network architecture:

• Review the Protocol Standards: Access the full governance framework and participant requirements at TradePact Protocol v1.0 Specification.
• Verify an Invoice Reference: Inspect a live status record using our non-custodial lookup tool at TradePact Network Status Lookup.
• Participant Integration Inquiries: Explore how billing platforms and accounting software providers become accredited participants by contacting participants@tradepact.net.
• Related Architecture Guides: Read our accompanying guide on Understanding TradePactID Status States (Paid, Unpaid, Unknown) and Reconciliation Timing.