[PR #4479] docs(skill): corroborate EVM carriers with on-chain inclusion evidence #6265

New issue

Open

opened 2026-10-31 01:13:08 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-31 01:13:08 +00:00

Owner

📋 Pull Request Information

Original PR: https://github.com/morluto/rea/pull/4479
Author: @yawningmonsoon
Created: 10/16/2026
Status: 🔄 Open

Base: main ← Head: evm-onchain-corroboration

📝 Commits (1)

395771a docs(skill): corroborate EVM carriers with on-chain inclusion evidence

📊 Changes

1 file changed (+28 additions, -0 deletions)

View changed files

📝 .agents/skills/reverse-engineer-anything/references/evidence-workflows.md (+28 -0)

📄 Description

Summary

inspect_evm_interface analyses a local carrier and makes no chain lookup, so a user who fetched bytes from a deployed contract has no guidance on how to connect the Evidence to where the bytes came from. This adds a short, optional section to references/evidence-workflows.md on corroborating an EVM carrier with on-chain inclusion evidence, keeping REA's Evidence and the external result separate.

Problem and expected behavior

When a question depends on a deployed contract (which transaction created it, whether it is final), the agent should record the carrier's origin, check the creating or calling transaction's inclusion with a source it trusts, and report a bundle that links (not merges) the REA Evidence id and the inclusion result, with the limits stated.

Change and scope

Documentation only: one new section in an existing reference file. No code, tool, provider or catalog change; REA still makes no network call. The section names a node's own receipt first and one public proof service (Taifoon's free GET /v1/proof/tx/{chain}/{tx}) as an option; disclosure: I work on Taifoon. Happy to drop the named example and keep the procedure generic if you prefer — that's the scope decision I'm asking for, so this is a draft.

Contract and boundary impact

Semantic owner and earliest changed stage: skill reference text only.
Contribution scope fit and linked maintainer decision: reverse-engineering workflow docs; maintainer decision pending on naming an external service.
CLI and MCP/tool-catalog contract: none.
Provider, bridge, target-format, or platform compatibility: none.
Evidence, artifact, provenance, or reconstruction contract: none (the section tells agents to keep external results separate from Evidence).
Target selection, authority, upstream behavior, and cleanup details: not applicable.

Verification

oxfmt --check on the file: clean.
Walked the procedure on a live contract: fetched runtime bytes of a Base contract, ran rea inspect-evm-interface <file> hex (rea-agents 6.5.0, Linux x64): 22 selector candidates, Evidence ev_c325d76de9e4db9800967dd89f3bbb87c1af72365316b71fc22ed4fbe769b36e; the creating transaction's inclusion read answered proof_state: proven, is_finalized: true, all checks true.
vitest on tests/boundary/filesystem/setupSkill.test.ts, tests/acceptance/setup/selectedSkillSetup.test.ts, tests/conformance/readmeConsistency.test.ts after npm run build: 26 passed, 1 failed; the same test (binds portable conformance to the generated skill bytes that setup installs) fails identically on unchanged main in my environment.
Not run: the full check:pr suite.

🤖 Generated with Claude Code

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/morluto/rea/pull/4479 **Author:** [@yawningmonsoon](https://github.com/yawningmonsoon) **Created:** 10/16/2026 **Status:** 🔄 Open **Base:** `main` ← **Head:** `evm-onchain-corroboration` --- ### 📝 Commits (1) - [`395771a`](https://github.com/morluto/rea/commit/395771af33ee9e6cdb394c301df520900786f29f) docs(skill): corroborate EVM carriers with on-chain inclusion evidence ### 📊 Changes **1 file changed** (+28 additions, -0 deletions) <details> <summary>View changed files</summary> 📝 `.agents/skills/reverse-engineer-anything/references/evidence-workflows.md` (+28 -0) </details> ### 📄 Description ## Summary `inspect_evm_interface` analyses a local carrier and makes no chain lookup, so a user who fetched bytes from a deployed contract has no guidance on how to connect the Evidence to where the bytes came from. This adds a short, optional section to `references/evidence-workflows.md` on corroborating an EVM carrier with on-chain inclusion evidence, keeping REA's Evidence and the external result separate. ## Problem and expected behavior When a question depends on a deployed contract (which transaction created it, whether it is final), the agent should record the carrier's origin, check the creating or calling transaction's inclusion with a source it trusts, and report a bundle that links (not merges) the REA Evidence id and the inclusion result, with the limits stated. ## Change and scope Documentation only: one new section in an existing reference file. No code, tool, provider or catalog change; REA still makes no network call. The section names a node's own receipt first and one public proof service (Taifoon's free `GET /v1/proof/tx/{chain}/{tx}`) as an option; disclosure: I work on Taifoon. Happy to drop the named example and keep the procedure generic if you prefer — that's the scope decision I'm asking for, so this is a draft. ## Contract and boundary impact - Semantic owner and earliest changed stage: skill reference text only. - Contribution scope fit and linked maintainer decision: reverse-engineering workflow docs; maintainer decision pending on naming an external service. - CLI and MCP/tool-catalog contract: none. - Provider, bridge, target-format, or platform compatibility: none. - Evidence, artifact, provenance, or reconstruction contract: none (the section tells agents to keep external results separate from Evidence). - Target selection, authority, upstream behavior, and cleanup details: not applicable. ## Verification - `oxfmt --check` on the file: clean. - Walked the procedure on a live contract: fetched runtime bytes of a Base contract, ran `rea inspect-evm-interface <file> hex` (rea-agents 6.5.0, Linux x64): 22 selector candidates, Evidence `ev_c325d76de9e4db9800967dd89f3bbb87c1af72365316b71fc22ed4fbe769b36e`; the creating transaction's inclusion read answered `proof_state: proven`, `is_finalized: true`, all `checks` true. - `vitest` on `tests/boundary/filesystem/setupSkill.test.ts`, `tests/acceptance/setup/selectedSkillSetup.test.ts`, `tests/conformance/readmeConsistency.test.ts` after `npm run build`: 26 passed, 1 failed; the same test (`binds portable conformance to the generated skill bytes that setup installs`) fails identically on unchanged `main` in my environment. - Not run: the full `check:pr` suite. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

bsakaguchi added the

pull-request

label

2026-10-31 01:13:08 +00:00

bsakaguchi referenced this issue

2026-11-01 21:46:24 +00:00

[PR #6265] [CLOSED] fix(evm): classify oversized input artifacts by file-size boundary #7239