Adversarial harness

A worker that tries to pledge the same receivable a second time, continuously, and is refused every time. It runs against the deployed registry with its own funded address, and nothing here is taken on trust: what a refusal means is checked against the registry separately, because the chain publishes one reason code both for a lien that is really there and for a registry that could not be read.

A worker submits the same already-pledged receivable again and again, from its own funded address. Every attempt is refused. Nothing below is served by us: the page reads the inbox and the registry directly, so it keeps answering when our own services are switched off.

submitter: 0xA687F2A567B6d26Dd0E45F08d5ec40f0a25454e7
refused as already pledged: —
refused for another reason: —

Reading the chain.

The same receivable, written differently

Reformatting is refused before it reaches the collision check, not by it. The ledger pins the invoice number, the amount, the currency and the due date, and the enclave replaces the debtor, the issuer and the country with the book's own values — so on chain this can only ever be seven of seven. The scores below are what the index would answer if a reformatted claim ever got that far, computed with the matcher the enclave itself runs.

invoice number with a separator: 7 of 7 — refused
invoice number without its prefix: 6 of 7 — refused
tax id without separators: 7 of 7 — refused
amount written with a decimal separator: 7 of 7 — refused
due date in day-first format: 7 of 7 — refused
lowercase country: 7 of 7 — refused
a second real invoice: different debtor, number, amount bucket and due date: 3 of 7 — a different receivable