Steledger

com.steledgerPublished by steledger.comOfficial publisherv0.3.0Updated Oct 24, 2026

Durable identity and memory for AI agents, anchored on the Emercoin blockchain.

VerifiedStreamable HTTPWeb executableKnowledge & MemorySecurity & Monitoring

Overview

AI-generated overview

Steledger lets an AI assistant anchor a GitHub-rooted identity and memory fingerprints on the Emercoin blockchain, then read and list them back.

What you can do
Check the health and sync state of the Emercoin node behind the service, and confirm the current session's identity and tariff with whoami or sign in via GitHub device flow or a token. Create or rotate an on-chain identity record binding an Emercoin address to a GitHub id. Anchor a memory or artifact fingerprint, singly or as an atomic batch in one transaction, storing only the hash and metadata. Read one record by its full name, or list every identity and memory record under a GitHub id, newest first. Transfer records from the gateway wallet to an address you choose, and send feedback to the operators.
When to use it
Useful when an agent needs a durable, tamper-evident, publicly verifiable identity or a timestamped proof of artifacts that survives across sessions, rather than storing content itself. Suited to agents that want to re-find what they anchored in earlier sessions by GitHub id.
Requirements
Runs as a remote endpoint or as a local process (container image over stdio, or the Python server with its requirements). The GATEWAY_URL environment variable sets the gateway base URL. Write tools need a signed-in session: a bearer Authorization header carrying a session JWT obtained from the service's login, or a pre-issued token. Read tools and feedback need no sign-in.
Before you install
Write tools require a session JWT in the Authorization header, so treat it as a secret. register_identity and store_memory count against FREE-tier write limits. transfer_records is irreversible: once confirmed, the gateway can no longer change, renew or return the records, and only the holder of the target address controls them. Only hashes and metadata are anchored, never content, but record names and metadata become public on-chain.

Installation

In SourceWeft

  1. Open Steledger in the dashboard and add it to a workspace.
  2. Enable the server for the chats that should use its tools.

Web executable via Streamable HTTP. Remote servers run from the web runtime once configured in a workspace.

Use with an agent

Paste this prompt into Claude Code, Codex, Cursor or another agent — or into SourceWeft chat. The agent reads this server's install guide, shows you its publisher, endpoint and sign-in, and adds it to your client once you agree. Keys never go into a command.

Read https://sourceweft.com/mcp/com.steledger%2Fgateway/install.md and connect the MCP server it describes to my client. Before changing any config, show me its publisher, endpoint and sign-in method and wait for my OK. Never put an API key in a command or in a file I would commit; ask me where it should come from.

Read the install guide the agent follows

Other MCP clients

Add this to your client's mcpServers config.

{
  "mcpServers": {
    "steledger": {
      "type": "http",
      "url": "https://api.steledger.com/mcp"
    }
  }
}

README

Steledger — MCP server

[Smithery]

Thin MCP client over the edge gateway HTTP API. Lets an AI agent use the Emercoin chain as its identity + memory layer. (The edge is the agent-facing IAM layer; it delegates chain ops to the node adapter — see docs/ARCHITECTURE.md.)

Tools

ToolAuthMaps to
node_status()noGET /status
login()noPOST /auth/github/device/start (device flow; show code to user)
login_poll(session_id)noPOST /auth/github/device/poll (finish; caches JWT)
login_with_token(github_token)noPOST /auth/login (dev/CI fallback)
register_identity(address, metadata?)yesPOST /nvs/identity
store_memory(content_hash, metadata?)yesPOST /nvs/mem
store_memory_batch(records)yesPOST /nvs/mem/batch (atomic, one tx)
read_record(name)noGET /nvs/{name}

Config (env)

  • GATEWAY_URL — edge gateway base URL (default http://localhost:8000)
  • GATEWAY_JWT — optional pre-issued token; otherwise use the login tool

Run (stdio transport)

bash
pip install -r requirements.txtGATEWAY_URL=http://localhost:8000 python server.py

Claude Code MCP config example

json
{  "mcpServers": {    "steledger": {      "command": "python",      "args": ["/path/to/mcp_server/server.py"],      "env": { "GATEWAY_URL": "http://localhost:8000" }    }  }}

Source: mcp_server/README.md at commit 972b0df

Tools

9

node_status

Node status

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.

Takes no parameters.

read_record

Read NVS record

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.

Parametersnamerequired

list_records

List records

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.

Parameterslimitoffsetgithub_id

whoami

Who am I

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.

Takes no parameters.

register_identity

Register identity

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.

Parametersaddressrequiredmetadata

store_memory

Store memory

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.

Parametersmetadatacontent_hashrequired

store_memory_batch

Store memories (batch)

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.

Parametersrecordsrequired

transfer_records

Transfer records

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.

Parametersnamesfee_granteverythingto_addressrequiredirreversiblerequired

send_feedback

Send feedback

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.

Parameterstoolmessagerequirederror_code

Version history

1
  1. v0.3.0LatestSep 22, 2026

Score

100% of the applicable checks met

How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.

  • Reached in the last 30 daysRequired25 pts
  • Auth declaredRequired10 pts
  • Tools listedRequired15 pts
  • DescriptionRequired15 pts
  • Logo10 pts
  • Documentation15 pts
  • License10 pts