What operational signals are
Traditional trade finance underwrites on financial proxies: credit score, balance sheet, historical revenue. These tell you the operator's general ability to pay, not their specific ability to execute the trade in front of you. Operational signals invert this: instead of asking what the operator looks like on paper, they measure what the operator actually does in practice.
Each signal is computed from the operator's real activity on TradeOS, derived from attestor-signed events (eBL, customs entries, QA reports, payment confirmations), and hashed for audit. The operator cannot manipulate the signal; it is the byproduct of running the business, not a self-reported metric. Financiers see signals updated per event, not per quarter, and can drill down to the underlying evidence trail from any signal value.
The six core signals
PASS vs NEED_MORE vs FAIL).How signals are computed
Every signal traces back to attestor-signed events on the rail. The supplier reliability score, for example, is computed from the timestamps on the On-Board, Customs, Delivered, and Arrival/QA PASS events; those timestamps were attested by independent title attestors, customs brokers, forwarders, and QA labs respectively. The signal is just an aggregation of those primary facts.
Because the events are on-chain and hashed, financiers can drill from any signal value back to the raw evidence. A reliability score of 94% means: across the operator's last N completed orders, 94% of milestones hit their target dates within the corridor SLA. Click the score, see the orders, see the milestones, see the attestor signatures, see the evidence files. The signal is auditable. No proxy, no inference, no proprietary model the operator can't see.
- Event1Operational event captured on TradeOSA milestone fires: a bill of lading is signed, a customs entry is filed, a QA report is uploaded. Each event carries a timestamp, an evidence payload (file hash + structured metadata), and a target date from the corridor SLA.Event payload assembled with structured metadata and file hashes.
- Sign2Attestor signs and PoV Gate evaluatesThe relevant attestor (title attestor, customs broker, forwarder, QA lab, or independent inspector) signs the event. The PoV Gate evaluates the four conditions: quorum, role diversity, equality of evidence, one-claim exclusivity. If PASS, the event is canonical.Attestor signature applied to the event hash;
proof.submit(evidence). - Anchor3Event hash anchored on L1EDMA L2 batches the event into the next epoch and anchors the Merkle root to Ethereum via EIP-4844 blobs. Auditors can reconstruct any signal from Ethereum alone. The on-chain anchor is what makes a signal verifiable rather than asserted.EIP-4844 blob anchors the epoch's Merkle root. Cadence: 2–10 minutes.
- Aggregate4Signal recomputed across operator historyThe operator's rolling window of canonical events feeds into the signal's aggregation formula. Reliability is a recency-weighted on-time percentage; dispute rate is a 12-month rolling count; maturity is a composite of three sub-indicators. Signals update per event, not per quarter.Aggregation runs on every new canonical event; new score posted to the signal pack.
- Drill5Financier reads the signal, drills to evidenceIn the listing view (pre-disclosure) or portfolio dashboard (post-funding), the financier sees the signal value and clicks to drill: the orders, the milestones, the attestor signatures, the underlying evidence files. The drill terminates at primary evidence, not a black-box score.Evidence retrieved via short-lived signed URLs; on-chain hashes confirm authenticity.
Why this beats credit-score underwriting
Credit scores were designed for consumer lending and adapted, awkwardly, to trade. They tell a financier whether the operator generally pays bills on time. They do not tell the financier whether this specific shipment of these specific goods through this specific corridor will hit milestones on schedule. The two questions have different answers.
Operational signals answer the second question directly. They also update per event, not per quarter; cover the specific corridor and product category, not the operator in general; and trace back to verifiable evidence, not a proprietary score. For trade finance, this is the first underwriting fabric since the letter of credit was invented. Credit scores will not go away; financiers will use both. But the marginal underwriting decision (do I fund this deal at this rate) is made on operational signals.
Updates: quarterly or annually, on filing cadence.
Inputs: financial proxies (revenue, balance sheet, payment history with credit reporters).
Granularity: the operator in general, not this specific shipment in this specific corridor.
Verifiability: proprietary scoring model the operator cannot see or replay.
Limitation: tells the financier nothing about whether this trade will execute on schedule.
Updates: per event, not per quarter. New PoV PASS, new score.
Inputs: attestor-signed milestone timestamps, dispute events, document acceptance rates, real activity on the rail.
Granularity: per corridor, per product category, per counterparty type.
Verifiability: every score drills to primary evidence on L1; no black-box model.
Strength: direct measurement of trade execution rather than financial proxy.
Where it stands today
The six core signals are already computed in TradeOS production for operators on the platform; the signal API is the integration target for the Marketplace surface in Stage 3 (Nov 2026 – Jan 2027). v1 of the Marketplace exposes signals with read access; v2 adds signal-based filtering, mandate matching, and alerts when an operator's signal pack matches a financier's open mandate.
