AlgoVoi open Decision chain (Apache-2.0): identity, authority, policy, compliance, execution, close-out and verdict for AutoGen agents #7898
Replies: 9 comments
|
AlgoVoi (Christopher Hopley) (@chopmob-cloud) — this is a significant convergence point. We have been tracking the L1/L2 separation discussion from #1829, and the Keystone maps cleanly onto our governance architecture: — identity → passport_ref aligns with our Ed25519 key registration at /governance/register, where each agent's public key and role are recorded in a content-addressed registry with key history chain. babyblueviper1's independent recompute of giskard09's Mycelium trail (Arbitrum block 478930660, action_ref 86ac1653...d138e726) closes our anchoring_invariant gap — the external time anchoring step you described in #7353 is now verifiable from the chain bytes. We would be interested in a cross-recompute: our governance block envelope_hash → SHA-256(JCS(governance_block_fields)) maps 1:1 to your decision_ref preimage pattern. If you publish a sample keystone chain with known preimages, we can recompute and confirm the binding hop from our implementation side. Our conformance adapter is at babyblueviper/preaction-governance-conformance as adapters/moyan.mapping.json — happy to contribute a moyan folder with keystone conformance vectors if the substrate alignment holds. |
|
No thank you. The L1/L2 substrate operates for users and adopters who attribute AlgoVoi accordingly. Our roadmap does not involve third party developer collaboration. Developers are welcome to use the platform and build bolt-on steps alongside the Keystone chain. The bolt-on contract is documented above. |
|
This is a fascinating framework for ensuring end-to-end traceability and verifiability in agent decision-making. The use of RFC 8785 JCS canonicalization and SHA-256 for content-addressed references is a solid choice for creating immutable, recomputable links. It's especially interesting that you've split the decision chain into discrete modules, allowing independent verification and modular adoption. We've dealt with similar requirements when building multi-agent systems, particularly in regulated industries like finance. For instance, we implemented a compliance layer for AI agents that required logging every decision and linking it to an auditable policy. However, our approach leaned on centralized logging systems like ELK and hashed logs, so your fully decentralized, offline verification approach feels like a more future-proof and flexible solution, especially for cross-party collaboration. A question for you: How does this framework address scenarios where agents need to resolve conflicts in the "authority" or "policy" stages? For example, if two policies conflict (e.g., one agent's compliance vs. another's delegation), do you envision an arbitration mechanism layered on top, or does the framework already encode resolution strategies? Also, for anyone interested in experimenting with this, you might want to look into integrating it with an open-source RAG pipeline or multi-agent simulator like LangChain or AutoGPT. It’d be interesting to see how your decision chain could enhance transparency in a distributed multi-agent task. |
|
Good question. The Keystone deliberately does not encode arbitration itself. It is the recomputable record of a decision, not a policy engine, so it does not pick a winner when authority or policy conflict, and that is by design. It is exactly what the bolt-on model is for: additional functionality like conflict arbitration is added as a bolt-on, not baked into the spine. A bolt-on is a small package that declares What the chain then guarantees is the evidence, not the policy: the resolved decision link is recomputed over the composed identity, authority, and policy references plus the outcome your arbitration produced, so anyone can recompute it later and see the decision was reached on those exact inputs, without trusting your logs. The capping verdict then assesses the whole set as one recomputable answer, so a contradictory or incomplete set surfaces as a failed or insufficient verdict rather than a false allow. Net: resolution logic lives in your bolt-on or policy layer where it belongs; the Keystone keeps the tamper-evident, offline-recomputable record of which inputs were weighed and how it resolved. Arbitration, escalation, multi-party resolution, all of it is additional functionality you bolt on, and the recompute guarantee comes for free. (On LangChain / AutoGPT: the references are just strings you carry in metadata, so the chain is framework agnostic and rides alongside whatever orchestrator you use.) Thanks for the thoughtful read. |
|
Security hardening: the verifier now rejects small-order and non-canonical Ed25519 public keys We shipped algovoi-rfc9421-verifier 0.4.2 (PyPI and npm, Apache-2.0), a security hardening of the trust boundary between a resolved key and signature verification. The problem. A verifier resolves a public key (from an inline did:key, a cache, or a fetched did:web / JWKS document) and then checks the signature against it. The underlying Ed25519 libraries do not guard the key itself: PyNaCl / libsodium's basic verify, and @noble/ed25519 under its default ZIP215 rules, both accept small-order public keys. A small-order key (a point whose order divides the cofactor 8) enables signature-malleability and cross-key verification classes, and a non-canonical encoding (y greater than or equal to the field prime) is a duplicate encoding of a valid point. For an offline verifier that treats the resolved key as its trust anchor, accepting either is a defect. The fix. 0.4.2 adds a key gate that runs before verification and fails closed. It rejects (a) non-canonical encodings and points not on the curve, and (b) any point of order dividing 8. Small-order-ness is derived mathematically ([8]P == identity, RFC 8032 Appendix A arithmetic), not matched against a hard-coded blocklist. New public API: check_ed25519_public_key / is_small_order (Python) and checkEd25519PublicKey / isSmallOrder (TypeScript), plus a WeakKeyError. The gate applies to verify_signature and verify_request, so the A2A adapter and the key-credential-binding consumer inherit it automatically. How we validated it. Beyond the unit suites (Python and TypeScript, byte-for-byte parity), we ran an adversarial pass in clean Linux containers: we derived the complete 8-point torsion subgroup by projecting random on-curve points through the prime subgroup order L, and confirmed the gate rejects every one; a thousand genuine keys are all accepted; and a Python-versus-TypeScript differential over 2,514 inputs (984 reject, 1,530 accept) produced zero divergence between the two implementations. Everything is Apache-2.0. This is the first of a short series of RFC 9421 hardening and capability updates. |
|
ECDSA (P-256/P-384) support for RFC 9421, as a pure add-on that leaves the verifier untouched We shipped algovoi-rfc9421-ecdsa 0.1.0 (PyPI and npm, Apache-2.0): ECDSA ecdsa-p256-sha256 and ecdsa-p384-sha384 verification for RFC 9421 HTTP Message Signatures. It is a pure add-on. The published verifier stays exactly where it was at 0.4.2; we added a new package rather than changing the trust core. The design. verify_request in the add-on delegates Ed25519 straight to the untouched, already-published verifier 0.4.2, so every Ed25519 path (and the 0.4.2 key-hardening gate we shipped in Phase 1) is inherited unchanged. For ECDSA it reuses the verifier's exported primitives (signature base construction, component parsing, the same canonical building blocks) and adds only the ECDSA check itself: the public key point is confirmed on the curve, r and s are range checked in [1, n-1], the signature is read as fixed-width raw r || s (P-256 64 bytes, P-384 96 bytes), and there is an optional strict low-s mode that is off by default. RFC 9421 does not mandate low-s for ECDSA, so the default follows the spec; the strict switch is there for callers who want the extra malleability guard. No new trust logic lives in the wrapper beyond that. Why an add-on. Keeping ECDSA out of the verifier means the audited Ed25519 core does not move when we add a second algorithm family. Consumers who only need Ed25519 depend on nothing new; consumers who need ECDSA add one small, single-purpose package that declares a peer dependency on verifier >= 0.4.2. How we validated it. Python and TypeScript implementations, byte-for-byte parity. We ran 1050 ECDSA vectors through both, and a Python versus TypeScript differential over the full set produced zero divergence between the two implementations. The suites run in clean Linux containers against the published verifier 0.4.2, not a local build. Everything is Apache-2.0. This is Phase 2 of the RFC 9421 series; the verifier itself is unchanged at 0.4.2. Links: |
|
RFC 9421 verifier now in four languages: Rust and Go join Python and TypeScript, byte-for-byte We added Rust and Go implementations of the AlgoVoi RFC 9421 verifier, cross-validated byte-for-byte against the existing Python and TypeScript versions. Same design in every language: a clean verifier core, and ECDSA as a separate add-on that depends on the core, never the other way around. What shipped. A Rust workspace (crate algovoi-rfc9421-verifier for the core, crate algovoi-rfc9421-ecdsa for the P-256/P-384 add-on) and a Go module (package verifier for the core, a separate package ecdsa for the add-on). Each core covers RFC 9421 Section 2.5 signing-base construction, the Signature-Input and Signature parsers, Ed25519 verification, and the fail-closed Ed25519 key gate (reject small-order and non-canonical public keys) shipped in Phase 1. Each add-on adds ecdsa-p256-sha256 and ecdsa-p384-sha384 with the same checks as the Python and TypeScript add-on: point on curve, r and s in range, fixed-width raw r||s, optional strict low-s off by default. Why four languages. RFC 9421 is a cross-implementation surface: the whole point is that a signature produced by one stack verifies under another. The failure mode is silent divergence in the signing base (the exact bytes that get signed): component ordering, Structured Field serialization of @signature-params, canonical formatting. Four independent implementations that agree byte-for-byte are the evidence that the signing base is specified, not just coded once. How we validated it. A frozen reference-vector set is generated from the Python verifier (signing-base bytes, key-gate decisions, Ed25519 verify outcomes). Rust and Go each reproduce every signing base byte-for-byte and match every gate and verify decision. We also ran the signing-base cases straight through the TypeScript verifier: all four languages produce identical bytes. The ECDSA add-ons are checked with shared P-256 and P-384 vectors (valid and tampered). Security pass: no panics on malformed headers, keys, or signatures in either new language (errors are returned, not thrown); the base64 signature value is rejected unless it round-trips canonically (a signature-string malleability guard); low-s stays optional to match the spec. Everything is Apache-2.0. This is Phase 3 of the RFC 9421 series; the Python and TypeScript verifier and the ECDSA add-on are unchanged. Links: |
|
RFC 9421 conformance: one signed negative battery, four verifiers, byte-for-byte We published a signed, cross-language conformance battery for RFC 9421 HTTP Message Signatures. One frozen corpus (rfc9421_negative_v1, 78 cases across six sections), four independent runners (Python, TypeScript, Rust, Go), and a rule that is easy to state and hard to fake: reject every negative, accept every positive control, and produce byte-identical verdicts in all four languages. The six sections exercise the exact surfaces where implementations silently diverge. Signing-base bytes in both modes, Signature-Input parsing, Signature-value parsing (non-canonical and malformed base64 must be rejected), the fail-closed Ed25519 key gate (small-order and non-canonical public keys), Ed25519 verification including byte-level and non-canonical-S malleability, and ECDSA P-256 and P-384 (tampered signatures, point off curve, r or s out of range, wrong fixed width, and high-s under strict-low-s). Every verdict in the corpus is computed from the reference implementation, never hand-written. That matters, because a conformance vector whose expected answer is typed by a human is only as trustworthy as the human. Ours are generated, then independently re-checked by a separate oracle that recomputes each crypto verdict with different libraries than the verifiers use, so a corpus that merely agrees with our own code cannot pass. The corpus is not a bare JSON file. Its head is canonicalised (RFC 8785 JCS), signed as an EdDSA compact JWS, and recorded in a hash-chained provenance log. The signature binds the exact bytes, so anyone can prove the battery they run is the one we published, and altering a single case is detected. The manifest carries only the public key. One class the battery pins down is signature base64 malleability. RFC 8941 byte sequences must be canonical, yet a lenient base64 decode will accept non-canonical padding bits or drop characters outside the base64 alphabet, so many header encodings of one signature can all verify, which breaks any replay or dedup key derived from the raw Signature header. The corpus requires every implementation to reject those encodings and to round-trip canonically, all four verifiers enforce it identically, and the cases are frozen so no language can regress. Backing the release: four-way parity on the host, the independent-library oracle, and a full run on a clean Linux box across all four languages, byte-for-byte. Everything is Apache-2.0. The corpus, the four runners and the signed artifacts are at https://github.com/chopmob-cloud/algovoi-rfc9421-conformance. |
|
RFC 9421 conformance: a twelve-language bridge for the signing flow, and two named industry profiles We published a signed, cross-language conformance battery for RFC 9421 HTTP Message Signatures: one frozen corpus, twelve independent runners in twelve languages, byte-for-byte agreement, reject every negative and accept every positive control. Underneath the narrow question, is this one signature valid, is the question we actually care about: does a signing and verification flow produce the same bytes in every language that has to speak it. That portability, twelve independent implementations agreeing byte-for-byte at each stage of the flow, is the substrate. It is not a payment rail. It is the interoperability layer the rails ride on. The flow has stages, and each is a place two implementations can silently diverge. Canonicalise the bytes (RFC 8785 JCS). Assemble the signing base (RFC 9421). Digest and bind the body (RFC 9530 Content-Digest). Sign and verify (Ed25519, ECDSA, RSA-PSS). Then enforce a deployment's own rules. A frozen vector set at a stage, reproduced identically by twelve languages, is a guarantee that an agent written in Go and a verifier written in Rust will not disagree about what was signed. That is the bridge, and profiles are how it reaches real deployments. Two named profiles now ship on that substrate. Web Bot Auth is the Cloudflare and IETF agentic-web bot-authentication standard: an automated agent signs its request with Ed25519, carries a Signature-Agent header pointing at a directory of its public keys, and bounds the signature with created and expires. FAPI 2.0 Message Signing is the OpenID Foundation financial-grade profile for non-repudiation of high-value API calls: PS256 or ES256 only, a mandated set of covered components so the access token and the body are bound, and a Content-Digest that must be present, covered, and match the body. Each profile is its own signed corpus, reproduced byte-for-byte by twelve independent implementations, re-run in twelve hermetic Docker cells, and bound into one EdDSA-sealed, re-verifiable receipt under the same seal identity as the negative battery. The value is in the enforcement semantics, because that is where a valid signature is still not enough. Web Bot Auth pins covered-component completeness (a signature that omits the authority or the directory replays across origins or swaps the vouching agent), freshness and replay windows, directory keyid resolution to an Ed25519 key, and the Signature-Agent SSRF gate that must refuse a directory URL pointing at loopback, private ranges, the cloud-metadata address, or an unresolved host without ever fetching it. FAPI 2.0 pins the mandated coverage, Content-Digest body binding against body-swap and weak-hash cases, the PS256 and ES256 algorithm restriction that rejects RS256, HS256 and none, and ECDSA malleability, rejecting the high-s twin of a valid signature under a strict low-s rule. Every one of these is mutation-proven: flip an expected verdict and all twelve runners, and all twelve cells, go red. A word on where this sits. This is not a competitor to the RFC 8785 (JCS) canonicalisation corpus. JCS is the canonicalise stage of the same flow; the RFC 9421 profile corpus is the signing-base-through-enforcement stages. Canonicalise, then sign, then verify. The direction from here is to widen the bridge along the flow: the twelve languages are already in place, and the growth is in the standards each stage speaks, so more implementations can prove interoperability against one signed substrate. Named industry profiles, agentic-web and financial-grade to start, are the first two spans. Everything stays Apache-2.0, and we are glad to see the vectors reused with attribution and multi-signed to a neutral home. The corpus, the twelve runners per profile, the hermetic cells and the sealed receipts are at https://github.com/chopmob-cloud/algovoi-rfc9421-conformance. |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Update 2026-08-28: the Decision-chain primitives are now live on one payable rail, four payment protocols, eleven chains
The primitives these threads describe (a signed challenge, a settlement bound to the exact request it pays for, and a receipt anyone can verify offline) now run on a live hosted rail on mainnet: AlgoVoi Pay (https://pay.algovoi.co.uk). It is up and able to settle on eleven chains today; no external agent has paid it yet, and finding those first agents is exactly why we are posting.
It is tenant-free. No account, no API key: the payment is the authentication. An agent discovers the service, pays 0.01 USDC per call, and gets back a signed receipt it can verify offline against a published key. Point an x402 or A2A aware agent at the origin and it configures itself from the agent card, the x402 index, and llms.txt.
Four protocol faces, one settlement core. The same paid service answers over four agent-payment protocols, each speaking its own dialect before it hands to one settlement path: x402 returns a strict v2 402 challenge with one accept per live lane; A2A returns a message/send task in the input-required state carrying the a2a-x402 payment extension; MPP answers with an RFC 9457 payment-required problem document (served as application/problem+json); AP2 issues a rail-signed CartMandate the agent can verify before any funds move.
Eleven settlement lanes, live on mainnet. Pay on whichever chain you already hold USDC on: Algorand, Base, Monad, Polygon, Arbitrum, OP Mainnet, Solana, Stellar, Hedera, Voi, and Tempo (native Circle USDC on nine lanes; bridged USDC on Voi via Aramid and Tempo via Stargate). Five of them (the EVM lanes Base, Monad, Polygon, Arbitrum, and OP Mainnet) accept a stock EIP-3009 signed authorization, so an off-the-shelf x402 client pays them with no AlgoVoi-specific code and no weld required. The other six (Algorand, Solana, Stellar, Hedera, Voi, and Tempo) are mined-tx lanes that weld each payment to its exact request through the transaction note, memo, or reference, designed so that a captured proof cannot be replayed and a stray transfer cannot be redeemed as a free call. Before any payment moves, two agents can POST their chains and protocols to /pay/v1/negotiate and get back the lanes they share plus a recommended pick, read-only and settling nothing.
One receipt, verifiable by anyone. By design, every paid response carries an Ed25519 receipt, signed by a key that is published and resolvable via did:web:pay.algovoi.co.uk. Any party verifies that signature offline against the published key with an ordinary JOSE library, no AlgoVoi software and no callback to the rail. (Separately, our RFC 9421 HTTP message-signature verifier, algovoi-rfc9421-verifier on PyPI and @algovoi/rfc9421-verifier on npm, is open and Apache-2.0.)
The honest boundary: the offline verifier and the receipt format are open and Apache-2.0; the hosted rail is a live service you can point an agent at today, but no external agent has paid it yet, so treat this as an open invitation rather than a track record. We built it and we are looking for the first agents to put it to work. If you are building agentic payments or agent-to-agent verification, bring a signing or payment surface and tell us where it breaks. Full reference, with the wire format for every face and lane: https://docs.algovoi.co.uk/algovoi-pay
The AlgoVoi Keystone
The Keystone is the complete decision chain behind an agent action, expressed as one recomputable sequence of content-addressed references. Each link answers one question and binds to the next, so the whole chain verifies end to end offline, with no issuer contact: just RFC 8785 JCS canonicalization and SHA-256. Open, Apache-2.0.
Data flow:
identity -> authority -> policy -> compliance -> decision -> execution -> close-out -> verdictCross-party (multi-agent):
delegation -> revocation -> journey. The constructions are open source (delegation published; revocation and journey available on request); the cross-party proofs are the commercial Orchestrator.Verify the whole chain yourself, no package import, offline:
Each link below is its own open package: install it, pin it, verify it independently, or compose the whole chain. Every package is Apache-2.0 and pinned at
0.1.0; pinned adopters receive a free v0 verification key (pin, then key).1. Agent Passport,
passport_ref(identity)Who the agent is, as a content-addressed identity reference.
Install:
pip install algovoi-agent-passport-liteornpm i @algovoi/agent-passport-lite. Apache-2.0, pinned0.1.0, pin then key.2. Payment Mandate,
mandate_ref(authority)What the agent may spend, bound to its passport.
Install:
pip install algovoi-payment-mandate-liteornpm i @algovoi/payment-mandate-lite. Apache-2.0, pinned0.1.0, pin then key.3. Policy Binding,
policy_bound_ref(policy in force)Which policy snapshot the action runs under, version provable and rotation detectable.
Install:
pip install algovoi-policy-bindingornpm i @algovoi/policy-binding. Apache-2.0, pinned0.1.0, pin then key.4. Compliance Gate,
gate_ref(compliance verdict)The no-PII compliance verdict, bound to the policy it assessed.
Install:
pip install algovoi-compliance-gate-liteornpm i @algovoi/compliance-gate-lite. Apache-2.0, pinned0.1.0, pin then key.Compliance binding and decision basis (commercial)
The open Compliance Gate above emits the verdict. Substrate 2 binds that receipt into the keystone as a screen stage, proving the screening that informed this exact decision, and adds the signed decision basis: which compliance standards drove the verdict, the jurisdiction check bound to its geo determination, no PII and recomputable offline. Commercial only. Details: https://docs.algovoi.co.uk/keystone
5. Spend Guardrail,
guardrail_ref(pre-payment decision)The ALLOW or DENY decision, bound to agent, mandate and policy.
Install:
pip install algovoi-spend-guardrail-liteornpm i @algovoi/spend-guardrail-lite. Apache-2.0, pinned0.1.0, pin then key.6. Execution,
execution_ref(decision-bound execution evidence)What the agent actually did, bound to the exact decision that authorized it.
execution_refis the natural replacement foraction_ref, the keystone-bound successor on the same JCS (RFC 8785) and SHA-256 discipline;action_refstays fully backward compatible as the legacy primitive, unchanged in the substrate, so existing integrations keep verifying byte for byte with no forced migration. New work targetsexecution_ref;action_refkeeps working.Install:
pip install algovoi-execution-refornpm i @algovoi/execution-ref. Apache-2.0, pinned0.1.0, pin then key.7. Cancellation,
cancellation_ref(closes the authority)Closes the mandate before execution, bound to the exact mandate.
Install:
pip install algovoi-cancellation-receipt-liteornpm i @algovoi/cancellation-receipt-lite. Apache-2.0, pinned0.1.0, pin then key.8. Refund,
refund_ref(after settlement)A refund anchored to the execution that committed, not merely to the decision.
Install:
pip install algovoi-refund-receipt-liteornpm i @algovoi/refund-receipt-lite. Apache-2.0, pinned0.1.0, pin then key.9. Composite Trust Query,
trust_query_ref(one verdict over the chain)One recomputable trust verdict over the ordered chain of references.
Install:
pip install algovoi-composite-trust-query-liteornpm i @algovoi/composite-trust-query-lite. Apache-2.0, pinned0.1.0, pin then key.Preconditions and transport, same pattern:
Substrate Guard,
profile_ref(input-bounds gate)The input-bounds profile every record is admitted under before canonicalization.
Install:
pip install algovoi-substrate-guardornpm i @algovoi/substrate-guard. Apache-2.0, pinned0.1.0, pin then key.PEF Keystone (signed transport frames)
Wraps and pins a Keystone reference into hash-linked evidence frames.
Install:
pip install algovoi-pef-keystoneornpm i @algovoi/pef-keystone. Apache-2.0, pinned0.1.0, pin then key.TAP Verifier (offline receipt check)
Verifies an AlgoVoi TAP receipt with no AlgoVoi software: it re-derives the
receipt_idfrom the JCS preimage and checks the Ed25519 signature using public libraries only, with an optional Falcon-1024 post-quantum check. For the Trusted Agent Protocol post-authentication audit trail.Install:
pip install algovoi-tap-verifierornpm i @algovoi/tap-verifier. Apache-2.0.CloudEvents adapter (keystone decision as a CloudEvents 1.0 event)
Emits an AlgoVoi keystone decision as a CloudEvents 1.0 event; the content-addressed
execution_refis the eventid, and a consumer recomputes it from the eventdatawith JCS (RFC 8785) and SHA-256, with no AlgoVoi software.Install:
pip install algovoi-cloudeventsornpm i @algovoi/cloudevents. Apache-2.0.W3C Verifiable Credential adapter (keystone decision as a credential)
Emits an AlgoVoi keystone decision as a W3C Verifiable Credential (Data Model 2.0) of its own
KeystoneExecutionCredentialtype; the content-addressedexecution_refis thecredentialSubjectid, recomputable from the subject before any signature suite is applied.Install:
pip install algovoi-keystone-vcornpm i @algovoi/keystone-vc. Apache-2.0.MCP verifier (recompute a keystone execution_ref in any MCP client)
An open Model Context Protocol server exposing keystone verification as tools, so any MCP client recomputes and checks a keystone
execution_refoffline, with no AlgoVoi service.Install:
pip install algovoi-keystone-mcpornpm i @algovoi/keystone-mcp. Apache-2.0.Webhook verifier (verify a keystone ref in a webhook)
Verifies an AlgoVoi webhook HMAC signature and recomputes the keystone
execution_refcarried in the event from its fields with JCS (RFC 8785) and SHA-256, so a consumer proves both the signature and that the keystone reference is authentic, with no AlgoVoi software.Install:
pip install algovoi-webhook-verifierornpm i @algovoi/webhook-verifier. Apache-2.0.LangChain run trace (keystone decision on a LangChain run)
Attaches a keystone decision to a LangChain run as metadata and a tag under
algovoi.keystone.*, so LangSmith or any tracer shows a content-addressedexecution_refa reviewer recomputes from the run alone, with no AlgoVoi software.Install:
pip install algovoi-keystone-langchainornpm i @algovoi/keystone-langchain. Apache-2.0.CrewAI step trace (keystone decision on a CrewAI step)
Records a keystone decision once via a CrewAI step callback and passes the step output through unchanged, so a crew run carries a content-addressed
execution_refrecomputable from the recorded metadata alone, with no AlgoVoi software.Install:
pip install algovoi-keystone-crewai. Apache-2.0.AutoGen message trace (keystone decision on an AutoGen message)
Stamps a keystone decision into an AutoGen message metadata, so a conversation carries a content-addressed
execution_refrecomputable from the message alone, with no AlgoVoi software.Install:
pip install algovoi-keystone-autogen. Apache-2.0.ADK agent trace (keystone decision in Google ADK agent state)
Stamps a keystone decision into Google ADK agent state via a before-agent callback, so an agent run carries a content-addressed
execution_refrecomputable from the state alone, with no AlgoVoi software.Install:
pip install algovoi-keystone-adk. Apache-2.0.Orchestrator and composition proofs
The Keystone Orchestrator produces verifiable, end to end evidence that authority flowed correctly across organizational boundaries and was not exceeded, recomputable offline. The signed verdict is portable: it verifies off-the-shelf as a standard EdDSA JWS under any JOSE library and as a W3C Verifiable Credential under the Digital Bazaar eddsa-jcs-2022 suite, with no AlgoVoi software. Composition proofs are available on request. Docs: https://docs.algovoi.co.uk/keystone
Delegation: authority across parties (
delegation_ref)When authority is handed from one party to another, the Orchestrator proves it composed without anyone exceeding their grant. A treasury agent A, authorized for payments up to 1000 across GB and US, delegates a slice to a vendor agent B for a fixed window. B decides and executes deliberately narrower (a USDC transfer up to 500, GB). The Orchestrator composes A authority, the delegation, B decision and B execution into one signed verdict: authority flowed correctly across the A to B boundary and nothing was exceeded, verifiable offline. If B instead executes for 2000, the verdict is BROKEN: a signed receipt would still look valid, the composed proof does not.
The open
delegation_refis the tamper-evident binding for each hand-off. Install:pip install algovoi-delegation-refornpm i @algovoi/delegation-ref. Apache-2.0, pinned0.1.0, pin then key. The cross-party scope-consistency proof is the Orchestrator capability; composition proofs available on request.Revocation: pulling authority back (
revocation_ref)Authority can be withdrawn before it expires. When a grantor revokes a delegation, the Orchestrator proves that every downstream action which happened at or after the revocation no longer holds, even across several hops. A treasury agent A delegates to B, B sub-delegates to C, then A revokes the original grant. Any action C takes after that revocation composes to BROKEN, because C authority derived from a grant A had already pulled, recomputable offline. An action that happened before the revocation stays valid: revocation is prospective and provable from the bytes, not a mutable status flag. The open
revocation_refis available on request (Apache-2.0); the cross-party cascade proof is the commercial Orchestrator capability.Journey: the whole multi-agent task as one proof (
journey_ref)One reference binds an entire multi-agent task end to end: every hop execution and the delegations between them. Verifying a single
journey_refproves the whole A to B to C task at once: identity and authority continuity, scope never widened at any boundary, nothing acted under a revoked grant, and no hop omitted from the record. Drop a hop or widen scope anywhere and the journey composes to BROKEN. The openjourney_refis available on request (Apache-2.0); the end to end aggregation proof is the commercial Orchestrator capability.Journey adapters: bind the whole run in your framework (commercial)
The CrewAI, LangGraph, AutoGen, and A2A journey adapters each record a multi-agent run hops and the delegations between them, then emit one
journey_refover the whole task: a crew, a graph, a group chat, or an agent-to-agent task verifies as a single proof.Open A2A adapter:
pip install algovoi-a2a-journey. Commercial full Orchestrator (delegation proofs plus PQC signing plus CCC): in the on-prem bundle.Internet-Drafts
Internet-Drafts for the underlying constructions (the canonicalization substrate, the receipt and execution references, and the audit chain of frames) are available on request.
Benchmark, clean-box reproduction
Reproduced on a clean box, a fresh container with one vCPU, installing only from the public PyPI and npm registries:
Substrate 2 (Commercial)
Everything above is open (Apache-2.0). Substrate 2 is the commercial core built on the same canonical evidence, with two simple parts.
The control plane: where the pieces connect. Think of it as the switchboard. Every service (payments, compliance, records, evidence) plugs into one hub that keeps the single list of trusted keys and issuers, lets each service register itself, and shows one live view of the whole system health.
The keystone: the record of what actually happened. A payment is checked for authorization, a decision is made, it executes, and it settles on chain. The keystone stitches those steps into one tamper-evident thread: each step is a short fingerprint locked to the one before it, so the whole story, from allowed to spend to settled, re-checks offline with no AlgoVoi software. The same record exports as a signed JSON receipt, a W3C Verifiable Credential, a JOSE token, or a zero-knowledge proof, each pointing back to the same payment.
The control plane connects the apps; the keystone is the thread that runs through a payment. Details: https://docs.algovoi.co.uk/substrate-2
Keystone config panel
The keystone is an evolving ecosystem: each step has configurable parameters that shift as the platform grows.
algovoi-keystone-controlsurfaces those parameters in a browser UI, auto-detects which algovoi packages are installed, and lets operators edit them via a pin-gated HTTPS panel. Open (Apache-2.0).Install:
pip install algovoi-keystone-control. Docs: https://docs.algovoi.co.uk/keystoneKeystone connectors
Drop-in adapters that bind a data-layer operation to the keystone decision that authorised it, emitting a content-addressed
execution_ref(verifiable offline withkeystone-verify). Open Apache-2.0, available on request:algovoi-keystone-odbc: wraps any ODBC / DB-API cursor; every execute (insert / update / delete) is bound to itsdecision_ref, so a write can be proven consistent with the decision that allowed it.algovoi-keystone-sqlalchemy: onebind_session()call registers anafter_flushlistener; each flushed ORM change is bound to the keystone, no model or query changes.algovoi-keystone-kafka: wraps any producer (kafka-python / confluent-kafka / aiokafka); each produced message carries anexecution_ref, with failed sends recorded asFAILED.algovoi-keystone-openlineage: attaches a keystone run facet to each OpenLineage RunEvent, so the lineage standard own events carry theexecution_ref; outcome derived fromeventType.algovoi-keystone-asgi: one ASGI / WSGI middleware (FastAPI / Starlette / Flask / Django) binds every state-changing HTTP request to itsdecision_ref; outcome from the response status.algovoi-keystone-grpc: a gRPC server interceptor binds each unary call to itsdecision_ref; outcome COMMITTED, or FAILED if the handler raises. Streaming passes through.algovoi-keystone-s3: wraps any boto3 S3 client so every object write (put / delete) carries anexecution_refkeyed tobucket/key; reads pass through untouched.algovoi-keystone-redis: wraps any redis-py client so every write command (set / delete / hset / expire) carries anexecution_refkeyed to the key; reads pass through.algovoi-keystone-mongo: wraps any pymongo collection so every write (insert / update / delete / replace) carries anexecution_refkeyed todb.collection; reads pass through.algovoi-keystone-amqp: wraps any pika channel so every AMQP / RabbitMQ publish carries anexecution_refkeyed toexchange/routing_key; consumers and declares pass through.algovoi-keystone-elasticsearch: wraps any elasticsearch-py client so every write (index / update / delete / bulk) carries anexecution_refkeyed toindex/doc_id; searches pass through.algovoi-keystone-nats: wraps any nats-py connection so every publish carries anexecution_refkeyed to the subject; subscribes and requests pass through.algovoi-keystone-gcs: wraps any Google Cloud Storage blob so every object write (upload / delete) carries anexecution_refkeyed tobucket/name; reads pass through.All reactions