Sealing and verification
Operational0 active session(s)
Signing key
OperationalEd25519
Post-quantum co-signing
Availableunlocked per request with a key
Transparency log
Operational1094 leaf/leaves, disk-backed
Bitcoin anchoring
Operational222 of 224 root(s) in a block
Off-box backup
Operationallast succeeded 0.7h ago
Timestamping service
Availableunlocked per request with a key
Details
Issuermedseal-local
Uptime48d 9h 10m
Signing modestandard
Transfers on record1091
Log root5127459c5a0219298bf291d372a51652...
Root anchored on Bitcoinyes
Last anchor pass2026-10-20T08:47:43
Verifies without this serveryes
Seal/verify latencyp50 22 ms · p95 579 ms
Responses since boot2xx 36957 · 3xx 2 · 4xx 143
Per-IP limit120 req/min
Concurrent work12 requests
Cryptography
hash SHA-512signature Ed25519watermark DUAL, PEE, LSB, DEAES-256-GCM16x16 block tamper localization
Use it from your own system
Sealing, verification and the DICOM endpoints are open: no key, no account, CORS enabled. Two things need an access key, because both spend resources on someone else's behalf: post-quantum co-signing, and Bitcoin timestamping of your own files. Keys are issued by whoever runs this instance. Machine-readable status is at /api/v1/health.
# open, no key curl https://medseal-ai.duckdns.org/api/v1/health curl -F image=@scan.png -F patient_id=PT-1 https://medseal-ai.duckdns.org/api/v1/seal curl -F image=@received.png -F id=<seal-id> https://medseal-ai.duckdns.org/api/v1/verify # DICOM stays PACS-safe: provenance in private group 0009, pixels untouched curl -F image=@scan.dcm -F patient_id=PT-1 https://medseal-ai.duckdns.org/dicom/seal curl -F image=@received.dcm https://medseal-ai.duckdns.org/dicom/verify # needs an access key: post-quantum co-signing, and timestamping any file curl -H "X-MedSeal-Key: $KEY" -F image=@scan.png https://medseal-ai.duckdns.org/api/v1/seal curl -H "X-MedSeal-Key: $KEY" -F file=@report.pdf https://medseal-ai.duckdns.org/ots/stamp