Blockchain Verification

Verifying a Record

Authenticated users can verify any blockchain-anchored record from within the platform, and counterparties can verify the same records on the public verification page without logging in. Verification confirms that the document has not been altered since it was anchored: the platform recomputes the SHA-256 hash of the current document and compares it to the hash recorded on the blockchain. A match means the document is unaltered; a mismatch means it has been modified since anchoring.

What you'll learn

How to verify an anchored record from within a case
What you need to perform verification (in-app vs. public verification)
What a successful vs. failed verification means
How to look up a record by transaction hash or entity ID
How the retry and pending-transaction system works

Authentication requirement

Vilulia offers two verification paths. Counterparties who receive an anchored record can verify it on the public page at /verify without an account or login, by transaction hash, settlement ID, award ID, or by submitting a hash for comparison. The in-app verification API is separate: it requires authentication, access to the case or entity, and the blockchain_verification feature on your plan.

Verifying from a case record

For arbitration awards, blockchain verification status is shown inline in the Awards tab of the case. Once an award is issued and anchored, the panel displays the transaction hash (tx_hash), block number, confirmed date and time, network name, and a link to view the transaction on PolygonScan. If an award has not yet been anchored, a Verify on Blockchain button is shown that initiates anchoring. There is no separate Verification tab in the case record.

Verification is supported for settlements, awards, documents (final/executed only), and training certificates. Evidence uploads, drafts, and working documents are not recorded on chain.

Training certificate QR codes

PDF training certificates include a QR code that encodes a verification URL in the form https://vilulia.com/verify/{verification_code}. Scanning the QR code opens a public verification lookup for that certificate, returning the holder name, course title, and issue date. No login is required.

Verification by transaction hash or entity ID

Any anchored record can be verified by transaction hash (GET /api/v1/blockchain/tx/{tx_hash}) or by entity type and ID (for example, GET /api/v1/blockchain/settlement/{id}, GET /api/v1/blockchain/award/{id}, GET /api/v1/blockchain/document/{id}, or GET /api/v1/blockchain/certificate/{id}). The public verification page covers a subset of these without login: GET /verify/tx/{tx_hash}, GET /verify/settlement/{id}, and GET /verify/award/{id}. Admins can also browse the Blockchain Verification History page in the admin dashboard, which lists all anchored records in a filterable, paginated table and supports CSV export.

Pending transactions

When a transaction is submitted to the Polygon network but confirmation times out, the system saves it as pending and a background task continues to monitor it. Anchoring status can be polled via GET /api/v1/blockchain/anchor-status/{log_id} or by entity using GET /api/v1/blockchain/anchor-status/by-entity/{type}/{id}. Status values are: pending, processing, submitted, confirmed, and failed.

Retry logic

The anchoring system retries transient failures (network errors, timeouts, rate limits, 5xx responses) automatically using exponential backoff with full jitter, up to three attempts by default. Permanent failures — insufficient funds, invalid signature, execution reverted — are not retried. If all retries are exhausted, the record is marked failed and can be re-submitted manually.

Verification results

A verified result means the SHA-256 hash of the current document matches the hash recorded on the Polygon blockchain at the time of anchoring — confirming the document has not been modified. A failed verification means the hashes do not match, indicating that the document content differs from what was anchored. A failed verification should be investigated immediately.

If the blockchain service is unavailable at verification time, the platform falls back to comparing the expected hash against the locally stored hash in the database and notes this in the response.

Can't find what you're looking for? Contact Support