vortx-ai/emem/emem-transparency-log

emem-transparency-log

Network use. The commands in this skill send JSON to https://emem.dev and receive JSON from it. Where a step says so, they also receive an image or a raster file. https://emem.dev is the service that the MCP server of the plugin connects to. The commands do not execute what they download. The files under scripts/ read local files and make no network calls.

A receipt proves that the responder signed some fact cids. It does not prove that the responder showed every reader the same history. The transparency log does that. Each attestation and each memory write is a leaf in one RFC 6962 Merkle tree. The responder signs the head of that tree. Pin a head today. Tomorrow you can prove that the log only grew.

Which call to use

All calls are reads. They need no key.

The inclusion call also accepts entry_hash=<base32> or fact_cid=<cid> in place of leaf_index. Add tree_size=<n> to prove against an earlier head.

The tree hashes with BLAKE3. A leaf is blake3(0x00 || entry_hash). A node is blake3(0x01 || left || right). A lone node moves up one level. The tree does not duplicate it.

The MCP tools in the table are not in the short tool list of the MCP server. The server runs them by name through tools/call. If your host calls only listed tools, or has no MCP, use the GET routes.

Step 1: pin a head and prove one leaf

scripts/verify_log.py ships with this skill. Claude Code sets ${CLAUDE_SKILL_DIR}. The script makes no network calls. Its only import outside the standard library is scripts/emem_crypto.py, which also ships with this skill. That module is a plain-Python BLAKE3 and Ed25519 verifier.

Check the module against the official test vectors first:

python3 "${CLAUDE_SKILL_DIR}/scripts/verify_log.py" --self-test

The last line is SELF-TEST PASS.

Get the current head and an inclusion proof for one leaf. Send a GET to https://emem.dev/v1/log/sth and save the answer as old_sth.json. Send a GET to https://emem.dev/v1/log/inclusion?leaf_index=12345 and save the answer as inc.json.

With MCP, call emem_log_sth with {}. Then call emem_log_inclusion with {"leaf_index": 12345}. Save each result as a JSON file.

Check both files:

python3 "${CLAUDE_SKILL_DIR}/scripts/verify_log.py" sth old_sth.json
python3 "${CLAUDE_SKILL_DIR}/scripts/verify_log.py" inclusion inc.json

The inclusion check also verifies the head that the response carries, so it prints an sth line first. On 7 November 2026 at 02:33 UTC these commands printed:

sth          VALID    tree_size=3245770 signed_at=2026-11-07T02:33:13Z signer=777er3yihgifqmv5hmc2wwmyszgddzderzhsx6rex4yoakwomvka
sth          VALID    tree_size=3245770 signed_at=2026-11-07T02:33:13Z signer=777er3yihgifqmv5hmc2wwmyszgddzderzhsx6rex4yoakwomvka
inclusion    VALID    leaf_index=12345 path=22 hashes

Step 2: prove that the log only grew

Later, get a new head and read both tree sizes. Send a GET to https://emem.dev/v1/log/sth again and save the answer as new_sth.json. Then:

jq .sth.tree_size old_sth.json new_sth.json

Ask for the consistency proof from the old size to the new size. Put your two sizes in the query. Send a GET to https://emem.dev/v1/log/consistency?first=3245770&second=3245806 and save the answer as cons.json. Then check it:

python3 "${CLAUDE_SKILL_DIR}/scripts/verify_log.py" consistency old_sth.json new_sth.json cons.json

With MCP, call emem_log_consistency with {"first": 3245770, "second": 3245806}.

On 7 November 2026 at 02:33 UTC the check printed:

sth          VALID    tree_size=3245770 signed_at=2026-11-07T02:33:13Z signer=777er3yihgifqmv5hmc2wwmyszgddzderzhsx6rex4yoakwomvka
sth          VALID    tree_size=3245806 signed_at=2026-11-07T02:33:28Z signer=777er3yihgifqmv5hmc2wwmyszgddzderzhsx6rex4yoakwomvka
consistency  VALID    3245770 -> 3245806, 14 hashes

Always send second. Without it, the server uses the current size. The log grows every few seconds, so that size can differ from the head you saved. The script refuses sizes that do not match the two heads.

If the two heads have the same tree_size, there is nothing to prove yet. Get the new head again a little later.

Exit codes and a tamper check

To see a failure, change one value in a copy and check the copy:

jq '.leaf_index=12346' inc.json > bad_inc.json
python3 "${CLAUDE_SKILL_DIR}/scripts/verify_log.py" inclusion bad_inc.json

On 7 November 2026 this printed inclusion INVALID leaf_index=12346 after a valid sth line, and exited with 1. A changed tree_size in a head also gave INVALID.

Step 3: prove that a memory note is in the log

A memory write is also a log entry. The JSON view of a note gives the inclusion path in its log field. Send a GET to https://emem.dev/memories/by_attester/k572x7go/readme/tree-20261106.md with the header accept: application/json. Read file_cid and log in the answer.

On 7 November 2026 log.inclusion was /v1/log/inclusion?entry_hash=vxtja5r45kg6uiu6kjmstondfq6fxhvnwyojsqaogehtavzqwqwq. A note with "log": null has no log entry to prove.

You can also send the BLAKE3 of the note content as entry_hash. The value must be base32 without padding, in lower case. A hex value gets 400 invalid_argument. Convert authorship.body_hash_hex like this:

python3 -c "import base64,sys; print(base64.b32encode(bytes.fromhex(sys.argv[1])).decode().rstrip('=').lower())" \
  2d04e9a347fc7cf59ef91e99a13274a95296f0d84aac32e641db7a887fdf511b

Then get and check the proof. Send a GET to https://emem.dev/v1/log/inclusion?entry_hash=fucoti2h7r6plhxzd2m2cmtuvfjjn4gyjkwdfzsb3n5iq767kenq and save the answer as note_inc.json. Then:

jq -c '{matched, memory_note_file_cid, leaf_index}' note_inc.json
python3 "${CLAUDE_SKILL_DIR}/scripts/verify_log.py" inclusion note_inc.json

On 7 November 2026 the response had matched: "memory_note_content", memory_note_file_cid: "fucoti2h7r6plhxzd2m2cmtuve" and leaf_index: 3235700. The path of 19 hashes verified.

The proof covers the log entry. It does not cover the content itself. To close the loop, get that entry from /v1/log/entries and decode its CBOR. Its content_blake3 must equal the hash that you sent. The verify field of the response says the same.

To prove the entry that carried a fact, send fact_cid=<cid>. On 7 November 2026, fact_cid=nflpddk7zsncywguwjzk5koksseqfyx4jnngkuryrnd4aykqlpfq matched at leaf_index 2457934 and its path verified.

Step 4: read the witnesses

curl -sf 'https://emem.dev/v1/log/witnesses?limit=5'

Read independent_operator_count, independent_operator_domains, head_is_witnessed_by_independent_operator, freshest_independent_operator_entries_behind and witness_keys_by_tier in the answer.

With MCP, call emem_log_witnesses with {"limit": 5}.

A witness attests only the prefix that it signed. The response gives three levels of independence:

On 7 November 2026 at 02:33 UTC the log had 112 independent witness keys. Only one independent operator domain had fresh evidence: eudr.dev. Its freshest co-signature was 58 entries behind the head, so head_is_witnessed_by_independent_operator was false. The value of head_is_witnessed was also false.

To check a co-signature, verify it offline. Then run a consistency proof from its tree_size to the head that you hold. Add at_or_after=<the tree_size you pinned> to the witnesses call. The nearest_witnessed field then gives the nearest co-signed head at or after your size, with that consistency proof.

What this does not prove

• That a fact is true. It proves that the history was not rewritten.
• That the merkle_proof in a receipt is this tree. That proof binds a

fact into its signing batch. To check it, use `emem-verify-receipt`.

• A split view that nobody compares. Pin heads, share them with other

agents, and check consistency between the heads that each of you saw.