Four dated readings about one MiCA-authorised issuer, produced independently and laid beside each other by whoever is asking. Was the entity present in the register extract you captured, on the date you captured it? Does its published reserve disclosure hold up against the terms you are holding it to? And do two separate recomputes of the stablecoin side agree with each other? Each stage emits its own hash-anchored artifact. Nothing here certifies anything.
register_snapshot_digest. The reading is a dated fact about that snapshot. It is never an authorisation or current-status determination.check_mica_register_presence{
"jsonrpc": "2.0",
"method": "tools/call",
"params": {
"name": "check_mica_register_presence",
"arguments": {
"register_type": "white_paper",
"entity_identifier": "984500XXXXXXXXXXXX02",
"register_extract": "lei,issuer_name,crypto_asset_name,notification_date,home_member_state\n984500XXXXXXXXXXXX01,Example Issuer SA,EXAMPLE-EURO-TOKEN,2026-01-15,FR\n984500XXXXXXXXXXXX02,Second Issuer NV,SECOND-TOKEN,2026-02-03,NL\n",
"retrieval_date": "2026-08-11",
"match_column": "lei"
}
},
"id": 1
}
check_mica_reserve_disclosure{
"jsonrpc": "2.0",
"method": "tools/call",
"params": {
"name": "check_mica_reserve_disclosure",
"arguments": {
"issuer_id": "ISSUER-DEMO-01",
"token_type": "EMT",
"as_of": "2026-06-30",
"tokens_in_circulation": "500000000",
"reserve_components": [
{"asset_class": "bank_deposit", "amount": "205000000", "custodian_type": "credit_institution", "segregated": true}
],
"declared_rules": {"eligible_asset_classes": ["bank_deposit"], "cadence_days": 31}
}
},
"id": 2
}
precheck_reserve_attestation{
"jsonrpc": "2.0",
"method": "tools/call",
"params": {
"name": "precheck_reserve_attestation",
"arguments": {
"issuer_name": "SYNTHETIC-ISSUER",
"outstanding_tokens": 500000000,
"total_reserves_usd": 512500000
}
},
"id": 3
}
check_genius_reserve_disclosure_conformance{
"jsonrpc": "2.0",
"method": "tools/call",
"params": {
"name": "check_genius_reserve_disclosure_conformance",
"arguments": {
"report_period": "2026-07",
"period_end_date": "2026-07-31",
"outstanding_tokens_reported": 500000000,
"token_price": 1,
"total_reserves_usd": 512500000,
"attestation_present": true,
"attestation_date": "2026-08-14"
}
},
"id": 4
}
If Stage 1 finds no match while Stages 2 to 4 read cleanly, the likeliest explanations are mundane: the wrong register was pasted, the extract was a filtered page, or the identifier is spelled differently in the register than in the disclosure. None of those is evidence about the issuer, and this chain deliberately says nothing about which explanation applies.
If Stages 3 and 4 disagree with each other over the same declared figures, that disagreement is worth reading, because both are recomputes of the same subject from the same reader-declared numbers by different routes. What it is not is a finding: the reader's own inputs, and the rules the reader declared, are equally capable of producing it.
Copy this paragraph into Claude, OpenClaw, or any MCP-aware agent to run this whole workflow on the server and check one field that answers a real question.
Question: Before onboarding this issuer, does its identifier actually appear on the register extract we pulled?
Run the AINumbers MCP tool `run_chain` with {"chain":"mica-register-crosscheck"} and read `art-602-mica-register-presence-check.match_found`.
Re-run with `inputs` for `art-602-mica-register-presence-check`, reusing the values that result echoed, with `entity_identifier` set to "984500YYYYYYYYYYYY99". Compare the same field.
Verify: call `verify_execution_hash` (https://mcp.ainumbers.co/mcp) with `claimed_hash` set to `composite_execution_hash` and the full `composite_artifact`.
Ledger, for a human re-check: https://ledger.ainumbers.co/
PII rule: send synthetic or anonymised inputs only. The MCP server runs these kernels and logs no payloads.
Chain page: https://ainumbers.co/chaingraph/chains/mica-register-crosscheck.html