M 5.2 · MID-INDIAN RIDGE

Each observatory’s own values and event id. The distance and the seconds are from the timestamp’s own epicentre and origin time.

The digest covers the timestamp’s values; the seal is SourceLess’s signature over the digest.

Digest

27d22642…6268974dcopy

Seal scheme

aegis-gemini

Signer

zk13str_b4c421607b749197aff78f3edb58ce087a7a16b6_16a1

Signature

00e40deed3cb907b310b84f6b40241c1056559f0c8e4d011d41902d7d2157a7978dd028a0596fb2ad7558ac05d2076f6f73f99cae8932782665eebda12d70303

Post-quantum signature

48289904…12181f28copy

The whole signature, 3,309 bytes

48289904cfc95467d3a38987135781120515001c9f7f962188ebf46e5aba7cbd209f32f01969a23dfe4d48c4da42ad789f64fc46e433580e9bb8c86056b6494e284d25573a6216706db34eb1ed841103ef4429fe2c9b11d6bf33ce1b515da22082715892ac32af54aad950dbf83cff6dfc04ce1e4b360e1f361ed44f66e74d6cad70731143a299d80c09ce1b0182759d115badf7bd061db7416344eddfa4b21a2e5734903df640a53ecb6c74371474d164d19cfc5f1d9b84c7fe0a5f8eeb74e9a3bd91d9556d30944cea9a31f794546f5ab7fc3464c452fa102150609b8a298f387362b2ea684fd7e0eda891489109b67316325326552c4df011433cf6f3332181326ca7d7f2b60f0221fcb1bc52d34eea347d0c312804ff1eccb6fe44adefae578b07f385041d530bb7395c2d810a5112f6f58f8f47d9c0cdec82c0935900aa5ded2f9c33b507fd7493d58b62153cad2b23d94a337e094ddeb404da6094a5467b9ca3c4d03dfd4f9969bb2765db70bd2c314b6a4031ba731f7989ef250aff34225ef62e57f4b01979412c40a27fd46cf1ef7086b419b20c0a62cad9632b62541b86d47fca2626c48c1d0208ca5d0ca6a7dca232a250dcf66d5ddd783993d2339b6616b1139d0be230660cd65f3cf401d5b7b7ee56eaf0787f67ffe6fc38d1daf2db7622a076cb1025c78fd90d4351c1774bffd898636caa5401b02b7f4916690b8fd91586258712de390b98e6f42a8c95399516dafbe7d2e90c26632eff7437edb7fadb1c79ce873dc0a18b3c0880a7df55f22591ade7c0ca3f9a9ce8b1fd1fdfd3bc7ead792feb59467ec1eafebb5e52423609540e4e6a460d90e290c7877d74223b1790cc18eef285a745c5a2435a3dafae33a05eef003fe8d07c135bbdde83b7ce5090572f728736437ea903ce5a5e1c9122cc50d773b05e198aa5f0a24baf3938b7162a47569f31c22b736bf82399b10ff64459ebcc05481d2518af18da3e71cf7ebf10d653d905b88bddfdb2d28e1379b1c486d40ddf616ba031002ebc81a44661cddd99e4a6705ccd89babca3f1c2745038cb4c3eb3afb4ca6695d77b43d72e43ca105f57563f0796620161de9fb245f50941bf283a8ef701ca53d94194b63f3e07eefb05806de7dbe5e934741236b17d174ebec582faa50e59dd245d7f48496ab0ae3e6864a794b9a984ae23cafd78c081e74f984fdc7e26bcbcec716bb0b1837889f035bdfc8a9bdf9019f0f37613cd4a3f072e3cbdc6ed69d2ab0af3f4368ba4be34071e3f80935c3e9d89ac3d551be64021cc7097a5a7cbb0d54d5e919df3571cce32d3a7d04c66ee79bc152e1e0499c406d94440d12fcad3b0ac37c402d8337d3781c8207dddd434dfaeb49012450948455e7147bd7ad6ff768f247549b227bc63fbb2b29b1e3d3c396c511e70cfa7909234958e2d4bcdd50e63eec693c0c406373283977d7dcdaaa83576bd780f2d362cb36c526baf08ad3a943e536e27b382a3300aedb1e2ff5843e16977644be775e7afbfb670e3fdae2483a49ff1461358d7bfbe0a1422d5b4560b41ad2a6a7936c2f6a47619e1183038de545789df9be175c100e3f210bf24e88184dd3b3f990cd35354bd93ef5eb66644251000f1a7c240819382a3365a92adfd62af898cb12021b8472f5a32fb9366669bd778b496a0d4759c3e4e7578f175ef1aa289df7e5bf05d83b95eb4db87b7b1006d23a22f9503542b72cbc06a04239221cdea30eff2d6e91d8f7ecccdfce2afcde33cba84a35c0e4a2d4a22c2f35050c4c268143df261790590f5b9c123a6642d91012262a473532885fafb1882933aca6d0f1eaf88f34aca9e7b6449019c7c83f137a8d0a9437748be4fc1b6fa4d19687807055a322c89bdbb8a847ea091256bc6a1fd6a143316f91e456df1279f38fcfdb4a6b4584e27afb4b08eec74e8912401414b3ea69074e3fb697e3dd88d3b6a6fafc70dcc02cfd230ced514b4e55fd85b60378dd93cab10251d7c777b98cace07201e088b41c08654e15fc9288d4fe0bb060aa1967b58e71e9d396d93021b1c99311b42677280475c1b6f338e92acd79564e628886d6a28ccd19d1eab813ba373dee109762eaf99167041427f8c06fca107d7394403dfcf5489399caa9d2133ee1d02b71e7f4fdb0b89b165a7cbbce277f7665453c7876c5f65e2302ea97d00ea1d4f0290a87f04f7faaa7974030e0e72d07d1f04e9819825314d30f2462a7652438b1c684019c0f1189c13ea0510666bbe2610e99bcb3f8204c0c70d6d0a921becb6b719576563686c1c5b7d8d6eb91f24d1c0c907bfccd2ea301fbefea237840fd14f3d800300d3fcd4e78d548a7c46cea049546bc2ee65039a749eb4b67e5291f0db136786dfb3e6a89a8c22f1c820e937c12e5d0bd63fc7b626127fd65af868e3bdb27ccf11a4933739ac556125d791bbbb20a76dd25b42f5eb5028236519649353704336b2da929ad6929337a62555f1d7a75b6d78f8ed15b50655e7a64d983518ba08af3d33e158cb779f4381ddda475fbd2fa94282c8256f673f407368c7f6d593bb1a005b046670cb6b2e206f90399bc715a5f77fe95a3df7c698da4f28080c2386e149aa1cbbdc1b3311023b9548f082b325077eb10f381d93de0b96acf859057bb7c60539aabe27bba1a3d4e3f54bcdb04f04451b654be8aa1ad7468e3c5da95c8454fad95e81f2bc2cd94e35321475a19c0fe3c0f2d721b89697051f528c999ccfac295e8d1bd18a1cebaa6dab24ebbebb0defa4d6381d83ea5fbf936583f611b29423a46fa1dab9064ab45d61998571a6e083d2f8724dcef956f3baf506dcf0669b227fec1bfc1450aa65a51a9cde301091182b69d60957a64506bbdf5c99f120e1d2399317053aa6e67a70f0d8b6cec585a43017172c3fe893acab8b8758591ffbfa9d1b1e3b76d750bdba18840457e52f7e3e2e1e9dbbc41b24f892274b5f022501fe4250a13de1b4bd1cc6e416a0ec3351024c50e1aaecd6f11d8cf02bea4a1bcf5a93e05b8e4e4b58b7e3500cc6a3e7a986699cb2972c4cc952a1601d6e9b15f481c8928145a304884171ad07b5494cbb3f862e5c0d4055d6736bb82f2bef37f09bca544752cf6672bfb79795031a27910f2424a960f4d5ea09267f738e1d20565c0e3bd376831203b2b003fc9ecb38a8039479f81d290379026d0f03d80e1d07a1efb33ae16fc63ffa214fc045aef3b8a0302b152337552fdc8a1f6f9b3931ae22389a0610ad7fa23a38de7f2448410ff9dceac3b20aa677ebfc68916e856922376464fc65e9f9e40ebf212cb61263d7dcc381b5c1a1f1ce8f97bc6555bcb50039c09dcf25ffcea1c99fddef346f8bd51667218331da22731b2b550300a6a8b569124ebf2014e4ec8eb7ee0396366be587da06250df93e0da782e4aced5be345549d0312949b079ac8225a43611b576701cf094cb7d76798c556772e6ea0abd4c2a88222c8d70a362b9f10b1b220f1973b8f72417d3c31ff79471b0eaeff7496b2ff79dfcdbbf74712b4934122686112fa9b2dfade3663a76bbaa4559cacc4667e3df98fc3d03a31d3715eaaa6cbc536ef05ea03bf0c3972e0eb98a84574f1ef9f5d523bef5d132f6c082b65cc957f7c6148d128640d61d7427c9ccde32fda17a55a168ecce165f4b628421ccf9710afdb1227950b56a9a957cdd49e22d3bdf881ae70cafdafecc8330dedc9dbc0213702e49fb5efa6abfef73b241e3f35852217e8e7559c399928a57687772dbd04d0808b1bc5e8dd7b5563d396ebd1849eb73850032f9f2315ac63ed3d1249a325552d51b3d6fceb0eebed6c639019b60e9b8d8a25f41637b1ca4cfaf6eb79df69c7b6523b9bbb43d43a096042574551aeec4659f1098570c9d007dddd9567f4551fb83e40fbdf45bc0d1ab577a915c5848d05a95b9699b4ce46aea006b3a9b3300c47169d5fc72d5544a0802b9732f02676b9206dcb13b393732c657d92df4cd53c3598412f04f6eeb5e671953c145d8c1e61658a65c33589427fbe4f568c9348cf07316011a85d4d0ecaf737516c7d4dfc13178db49e36ef99c31cfc3394cd798ad6993e8df28bc113566a068267fe1b7437a160d7208999f05ff6cf82a5313ed08b3ce7e9e3d873d127068ab6fc474395eac3814914aa2e9ece67fc97065feb3bb21684e430998dc3e031765c89b23bc4221adc745c29523df0eb878956bf91fb960d6f60a70c7ae229320ff75104fe198aaa88387e06f62998c3036e50a46a1b2b76669a5d0b8b1bdd046a5cb168bf6c13db7e7d63a3ca12d7dde64ac68fec665d2738329de1ed0f89ace9e8540cf7c307fcd3d56ffe9229d7d6249c35627c9dc773f3f40d57cc1f8d000a8f8986da69ed03395298891aa341a9833b86ab92a44bf8e3f67269e0fc5f6a19afff563965b104a3da4b32c48b2effa4812f12e8bfca399efd619c79d3a4cd6176a635eebdd6bd1287be39c4471b0be6fa7717597dcaf89f074a0ca13d55cc082858e841fd4964db006b43cc6474cf199a05e935c210bf317a0b591965c42d466a65e57fbeb3fb413ecea943d549487b27c2b09f0b4a65c24054b307435f769cc5ccfabac7df092764a6ade0fe0b3148aaacc02e7f8c9ca1d6fc445e6672898db6c5e9000000000000000000000000000000080b12181f28

Binding

Both layers are signed by the printer that sealed this timestamp, together with its digest.

Countersign

CountersignedNot sealed

Window

USGS day feed, published by 2026-11-03 18:33:08.000 UTC, 218 earthquakes, this one not among them

Window source

https://earthquake.usgs.gov/earthquakes/feed/v1.0/summary/all_day.geojson

Window digest

955c1cdb…f9948566copy

Countersigned by

zk13str_b4c421607b749197aff78f3edb58ce087a7a16b6_16a1 · the printer

Checked here

the signature, the digest it is over and the window digest all verify on this server. The window itself was not re-fetched here.

What it proves

this countersigned timestamp did not exist before 2026-11-03 17:37:00.350 UTC, when the eighth-newest earthquake in the window happened, once a re-fetch of the window confirms it. Both routes rest the bound on the eight newest earthquakes, never on one, so it is looser by design than the newest; a re-fetch from the permanent catalogue, after the feed has moved on, confirms the eighth-newest it matches, less five seconds. The window’s publication is shown above as “published” and is not a proven bound. A lower bound only.

Sealed evidence

Not sealed: GodCypher parties not configured

What this page checks, it checks on this server. The full check is node scripts/jord.mjs verify on your own machine, with --refetch to re-fetch the window.

The upper bound is not GodCypher’s: it is the Roughtime signed time above, the national laboratories’ judgement of the printer’s clock, and the chain anchor once one is submitted. How a GodCypher timestamp works.

Pending Not anchored yet. Anchoring timestamps on the chain is not live; when it is, this line names the transaction and the block that carry this timestamp’s digest. Until then the chain holds none of it, and the page says so rather than pointing at a block that does not hold it.

1. Read the timestamp as data. /api/timestamps/27d226424311ac684d8aec848331b358c5ad9af29dc14626a55093806268974d is this page as JSON: every value the digest covers, as it was digested, and the GodCypher layers beside it.
2. Recompute the digest, check the seal and re-fetch the countersign window on your own machine: save that JSON as timestamp.json and run the SourceLess code over it:

   node scripts/jord.mjs verify timestamp.json --refetch

   Each layer is reported on its own. A window the verifier could not reach is reported as not confirmed, never as a pass.
3. Check each observatory at its source. The addresses in the evidence table are printed as text for you to open yourself; this page links to no other site. An observatory may revise its values later, by a little.
4. Once it is anchored, open its transaction and check that it carries the digest shown on every timestamp.