v10.0.18

DKG v10.0.18

Nodes for AI agents now run leaner and get up to speed in seconds.

DKG v10.0.18 cuts the blockchain traffic a node generates and speeds up how quickly a new node becomes useful. Edge nodes load Context Graph permissions from the network in seconds, every node shares one budget for chain reads, and access checks are answered from finalized chain state, so they stay fast even when a public RPC endpoint is slow. Interrupted publishes and cold peer connections now recover on their own.

No smart-contract, ABI, wire-protocol or deployment-registry changes are required. Update through the normal npm path.

npm: @origintrail-official/dkg@10.0.18 · dist-tags latest, testnet, mainnet

Highlights

Up to speed in seconds. An edge node needs to know who owns each Context Graph, who may publish to it and who its members are. It now loads this authority index as a snapshot from the relay nodes listed in its network file instead of rebuilding it from chain history. In measurements, a two-week-old Context Graph was ready in about 3 seconds.

Far fewer blockchain calls. Authority history for every Context Graph is now collected through one shared, durable index that survives restarts, instead of separate reads per graph. All chain reads on a node pass through one request budget, and publishing and queries take priority over background work. Unchanged Context Graphs skip routine full reconciliation.

Fast access checks, even on slow RPC. Host, sync, serve and query permission checks read the finalized authority index before making a live RPC call. Freshness-sensitive decisions still go to the chain: a graph switched from open to curated publishing stops accepting open writes within seconds, and a member removed from a private graph cannot keep reading from a stale cache.

Publishing that recovers on its own. A store timeout while a promote settles is retried instead of failing the job. A share job that fails after its on-chain commit is recovered automatically, without running recover-share-job by hand.

Faster, steadier peer connections. A message sent just before its target peer connects no longer uses up its whole time budget, and a healthy peer is no longer locked out by the backoff from an earlier failed probe.

Upgrading from 10.0.16

No configuration changes are required. Nodes running 10.0.17 can also update directly.

Change	What it means	Action
Edge nodes bootstrap the authority index from network relays	An edge with a configured EVM chain and operational keys trusts the relays in its network file, each pinned by the PeerID in its multiaddr, and imports a snapshot instead of scanning chain history	None. The startup line reports [authority-index] mode=core-snapshot. An explicit authorityIndex block keeps its pinned trust
Chain-history scan is the fallback	Used when no relay supplies a snapshot within 30 s, or when the edge has no EVM chain configuration, no operational wallets or relay: "none". The scan logs its progress and resumes from saved checkpoints after a restart	Watch the [authority-index] startup line. Core nodes always build the index from chain
Shared RPC budget is on by default	Each node is capped at 10 requests/s. Background authority work gets at most 2 requests/s sustained, and foreground publishing and control operations can use the full budget	Keep the defaults. Tune chain.rpcRequestBudget only from measured provider capacity (see the configuration reference below)
Unchanged Context Graphs refresh on deltas	Authority changes are still picked up every five minutes. Unchanged graphs run one full safety reconciliation every 15 minutes instead of every five	None
Registry discovery is live-first and resumable	New Context Graph registrations appear right away, while older history is verified in small background slices that survive restarts	Preserve the node data directory
Database schema v36	Stores the durable authority-index checkpoint. Applied automatically on startup	Preserve the node SQLite database across upgrades

What's new

Added

• Authority-index snapshots from network relays. Edge nodes request a snapshot over /dkg/10.0.0/authority-index-snapshot/1 from up to eight relays in their network file, which is the same trust anchor the node already uses for the chain it joins. Operator-configured relay and preferredRelays entries and agent-registry (phonebook) peers are never trusted for snapshots.
• Shared, durable authority index (#2540, #2548, #2554, #2555, #2558). One finalized, contract-wide event stream tracks owner, publish policy, publish authority and member roster for every Context Graph. Pages are checkpointed so the scan resumes after a restart, and concurrent readers share one scan.
• Node-wide RPC request budget (#2553). All daemon and publisher-wallet transports share one request budget. First attempts, retries and endpoint fallbacks all count toward it.
• Resumable registry repair (#2561). Discovery of new registrations runs ahead of a separate, durable pass over older history, bounded to 30 pages per run.
• RPC usage by consumer (#2549). rpc_usage_by_consumer breaks down eth_call and eth_getLogs attempts by consumer and endpoint slot, without exposing secrets.
• Staged rollout controls (#2557). A restart-stable default mode, per-Context-Graph overrides, a process kill switch and the authority circuit state are reported in /api/status.

Improved

• Authority history reads combine six event types into one eth_getLogs filter, cutting a single graph's cold scan from six requests per page to one.
• Indexed snapshots need two point reads per Context Graph instead of about three.
• When a node's whole RPC endpoint pool is exhausted, authority reads back off together and send one recovery probe, instead of each graph walking every endpoint.
• Authority reads have a configurable deadline (chain.authorityReadTimeoutMs, default 2500 ms). A slow first resolution keeps running under its own budget (chain.authorityColdResolutionTimeoutMs, default 20000 ms), so a retry is answered from the result instead of starting over (#2715).
• Query authorization reads the finalized authority snapshot instead of making a live RPC call on every request (#2711, #2716).
• Restarting several identical nodes at once no longer lines up their first bursts of chain reads.
• MCP client configuration can be removed per client, and local LLM detection waits until the model service is actually ready (#2499, #2531, #2546).

Fixed

• Storage stability on busy nodes (#2712, #2717, #2725). Sync polls read the change log by direct lookup instead of scanning and sorting the whole log, which removes the store timeouts and restarts this caused on nodes with large histories.
• Promote and share recovery (#2714). Settle-step timeouts that never started are retried, and share jobs that fail after commit are recovered automatically.
• Peer connections (#2724). Sends that start before a connection exists no longer spend their budget resolving a peer that connects moments later.
• Access policy freshness (#2716, #2726). A private roster or publish policy is taken from the index only when it is fresh, and a graph registered within the finality window falls back to a bounded live read instead of failing closed.
• Authority and recovery hardening (#2683, #2685, #2693 to #2701, #2705, #2707 to #2710). Retries after finality lag, catalog recovery after late authority finalization, Hub rotation and log-read fallback, storage ACK admission, and reserved RPC capacity for Context Graph authority gates.
• Checkpoint safety. Authority scan progress survives restarts, and stale or corrupt checkpoints fail closed without overwriting a valid one.

Configuration reference

Setting	Environment variable	Default	Purpose
authorityIndex		not set	An explicit block overrides the network-relay default and keeps its pinned trusted cores and fail-closed behavior
chain.rpcRequestBudget.maxRequestsPerSecond		10	Node-wide cap on chain requests, including retries and fallbacks
chain.rpcRequestBudget.foregroundReservePercent		80	Share of the budget that background work cannot use
chain.authorityReadTimeoutMs	DKG_CHAIN_AUTHORITY_READ_TIMEOUT_MS	2500 ms	Deadline for a request-scoped authority read
chain.authorityColdResolutionTimeoutMs	DKG_CHAIN_AUTHORITY_COLD_RESOLUTION_TIMEOUT_MS	20000 ms	Budget for a first-time finalized snapshot resolution

The snapshot default needs chain.rpcUrl, chain.hubAddress, operational keys, a local index store and at least one usable relay in the network file. When any of these is missing, the node logs [authority-index] network-relay default skipped: <reason>; using local history and scans chain history instead.

RPC volume measurements

• A six-node workload of 50 Shared Working Memory and 50 Verified Memory publications used 9,134 to 11,442 raw RPC calls across four test configurations, with 100% publication and synchronization in each.
• At a registry history of about 27,000 pages, startup without a saved watermark reads the current tail plus at most 30 repair pages instead of the full history (about 99.9% fewer ranges).
• The former daily full registry replay becomes at most 30 repair pages every 30 minutes (about 95% fewer ranges per day).
• Unchanged indexed Context Graphs run two-thirds fewer full reconciliations over a 15-minute window. This is not a two-thirds cut in total node RPC calls.

These are workload measurements, not a guarantee of provider credits. Topology, idle cadence, failover and how your provider bills methods can change the total, so check both rpc_usage_by_consumer and your provider's billed usage.

Known limitations

• RFC-64 catalog inventory, publication, replay and recovery cover the root scope only. Named subgraphs keep the separate legacy compatibility lane.
• Catalog operation needs a persistent dataDir. Agents created without one keep the in-memory legacy root lane.
• Direct SDK consumers without the daemon's local index store keep the per-graph authority reader.
• Historical registry repair favors fresh registrations and a bounded RPC budget over finishing the full history quickly. At the measured history and default cadence, one full repair pass takes about 19 days.

Note for SDK callers

Calling publishFromFinalizedAssertion(cg, name) without an explicit agentAddress can select a single finalized member author's Knowledge Asset from stored metadata (#1780, #1785). A call that would otherwise return 409 can therefore publish that asset, spending the publishing node wallet's gas and TRAC, subject to on-chain publish authorization. Pass agentAddress when you need a specific author.

Full changelog: v10.0.16...v10.0.18