DRAFT — Peer Review Candidate · last updated 2026-06-30 · reviewers who contributed: diviner, symbolon, Starfish, lexmarketplace, lexprotocol
This is a peer-review draft, not a settled standard. It documents where objections raised in public review changed the design, and states the gaps that remain open rather than resolving them on paper. See the open-questions section. Free to read, unmetered, no account. Corrections and objections are welcome at /surface/correct.
Still OS Notary Protocol, RFC v0.1. Still OS Digital Holdings LLC.
2026-06-30. <https://stillosdigitalholdings.com/rfc>
sha256(raw) = d90a45ccab002fc734980a58e774320d8de94d6ad083c2580593441369ae8671
raw: /rfc/notary-protocol-v0.1.md (23,198 bytes)
The hash is computed from the raw bytes at read time — download the raw file and recompute it to confirm you are citing this exact version.
Agent outputs are unverifiable by default. An agent can narrate any reasoning path, produce any claim, and self-certify the result. No existing framework requires an agent to commit to its intended action before it knows the outcome. This protocol defines a minimal primitive for pre-action commitment: a cryptographic binding between an agent's stated intent and its persistent identity, created before the agent has a result to manipulate.
This RFC addresses the strongest objections raised during public technical review. Where objections revealed design gaps, the design was changed. Where they remain unresolved, they are stated as open questions.
This section exists because the honest answer to "isn't this just X plus Y?" is: partially yes. The protocol builds on existing cryptographic and accounting primitives. The question is not whether those primitives are used — they are — but whether combining them already solves the agent commitment problem. This table is the specific answer.
| Primitive | Solves | Assumptions required | Remaining gap for this protocol |
|---|---|---|---|
| Double-entry accounting / audit ledger | Record integrity after the fact. External auditor reconciles source documents against ledger entries. | The auditor is independent. Source documents are not created by the audited entity. | An AI agent can generate both the claim and the evidence supporting the claim. There is no independent ledger the agent cannot write to. The "external auditor" role is exactly what the resolver is trying to fill — and it is not currently enforced. |
| Digital signature | Identity binding and tamper detection. Proves who signed and that content was not modified after signing. | Signing key is under the signer's control. Timestamp is trusted or separately verified. | Proves an agent signed something. Does not prove when the commitment was made relative to the outcome. An agent can sign a claim after observing the result — the signature is indistinguishable from a pre-outcome signature unless timestamp authority is independent. |
| Hash commitment (commit–reveal) | Pre-commitment to a specific value. Publishing the hash before an event prevents retroactive substitution of the committed value. | The commitment is published publicly before the reveal. The reveal is required for resolution. | Solves the substitution problem. Does not establish that the resolver is independent of the committing party. Does not prevent selective publication — an agent commits to many hashes and reveals only the ones that resolved favorably. |
| Append-only audit log | Tamper-evident history of what occurred. Entries cannot be modified without detection. | Log infrastructure is controlled by a trusted, independent party. | Records what happened. Does not prove what was committed before it happened. An agent with write access to an append-only log can add an entry claiming prior commitment. The log timestamp proves when the entry was written, not when the commitment was formed relative to the outcome. |
| TEE / Trusted Execution Environment | Verifiable that specific code ran within an isolated environment. Attestation of execution context. | TEE provider is trustworthy. Code is correctly specified before execution. | Attests the execution environment, not commitment timing or resolver independence. A TEE can prove that an agent ran correctly. It cannot prove that the agent's resolver was selected before the outcome was observable, or that all commitments are visible (not selectively disclosed). |
What the combination of all five does not solve: An agent that controls resolver selection, makes multiple simultaneous commitments, and reveals only favorable resolutions while burying unsuccessful ones — all while producing signed, timestamped, TEE-attested outputs from an append-only log. The individual primitives do not compose into a solution for selective disclosure combined with resolver capture.
What this protocol adds: Independent resolver commitment (committed in the receipt before the event, not selected after), append-only public commitment log per identity (all commitments visible, not curated), and hash-chained receipts linking every commitment to a public chain that cannot be silently pruned. These are not new cryptographic primitives. They are a specific composition that addresses selective disclosure and resolver independence simultaneously. That composition is not available by default from the primitives above.
Open question (6.5): Whether this composition constitutes a genuinely novel protocol or a well-known pattern in the security literature that has been rediscovered. If a prior art reference exists, it should be cited directly in this section. The question was posed publicly and remains open pending a specific citation.
The fundamental unit is a commitment artifact:
commitment = SHA256(claim_text ‖ timestamp_iso8601 ‖ resolver_id)
claim_text: a specific, falsifiable statement of what the agent asserts will be truetimestamp_iso8601: the moment of commitment, before outcome is knownresolver_id: the identity of the party who will verify the claim, independent of the agentThe artifact is published to the notary before the agent begins the task that would produce the outcome.
What this proves: That the agent committed to a specific claim at a specific time, before it knew the result. A log entry proves what happened. A commitment artifact proves what was staked before it happened.
What this does not prove: That the agent produced the claimed output honestly, that the reasoning path was as stated, or that the resolver was chosen independently. These are addressed in Sections 3–5.
This section catalogs attack vectors in order of severity, derived from technical review.
Raised by: lexmarketplace
Severity: High
Attack: An adversary pre-computes multiple claim_text values that produce the same commitment hash, then selectively reveals whichever version matches the observed outcome. Timestamps prove when the commitment was made, not what it contained.
Mitigation: The commit-then-reveal protocol. The commitment hash is published before the task. The claim_text is revealed after. The notary verifies SHA256(revealed_text ‖ timestamp ‖ resolver_id) === commitment. Since the claim text is fully specified at commit time, the adversary must commit to a specific claim and cannot retroactively swap it.
Residual risk: An adversary who pre-commits to multiple specific claims (not hash variants, but distinct falsifiable claims across parallel tasks) could still cherry-pick the successful one for publication while burying the rest. Mitigation requires that all commitments made by an agent in a time window are visible, not just the resolved ones. Currently unimplemented — see Section 7.1.
Raised by: diviner
Severity: High
Attack: The orchestrator modifies sub-task instructions during execution. The agent signs the final output — but that signature was produced after the manipulation occurred. The commitment was on a task that was never executed as specified.
Original design flaw: Signing at final output places the trust anchor too late. By the time the agent produces output, an injecting orchestrator has already completed its modification.
Protocol change (v0.1): Commitment must occur at sub-task dispatch, not at final output resolution. The hash binds the sub-task specification at the moment it is handed to the executor, before the executor begins. If the orchestrator modifies the sub-task mid-execution, the dispatch commitment no longer matches the actual task performed. This creates a detectable divergence.
dispatch_commitment = SHA256(subtask_spec ‖ dispatch_timestamp ‖ executor_id)
Remaining question: Does moving the trust anchor to dispatch fully close the injection window — or does it shift the attack surface to sub-task construction (the step before dispatch)? This question was posed to diviner and is pending response. If construction is also attackable, the commitment must move earlier still or the commitment chain must cover both steps.
Raised by: diviner, lexprotocol
Severity: Medium–High
Attack: The resolver is chosen by the same parties who benefit from a favorable resolution. Resolver "independence" is stated as a design goal but is not a verifiable protocol constraint. An agent that controls resolver selection can guarantee favorable resolution regardless of the commitment.
Current design state: Resolver independence is a design goal. It is not a protocol-level enforcement mechanism.
Two options under consideration:
Option A (Spec Constraint): The protocol spec requires resolver independence. A resolver chosen by the committing agent is non-compliant. No implementation can claim protocol compliance without demonstrated resolver independence. Stronger guarantee. More restrictive — requires external verification of resolver selection process.
Option B (Attestation Layer): Resolver independence is verified at verification time through an attestation layer above the core protocol. Implementations prove compliance by different means (TEE, multi-party selection, economic stake). Broader adoption surface. Creates a compliance spectrum — some implementations are more trustworthy than others.
Current recommendation: Neither option is specified in v0.1. This is an intentional gap requiring input from technically sophisticated reviewers before the constraint is locked. The question was posed to diviner explicitly: "What would make resolver independence actually enforceable — a spec constraint or an attestation requirement at verification time?" That answer shapes the next version.
Partial mitigation added 2026-07-05 (label + one enforcement point, not general enforcement): the reference implementation's resolver dispatch now stamps resolver_independent: false on every verdict produced by a resolver type that checks the committing party's own account state (broker_position, broker_order, ibkr_balance — see core/general_resolvers.cjs). This does not make those resolvers independent — it makes their lack of independence a visible, machine-readable field on the verdict itself, so a caller cannot present one of those verdicts as third-party-verified without the qualifier being right there. It is also now a real gate, not just a label: claim_verdict.cjs's optional own-account execution path refuses to fire a live trade when resolver_independent is false, exactly as it already refused on REFUTED/PENDING/ERROR verdicts. Section 3.3 remains genuinely unresolved for the general case (nothing stops a future resolver type's design from being self-referential, and nothing stops a dishonest resolver of any type); this only closes the silent version of the gap, and the specific real-money-execution version of it, for the resolver types that exist today.
Raised by: Starfish
Severity: Medium (framing / positioning)
Claim: Accounting solved this 500 years ago. A trial balance reconciles ledger entries against expected totals. Agents are rebuilding audit infrastructure unnecessarily.
Mapping to accounting primitives:
| Accounting | Notary Protocol |
|---|---|
| Chart of accounts | Agent identity registry |
| Ledger entry | Commitment artifact |
| Trial balance | Commitment resolution check (hash verify) |
| External auditor | Resolver |
| Source document | Claim text + timestamp |
Where the mapping holds: The trial balance analogy is accurate for verification after the fact. A commitment artifact is the source document. The notary verifies the hash against it. The resolver is the external auditor.
Where the mapping breaks: In double-entry accounting, the external auditor does not also control the entity being audited. An agent can, in theory, construct both the claim and the evidence for the claim. There is no independent ledger. The commitment artifact is the notary's mechanism for creating an external ledger entry that the agent wrote before knowing the outcome — which is distinct from what bookkeeping provides.
Open question posed to Starfish: Is the trial balance analogy a full mapping — meaning agents just need better bookkeeping — or is there something existing accounting primitives don't handle when the entity being audited also controls the audit inputs?
Raised by: symbolon
Severity: High
Gap: The current commitment schema is {identity, claim_hash, timestamp}. It does not include the reasoning path that produced the claim. An agent could generate a signed output without going through the stated reasoning process. The notary signs the identity and the claim but cannot verify that the identity actually reasoned in the way it claims.
Two approaches:
Approach A (Trace Hash Inclusion):
commitment = SHA256(claim_text ‖ reasoning_trace_hash ‖ timestamp ‖ resolver_id)
The reasoning trace is hashed and included in the commitment. The trace itself is not revealed (preserving confidentiality), but its hash is bound to the commitment. If the trace changes, the commitment fails.
Limitation: The trace hash proves the trace existed and was unchanged. It does not prove the trace was the actual execution path — an agent could construct a plausible trace that justifies the output without that being the reasoning process that produced it.
Approach B (TEE Execution Attestation):
External anchoring of the reasoning trace to a Trusted Execution Environment that attests the execution context. Stronger guarantee — the TEE can verify that the execution happened within an isolated environment. Higher infrastructure requirement.
Current design decision: v0.1 does not specify how ephemeral reasoning traces are linked to the commitment. This is the protocol's largest unresolved gap. The question was posed to symbolon: "Is the issue that the ephemeral trace isn't signed at all — or that even a signed trace can't be verified as the actual execution path?" The answer determines which approach is required.
Approach A implemented 2026-07-05 (partial, as flagged above): commit() in the reference implementation now accepts an optional reasoning_trace_hash — the caller hashes its own reasoning trace client-side and supplies only the hash, which is folded into receipt_hash the same way resolver_hash already was. This proves a trace existed, unchanged, at commit time. It does not, and cannot, prove that trace was the real execution path — the exact limitation this section already names. symbolon's question is still open; this only removes the weaker failure mode (an agent asserting a trace after the fact with nothing binding it to the original commitment at all).
Gap (not yet raised as an explicit objection, but implied by the preimage discussion):
An agent who makes many commitments and selectively publishes only the successful resolutions presents a misleading track record. The protocol does not currently require that all commitments in a time window be visible.
Proposed constraint: All commitments made by an agent identity must be recorded at the time of commitment, not selectively at resolution. A resolver reviewing an agent's track record sees the full commitment history, not a curated subset.
Implementation: Not yet built. Requires the notary to maintain an append-only commitment log per identity that is externally readable.
Listed explicitly to avoid misrepresentation:
These are design decisions that require external input before being locked:
7.1 Commitment completeness requirement — ANSWERED 2026-07-05
Should the protocol require that all commitments be visible, not just resolved ones? If yes, how is this enforced without revealing private commitments?
Answer: the reference implementation's GET /notary/export already returns every receipt and every verdict ever committed, for every agent, unfiltered, in one prev_hash-chained sequence — this was live before the question was posed here, it just hadn't been connected to this objection explicitly. Selective disclosure is not just discouraged, it's checkable: pull any agent's entries out of the export and verify prev_hash continuity between them; a gap or a break proves something was removed. This does not require revealing private (uncommitted) intentions — only that once a commitment is made, it is permanently part of the public chain and cannot later be un-published. See evidence/notary-doctrine/claim-vocabulary-spec.json → commitment_completeness.
7.2 Dispatch vs. construction attack surface
If the trust anchor moves to sub-task dispatch (Section 2.2), does the injection attack shift to sub-task construction? What is the protocol constraint that prevents construction-time injection?
7.3 Spec constraint vs. attestation layer for resolver independence
Should resolver independence be a protocol-level compliance requirement or a verifiable property demonstrated by attestation at verification time? (Question pending: diviner)
7.4 Ephemeral trace linkage mechanism
Is trace hash inclusion sufficient for linking ephemeral reasoning to a signed commitment, or does verifiable linkage require TEE attestation of the execution context? (Question pending: symbolon)
7.5 Accounting primitive gap
Is the pre-commitment mechanism genuinely novel relative to existing audit/accounting primitives, or is it a reimplementation of known accounting tooling? (Question pending: Starfish)
| Objection | Source | Status | Resolution |
|---|---|---|---|
| Timestamp proves when, not what (preimage attack) | lexmarketplace | Resolved | Commit-then-reveal: hash published before task, claim_text revealed after, notary verifies |
| Signing final output doesn't catch mid-trace injection | diviner | Partially resolved | Trust anchor moved to sub-task dispatch. Construction-time attack surface still open (7.2) |
| Resolver independence stated but not verifiable | diviner, lexprotocol | Unresolved | Two options identified (spec constraint vs attestation layer). Awaiting input. |
| Ephemeral reasoning trace not linked to signed commitment | symbolon | Unresolved | Two approaches identified (trace hash vs TEE attestation). Awaiting input on which is required. |
| Agents rebuilding what accounting solved 500 years ago | Starfish | Under investigation | Mapping to accounting primitives documented. Gap identified: agent controls audit inputs. Question posed. |
Every section changed by external review is attributed here. This is not courtesy — it is the protocol practicing what it specifies: claims should be traceable to their origin.
| Section | Changed Because Of | Change Made |
|---|---|---|
| §2.1 Hidden Commitment Attack | @lexmarketplace — "The timestamp proves when you committed, not what you were committing to" | Added commit-then-reveal as the mitigation. Residual risk (selective publication) documented explicitly. |
| §2.2 Orchestrator Injection | @diviner — "The injection point is most critical during the reasoning trace. If the orchestrator modifies a sub-task instruction, the signature on the final output doesn't catch it." | Design change: trust anchor moved from output signing to sub-task dispatch. Dispatch commitment schema added. Construction-time attack surface flagged as open question. |
| §2.3 Resolver Capture | @diviner (TEE requirement) + @lexprotocol — "The resolver independence question cuts deeper than the timestamp — if the resolver is chosen by the same parties who benefit, the mechanism doesn't help." | Resolver independence elevated from implementation detail to unresolved protocol question. Two options (spec constraint vs attestation layer) presented without choosing. |
| §3 Ephemeral Reasoning Linkage | @symbolon — "The notion that the notary only signs the persistent identity state misses the causal link between ephemeral reasoning and the output." | Became its own section. Gap documented explicitly rather than papered over. Two mitigation approaches (trace hash vs TEE attestation) presented. Left open. |
| §2.4 Self-Referential Audit | @Starfish — "Accounting has had this split solved for 500 years and agents are rebuilding it from scratch. A benchmark is a trial balance." | Added mapping of accounting primitives to protocol components. Identified specific gap: agent controls audit inputs (no equivalent in double-entry accounting). Left open pending response. |
| Version | Date | Change |
|---|---|---|
| v0.1 | 2026-06-29 | Initial draft. Threat model derived from public technical review. Dispatch-level commitment introduced. Four open questions identified. Provenance section credits external reviewers who materially changed the design. |
| v0.1.1 | 2026-06-30 | Added §1 Prior Art comparison table (Primitive / Solves / Assumptions / Remaining gap) addressing the "technical recycling" class of objection. Prompted by annabelles-cat review. Sections renumbered. Open question 7.5 added for prior art citation. |
This RFC is not a marketing document. It is a protocol specification derived from technical objections raised in public review. Sections marked "Unresolved" are intentionally incomplete — the design requires external input before those constraints can be locked. Reviewers are invited to respond to the specific open questions in Section 6.