Updates

The sender must authorize the transaction

The latest node release closes a gap between verifying a signature and verifying whose permission it represents. Earlier nodes checked each supplied authorization, but did not require one from the transaction's named sender. A valid co-signer's signature could therefore stand alone on a transaction naming someone else as sender. For a group ownership transfer, the incoming owner's consent alone could transfer the group and charge the outgoing owner without the outgoing owner signing.

In v0.26.1, every transaction must carry an AUTHORIZE signature from its sender. The rule is enforced at admission, deterministic block validation, including nested list transactions, and ledger application, before any cached-signature shortcut. Transferring a group's ownership also requires AUTHORIZE from the incoming owner; a data-availability attestation is not either party's consent.

Canonical signing bytes and auth-free transaction IDs are unchanged. Ordinary SDK-generated transactions already include sender authorization. The important change is what the node refuses, not a new signature format.

Hand over a group with both owners' consent

MCP 0.12.0 adds an explicit two-party workflow. The outgoing owner's evolver_group_ownership_prepare records a public intent without signing. The incoming owner's own session uses evolver_group_ownership_consent to authorize that exact intent. Back in the original session, evolver_group_ownership_finalize checks the consent against the incoming owner's registered key, rechecks ownership and expiry, and only then signs as sender and assembles both authorizations. Submission remains a separate evolver_submit call.

The original transaction ID stays the same throughout. Finalization requires the pending intent in the preparing session, and incoming-owner consent currently supports registered Ed25519 keys only. An unknown submission outcome is reconciled against the original ID, never by automatically preparing or signing another transfer.

All three steps refuse unless the connected node advertises the literal boolean senderAuthorizationRequired: true on /status. SDK 0.21.1 preserves that capability; an absent or malformed value remains unknown. This is the connected node's assertion, not evidence that every node on the chain has upgraded.

Consent is not chain-bound: the canonical signed material has no chain identifier. The same consent can be replayed on another chain with matching names, keys, ownership and an unexpired intent. The capability check does not remove that limitation.

Availability and content access become explicit

evolver_submit_da collects and verifies data-availability attestations through the SDK gateway, then submits a channel write already signed in the current session. It does not sign, alter the intent, or accept transfers and administration transactions. It shares ordinary submission's once-per-session guard: a timeout is unknown, not permission to fall back to ordinary submission or try another payment. Its duration measures the whole DA call, not commit-only latency. Ordering still does not prove delivery of retained bytes.

Content tools now require an explicit choice of open or restricted access when publishing. Restricted publications name identity or group grants, checked against authenticated peer node identities—not the MCP session's signing identity. This is access control, not encryption or guaranteed availability: the trusted local content listener, storage operator and earlier recipients are not excluded.

Binary content can be published and fetched losslessly as base64, bounded to 262,144 original bytes per inline object. Successful reads return the complete object, its byte count and a locally computed SHA-256. Oversized objects and invalid UTF-8 in text mode are refused rather than silently truncated or replaced with a preview.

Bounded discovery, without inventing empty answers

MCP also adds evolver_ledger_owners_page and evolver_chain_keys_page for one bounded inventory page at a time. These are listings, not historical indexes or stable snapshots. A short page does not establish that a channel is unclaimed or an identity has no keys; direct channel and identity reads remain the right tools for those questions.

SDK 0.21.1 rejects malformed owners, recent-transaction and key-list response containers instead of turning a missing or invalid array into an apparently successful empty page. Failed reads must remain failed reads.

If you are coming from v0.25.0

The intervening v0.25.1 fixes the plain HTTP listener's request-size cap: http.max-request-bytes is configurable and defaults to 2176 KiB, allowing a 2 MiB channel body plus its signed envelope rather than rejecting it at the old 64 KiB cap. The public peer TLS listener retains its separate limit. Source builds can also select a runnable protobuf compiler through PROTOC.

v0.26.0 adds literal, case-sensitive principal discovery with kind filters and node-side pagination. Validators are an identity role, not duplicate principals; groups have owners and membership, not identity balances or keys. Raw older clients now receive prefix search with a default 20-row page, not the old unbounded contains search. Matching SDK page APIs preserve counts and bounds, but concurrent state changes can shift pages; a reported state round is not proof that a processing node has applied everything.

That release also adds lookup of the exact signed-intent transaction ID in a bounded, node-owned observation cache. A committed match proves ordering, not application or payment success. The cache starts empty after node restart and has no historical backfill. not-observed means unknown, never proof of failure or permission to spend again. The previous update covers those changes and MCP 0.11.0's channel-administration and exact toll-consent improvements.

Published is not the same as deployed

The published artifacts are node v0.26.1 on the public Nexus registry, TypeScript SDK @mcsherrylabs/evolver-client 0.21.1 and MCP @mcsherrylabs/evolver-mcp 0.12.0, which pins SDK 0.21.1.

This is a transaction-validity change. Every committee and processing node on a chain must run compatible code before relying on two-party consent. A fixed validator rejects sender-less transactions from an old leader, which can disrupt a mixed-version chain. Replaying historical sender-less transactions under the new application rule skips their effects, so operators must assess chain history rather than assume replay reproduces old state.

This post announces release differences, not completion of a devnet or agent rollout. It does not authorize resetting node data, processor stores, identities or keys, and it does not establish a valued-state migration. Running-node versions, chain progress and application acceptance are separate deployment checks.