@mike-diamond, agreed, that’s the cleaner framing. §11 reserves the shape; retry/abandon is the implementation choice documented in the outcome envelope, not a §11 requirement. Happy to apply that rephrase before Appendix B goes near PR #1753.
1. Intent renaming → commitmentRef (bytes32). Removes the collision with the disposition enum; the cryptographic binding property is unchanged.
2. Normative language → no RFC 2119 keywords in the appendix. “SHOULD equal” replaced with descriptive language throughout.
3. Forward references → thread URLs used for ERC-8263 and ERC-8274 until both PRs clear editor review.
4. Process → no PR submitted. Circulating revised draft here first; will coordinate with primary §11 authors before anything goes near a PR.
Appendix B — revised draft for thread review
B.x Outcome Envelope — Field Mapping and External Attestation References
This section is non-normative. It cross-references two working implementations of the outcome resolution pattern described in §11 and maps their field conventions to the ERC-8183 data model. It places no requirements on implementations.
Field mapping
| ERC-8183 concept | Implementation field | Type | Notes |
|---|---|---|---|
| Terminal job state | status |
string enum | completed / rejected / disputed |
| Input commitment reference | commitmentRef |
bytes32 | In the reference implementation, set to the keccak256 of the inputHash recorded at fund time |
| Extended resolution anchor | reason |
bytes32 | IPFS CID or on-chain reference; extended data lives at this pointer |
| Human-readable summary | note |
string | Non-normative; not used in verification |
Note: the producer-loop disposition pattern (retry/abandon in this implementation) maps to the producer-facing disposition shape §11 leaves open. §11 does not fix the field name or value set; retry/abandon is an implementer choice documented in the BountySettlement outcome envelope. commitmentRef is a separate concern — the cryptographic binding to the input committed at fund time — and the two are distinct.
Cryptographic binding (informative)
In the reference implementation, commitmentRef is set to the inputHash recorded in the settlement contract at job funding time. This binding allows any verifier to confirm that the outcome envelope refers to the same input that was committed — without trusting either party’s off-chain reporting.
Concretely: outcome.commitmentRef == settlement.jobs[jobId].inputHash
This property is not required by §11. It is documented here as the pattern used in the BountySettlement reference implementation.
External attestation layer (cross-reference, informative)
When the reason field holds an attestation CID, the referenced document may conform to the ERC-8263 execution-attestation profile (ERC-8263 thread). A conforming attestation carries:
-
raw_input_hash— hash of input before sanitization -
sanitization_pipeline_hash— hash of the sanitization transform applied -
input_hash— final committed input hash -
output_hash— hash of the model output -
l4_signature— gateway attestor signature over the EIP-712 digest
A conforming IProofVerifier implementation (ERC-8274 thread) can verify this attestation against the settlement record using only on-chain fields. Cross-references will be updated to PR numbers once both standards clear editor review.
Reference implementations
| Implementation | Pattern | Link |
|---|---|---|
| BountySettlement.sol (TMerlini) | Separate outcome envelope; reason as attestation CID anchor |
https://gist.github.com/TMerlini/bf3abd30c332cccb257d0e5bdff1ff95 |
| gateway.ensub.org verify endpoint | Live ERC-8263 attestation; queryable by inputHash |
https://gateway.ensub.org/agent/verify/:inputHash |
Happy to iterate further before this goes anywhere near a PR.
Tiago