Following up on this one, with inkan "verify" isn't just a slogan.
Every OTS-stamped event on inkan.cc comes with a download button for the raw .ots proof, together with a report that tells you exactly how to reproduce the hash the proof commits to:
leaf = SHA-256( id_bytes || sig_bytes )
It takes one line of shell to recompute it from the event's id and sig, then feed the .ots to any OpenTimestamps verifier, the CLI, the web one, whichever you like. Nothing from inkan is in the loop. It either resolves to a Bitcoin block header or it doesn't.
It's the same for key delegations: with the click of a button, the inkan client lets you download a standalone Python script that checks the on-chain declarations against an Ethereum RPC you choose. It recovers every ECDSA signature locally, checks the contract binding, flags nonce replays. You can read it top to bottom, no inkan server involved.
If I were fooling anyone, handing out the tools to catch me by building them right into the client would be a strange way to go about it.
The critics of inkan come in different flavors, like "haven't read it," "haven't tested it," and "haven't found a flaw in it." It's hard to be fooled by something you have the tools to verify, but it's easy to be fooled by people who are telling you not to look.
inkan
npub16x…56z6l
2026-10-12 06:08:39 UTC
in reply to nevent1q…2j69
Author Public Key
npub16xnpfx85k8wzdhctang6860g3u64lds5kac73ddjwlg0lxdg9g3su56z6lSeen on
wss://nostr.winePublished at
2026-10-12 06:08:39 UTCEvent JSON
{
"id": "68e2d1069997563744acbdfc83ae75b8ff5136b3699c90716fbafe5276b9236b",
"pubkey": "d1a61498f4b1dc26df0becd1a3e9e88f355fb614b771e8b5b277d0ff99a82a23",
"created_at": 1791785319,
"kind": 1,
"tags": [
[
"e",
"0000064b2f1bac5824277f82253d798733a7b31da9f6cf63eecfb9caceabb930",
"wss://theforest.nostr1.com/",
"root",
"dd664d5e4016433a8cd69f005ae1480804351789b59de5af06276de65633d319"
],
[
"e",
"f95ebb0864dc52d54f7a49f52442011daec078852e3c615b0e75593ada49d9a0",
"wss://relay.damus.io/",
"reply",
"d1a61498f4b1dc26df0becd1a3e9e88f355fb614b771e8b5b277d0ff99a82a23"
],
[
"p",
"dd664d5e4016433a8cd69f005ae1480804351789b59de5af06276de65633d319"
],
[
"p",
"036533caa872376946d4e4fdea4c1a0441eda38ca2d9d9417bb36006cbaabf58"
]
],
"content": "Following up on this one, with inkan \"verify\" isn't just a slogan.\n\nEvery OTS-stamped event on inkan.cc comes with a download button for the raw .ots proof, together with a report that tells you exactly how to reproduce the hash the proof commits to:\n\nleaf = SHA-256( id_bytes || sig_bytes )\n\nIt takes one line of shell to recompute it from the event's id and sig, then feed the .ots to any OpenTimestamps verifier, the CLI, the web one, whichever you like. Nothing from inkan is in the loop. It either resolves to a Bitcoin block header or it doesn't.\n\nIt's the same for key delegations: with the click of a button, the inkan client lets you download a standalone Python script that checks the on-chain declarations against an Ethereum RPC you choose. It recovers every ECDSA signature locally, checks the contract binding, flags nonce replays. You can read it top to bottom, no inkan server involved.\n\nIf I were fooling anyone, handing out the tools to catch me by building them right into the client would be a strange way to go about it.\n\nThe critics of inkan come in different flavors, like \"haven't read it,\" \"haven't tested it,\" and \"haven't found a flaw in it.\" It's hard to be fooled by something you have the tools to verify, but it's easy to be fooled by people who are telling you not to look.",
"sig": "bee536b4047132215cd0c12ef5cf68ecd4079abdb90d660309b47bf1a8434f0a788d38a0ed6dbe78c2743b05ae0e16b76509208e7d46cd744c0e918c28f1314e"
}