Steledger

List every record under one GitHub id — its identity record `ai:gh:<id>` and all its memories `ai:gh:<id>:mem:<hash>` — newest first, with each memory's content hash and metadata. This is how an agent starting a fresh session finds what it anchored before: `read_record` needs the full name, hash included, and this is where the hashes come from. Read-only, no sign-in needed to list any id; omit `github_id` to list your own when signed in. What comes back is the chain's view: confirmed records only (a write still in the mempool shows up after its block), expired ones included and flagged `expired` — their names can be taken by someone else, so do not treat them as yours. Only fingerprints and metadata live here; the content itself stays wherever you stored it. Results are cached for about a minute, so a record confirmed seconds ago may take that long to appear.

Check that the chain node behind this service is healthy and fully synced: its version, block height, header height, peer connections and sync state. It is an Emercoin node. Read-only, no sign-in required, no parameters. `synced` is not a comparison of the two heights — it is true once the node's verification progress passes 0.9999, so it can still be false while `blocks` and `headers` already match. Trust that field, not the arithmetic. While it is false, a `read_record` may reflect an older state of the chain; writes still work, they simply confirm later. Also the way to make sense of expiry: `expires_in` on a record is denominated in blocks, and this tool reports the current height, so the two together are the only authoritative answer to when something lapses. A term is bought in days and charged at a flat 175 blocks each; the chain has been producing about 171 a day lately (8.4 min/block over the 103 days to 2026-09-22), so a term is close to its nominal length right now — but that rate drifts, which is why you should read the blocks rather than convert to days.

Read one on-chain record by its full name — an agent's identity (`ai:gh:<github_id>`) or a memory (`ai:gh:<github_id>:mem:<hash>`) written by `register_identity` / `store_memory`. Records live in Emercoin's Name-Value Storage, so anyone can verify one in a public block explorer as well as here. Returns the confirmed on-chain record, or a `pending` one still in the mempool — the `status` field ('confirmed' | 'pending') distinguishes them. A name is only held for a limited term, so check `expired` (and `expires_in`, in blocks) before trusting a record: a lapsed name still reads back as 'confirmed' but can be re-registered by anyone. Read-only, no sign-in required; use `whoami` to find your own github_id. A name that has never been written is an error, not an empty record — handle the failure, do not test the fields for null. `name` is the full NVS name and is capped at 512 bytes by the chain.

Create or rotate your on-chain identity record `ai:gh:<github_id>`, binding an Emercoin address to your GitHub identity. Requires a signed-in session (OAuth) and counts against the FREE-tier write limits (see `whoami`). Run `whoami` first to confirm you are signed in; anchor memories under this identity afterwards with `store_memory`. Writes one NVS transaction paid by the gateway (you need no EMC); the record reads back as `pending` at once and `confirmed` after the next block (about 8 minutes on average lately). Idempotent — calling again rebinds the address, and `metadata` is replaced rather than merged. Limits worth knowing before you call: `metadata` is stored verbatim in the record value alongside your github id, login and address, and the whole value must stay under 20 KiB — the chain rejects more. Every 128 bytes of name plus value adds about 0.0001 EMC to the fee the gateway pays for you. The value is written to a public chain exactly as given and cannot be deleted, so put nothing private in it. `address` is not parsed or checked here — any string is accepted, because control is proven later by signing a challenge at login, so a typo surfaces then rather than now. Returns the record name and the transaction id.

Tell the people running this service that something went wrong or is unclear — an error you cannot explain, a result that looks wrong, documentation that misled you, a tool you needed and did not find. Open to everyone; no sign-in. Up to 1000 characters, a few messages per day. A person reads them over the following days; there is no automatic reply, so do not wait for one. If you are signed in, your GitHub id is kept with the message; nothing else about you is. Every refusal from this service points here.

Anchor a fingerprint of a memory or artifact on-chain as the NVS record `ai:gh:<github_id>:mem:<content_hash>`. Only the hash and your metadata are stored — never the content, which you keep wherever you like (a file, a database, IPFS). What you get is a tamper-evident, timestamped proof that content with this hash existed, which anyone can verify later; `list_records` finds your earlier ones again. Requires a signed-in session (OAuth) and counts against the FREE-tier write limits (see `whoami`). Writes one NVS transaction paid by the gateway; reads back `pending` at once, `confirmed` after the next block (about 8 minutes on average lately). Not idempotent — each distinct hash is a new record. Register your identity first — nothing enforces it, the write succeeds either way, but a memory under an unregistered id anchors to nobody and proves correspondingly little. Writing a hash you already anchored renews that record: its term is extended (terms add up), and its metadata is replaced by what you pass now — so pass the old metadata again if you want to keep it. That is the only renewal there is; a record left alone lapses after its term (see `expires_in`). Limits worth knowing before you call: `content_hash` becomes part of the record *name*, `ai:gh:<github_id>:mem:<hash>`, so it must look like a digest: 32–128 characters of letters, digits, '_' or '-' (hex of any common algorithm, or an IPFS CID); anything else is refused with `invalid_hash` before any quota is spent. Beyond that shape it is never verified: nothing checks that it is the hash of anything, so a wrong digest anchors happily and proves nothing. `metadata` goes verbatim into the record value, which must stay under 20 KiB, is public and permanent. Returns the record name and the transaction id.

Anchor many fingerprints in ONE on-chain transaction — the way to record a session's worth of artifacts without spending a write per minute on each. Each item becomes `ai:gh:<github_id>:mem:<content_hash>`, exactly as with `store_memory`: only hashes and metadata, never content. All or nothing: if any item is refused (a malformed hash, say), nothing is written. Requires a signed-in session. A batch of N counts as N writes against the FREE-tier limits (10 per minute, 100 per 24 hours), so at most 10 items fit in one call on a fresh minute; the result says how many writes are left. One transaction id comes back for the whole batch; each name reads back `pending` at once and `confirmed` after the next block.

Hand your records over from the gateway's wallet to an address you choose, in one transaction. IRREVERSIBLE: once the block confirms, the gateway can no longer change, renew or return them — nor can anyone else but the holder of `to_address`. Values are carried over unchanged, and each record gets about a century added to its term, since the gateway will not be able to renew it. Why you might: with an address whose key you hold, the records are really yours — you can prove control by signing, and payments sent to your identity name reach you rather than the gateway. Changing a record afterwards needs your own Emercoin node and its fees. With an address no one holds a key to, the records are sealed: provably unchangeable by anyone until the term ends. If you only want proof that something existed at a given time, do not transfer — a record held by the gateway is already dated. Only records under your own identity (`ai:gh:<github_id>` and its `:mem:` records) can be moved, and only once they are confirmed. Requires a signed-in session; each record counts as one write against the FREE-tier limits. After a transfer, register_identity and re-storing a moved hash fail with `not_held`; new memories are held by the gateway again. Changing a record costs a network fee in EMC. If you hold the key and have no EMC, set `fee_grant`: the gateway then also sends 0.01 EMC (about fifty value updates) to `to_address` in a separate transaction — once per GitHub account, within a daily budget. If it is not available the call is refused before anything moves (`fee_grant_used`, `fee_grant_unavailable`), so you can decide to transfer without it. Do not ask for it with an address no one holds a key to: nobody could spend it. Returns the transaction id, the names moved, the fee funds if sent, and a plain statement of what changes.

Report the current session's identity. Read-only, no sign-in required: an anonymous session gets `{authenticated: false}` with a hint (not an error), a signed-in one gets `{authenticated: true}` plus the GitHub-rooted id, login and tariff. Call it to confirm who you are before `register_identity` / `store_memory`; an anonymous caller must sign in (GitHub OAuth) first. `github_id` is the one field you usually need: every record name is built from it — `ai:gh:<github_id>` and `ai:gh:<github_id>:mem:<hash>` — so this is how you learn which names are yours to write and to read back. `tariff` is `free` for every account today; it governs the write limits, currently 10 writes per minute and 100 per trailing 24 hours per account, and writing needs a GitHub account at least 30 days old. `quota` says how many writes are left right now (and, for a young account, the date writes open); every write returns the same figures, so plan batches with them. Note what this tool does not do: it reports the session only, reading the token your client already holds without calling GitHub, and it proves nothing about control of an Emercoin address — that is what signing a challenge at login is for.