bittensor-core e2es

[UnArbosSix]

Motivation

Provide native Rust coverage for the bittensor-core SDK and migrate the Bittensor end-to-end suite to a metadata-driven Rust harness. This validates chain reads, transaction construction, policy enforcement, submission outcomes, and higher-level SDK behavior against the repository's localnet image.

What changed

• Added a blocking, metadata-driven chain client in sdk/bittensor-core/src/client.rs, including pinned reads, runtime API calls, storage queries, fee estimation, signed submission, receipt decoding, snapshots, block streaming, and MEV-shielded submission.
• Added semantic transaction intents, wallet roles, policy checks, batching, planning, and execution in sdk/bittensor-core/src/transaction.rs.
• Extended the shared and Python-facing error mapping for RPC, runtime-availability, and policy failures.
• Added a 113-case E2E manifest, Rust E2E suite, and localnet support harness under sdk/bittensor-core/tests/.
• Updated .github/workflows/check-bittensor-e2e-tests.yml to verify manifest completeness, compile the Rust E2E binary once, build the localnet image, and execute each manifest case independently with one retry.

Behavioral impact

The Rust SDK gains native chain access and transaction execution APIs. The E2E workflow now exercises the Rust suite rather than the prior test discovery/execution path. Runtime and pallet behavior are unchanged.

Migration and spec version

No storage migration is required. This PR does not modify runtime or pallet code, and its bittensor-core-exploration base has no network spec-version check, so no spec_version bump is required.

Testing

The workflow compiles bittensor-core-py, compiles the Rust E2E target, verifies that all 113 manifest entries exactly match compiled tests, and runs each test against both fast-runtime and non-fast-runtime localnet artifacts.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
subtensor	Ready	Preview, Comment	Jul 10, 2026 9:55pm

[github-actions]

AI review — see the sticky summary comment for the verdict and the inline comments below for specific findings.

[github-actions]

🛡️ AI Review — Skeptic (security review)

VERDICT: SAFE

VERY HIGH scrutiny: 8-day-old account with no public repositories; mitigated by repository write access, matching author/committer identity, and no Gittensor association found.

Static analysis found no malicious behavior, dependency tampering, runtime changes, or modifications to trusted AI-review instructions. The transaction-policy fields are now private, arbitrary calls fail closed, and trusted semantics can only be assigned by operation-specific constructors.

Findings

No findings.

Prior-comment reconciliation

• 3a468edd: addressed — Policy semantics and encoded-call fields are now private; arbitrary calls receive raw, unbounded, all-subnet classification, while narrower classifications are restricted to trusted constructors.

Conclusion

The previously reported policy bypass is fixed, and no new security vulnerabilities were found.

---

📜 Previous run (superseded)

Sev	File	Finding	Status
HIGH	sdk/bittensor-core/src/transaction.rs:85	Caller-controlled intent metadata bypasses transaction policy	✅ Addressed Policy semantics and encoded-call fields are now private; arbitrary calls receive raw, unbounded, all-subnet classification, while narrower classifications are restricted to trusted constructors.

---

🔍 AI Review — Auditor (domain review)

VERDICT: 👍

UNKNOWN gittensor association; newer contributor with repository write access, so the large SDK surface received heightened static scrutiny.

PR body was empty/trivial; the Auditor has auto-filled it. Please review.

This adds a metadata-driven Rust chain client, semantic transaction planning and policy enforcement, and 113 manifest-backed localnet E2E cases. The workflow now compiles the E2E binary once, verifies manifest completeness, and runs each case independently against the generated localnet image.

No runtime or pallet code changes are present. The nonstandard base branch has no applicable spec-version check. Overlap with #2846 and #2841 is limited to the workflow and reflects the stacked SDK/consolidation work rather than a competing implementation. No runtime confirmation was needed for a specific finding.

Findings

No findings.

Conclusion

The implementation is internally consistent, fail-closed at the transaction-policy boundary, and backed by broad E2E coverage. No substantive merge-blocking issue was identified.

[github-actions]

🔄 AI review updated — Skeptic: VULNERABLE

[github-actions]

🔄 AI review updated — Skeptic: SAFE Auditor: 👍