backlog+memory: blockchain ingest BTC/ETH/SOL first-class DB support#394
Merged
backlog+memory: blockchain ingest BTC/ETH/SOL first-class DB support#394
Conversation
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
There was a problem hiding this comment.
Pull request overview
Captures a maintainer directive (2026-04-24) to treat blockchain block ingestion (BTC → ETH → SOL) as a first-class Zeta distributed-DB workload, with a phased plan starting from research and post-install ingest scripts and potentially graduating to full protocol participation if required for network reciprocity.
Changes:
- Adds a new feedback memory file preserving the directive verbatim plus a structured phased scope (0–4).
- Indexes the new memory in
memory/MEMORY.md(newest-first). - Adds a P2 research-grade umbrella row to
docs/BACKLOG.mddescribing the phased plan and constraints.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| memory/feedback_blockchain_ingest_btc_eth_sol_first_class_db_support_aurora_prep_2026_04_24.md | New memory capturing the directive verbatim and expanding it into a phased roadmap and architectural constraints. |
| memory/MEMORY.md | Adds a top-of-index pointer entry for the new memory file. |
| docs/BACKLOG.md | Adds a P2 umbrella backlog item defining the research gate and phased execution plan. |
AceHack
added a commit
that referenced
this pull request
Apr 24, 2026
…aps itself) Maintainer 2026-04-24 directive — Ouroboros bootstrapping is the META-thesis tying together every 2026-04-24 same-day directive: the system uses its own substrate to bootstrap itself. Native F# git stores its own commits as Z-sets; permissions registry tracks the authority for its own creation; memory-sync uses memory-sync; Mode 2 hosts the factory dashboard for Mode 2. Three load-bearing properties of Ouroboros closures: (1) Provenance is closed under the substrate. (2) Every integration is testable from the inside. (3) Self-consistency is a detectable invariant. Cardano consensus protocol naming-overlap is intentional, not accidental — same self-referential property at the consensus layer vs the bootstrap layer. When blockchain-ingest activates and Cardano comes into scope (Phase 3+), the Ouroboros-protocol research will reinforce the Ouroboros-bootstrap thesis. Connection-map work owed at `docs/research/ouroboros-bootstrap-connection-map-2026.md` before any 2026-04-24 directive implementation begins. Maintainer standard: "exact integrations and connections to make sure we can do it right" — hand-waved "Mode 2 talks to Mode 1 somehow" is insufficient. This BACKLOG row + companion memory file are the meta-frame for the entire 2026-04-24 cluster: rename (#393), blockchain ingest (#394), Mode 1 admin UI + native F# git + protocol upgrade + permissions registry + UI split (this PR / #395).
Maintainer 2026-04-24 directive captured verbatim. Two motivations:
Aurora preparation (understand real blocks before building) + DB
stress-test (real-world streaming workload at battle-tested scale).
BTC → ETH → SOL priority order. Additional chains (Cosmos, Polkadot,
Cardano, Avalanche, L2 rollups) evaluated later.
Architectural frame (maintainer-explicit): NOT a fork of bitcoind /
geth / solana-labs. Full node layered ON TOP of Zeta's distributed
DB — distributed-node support falls out of Zeta's multi-node
primitives for free.
Phased scope captured in the row:
Phase 0 — research gate (read actual client source per chain to
map freeloader detection: BTC net_processing.cpp DoS
scoring; ETH devp2p/Snap sync reciprocity; SOL turbine
shred forwarding)
Phase 1 — post-install ingest script + Z-set retraction-native
chain-reorg handling + queryable through all existing
interfaces
Phase 2 — full-node protocol participation (CONDITIONAL on Phase 0
finding; upload-side interfaces first-class on par with
SQL per maintainer)
Phase 3 — cross-chain stream bridge (Z-set operator composition)
Phase 4 — UI block-explorer + streaming dashboard
Otto-275 log-don't-implement. Does NOT authorize implementation start;
Phase 0 research is the gate. Does NOT authorize mainnet exposure
without Aminata threat-model sign-off.
AceHack
force-pushed
the
backlog/blockchain-ingest-btc-eth-sol
branch
from
159c275 to
49f5acb
Compare
AceHack
added a commit
that referenced
this pull request
Apr 24, 2026
…aps itself) Maintainer 2026-04-24 directive — Ouroboros bootstrapping is the META-thesis tying together every 2026-04-24 same-day directive: the system uses its own substrate to bootstrap itself. Native F# git stores its own commits as Z-sets; permissions registry tracks the authority for its own creation; memory-sync uses memory-sync; Mode 2 hosts the factory dashboard for Mode 2. Three load-bearing properties of Ouroboros closures: (1) Provenance is closed under the substrate. (2) Every integration is testable from the inside. (3) Self-consistency is a detectable invariant. Cardano consensus protocol naming-overlap is intentional, not accidental — same self-referential property at the consensus layer vs the bootstrap layer. When blockchain-ingest activates and Cardano comes into scope (Phase 3+), the Ouroboros-protocol research will reinforce the Ouroboros-bootstrap thesis. Connection-map work owed at `docs/research/ouroboros-bootstrap-connection-map-2026.md` before any 2026-04-24 directive implementation begins. Maintainer standard: "exact integrations and connections to make sure we can do it right" — hand-waved "Mode 2 talks to Mode 1 somehow" is insufficient. This BACKLOG row + companion memory file are the meta-frame for the entire 2026-04-24 cluster: rename (#393), blockchain ingest (#394), Mode 1 admin UI + native F# git + protocol upgrade + permissions registry + UI split (this PR / #395).
3 tasks
AceHack
added a commit
that referenced
this pull request
Apr 24, 2026
… index)
Maintainer 2026-04-24 directive — closure-table substrate
needs hardening to support filesystem-class workloads
(deep + wide trees, 100k+ files) for the native F# git
implementation. Make the index pluggable so a faster
substrate can swap in if profiling shows it's the
bottleneck. Maintainer hasn't looked at space/time
tradeoffs; backlog research.
Phase 0 research scope captured in the row:
- State-of-the-art survey: nested-set, materialized-path,
closure-table, Postgres ltree, B-tree-prefix-index,
radix-trie, Verkle/Merkle Patricia.
- Substrates worth interface-compatibility: B-trees
(ZFS/btrfs scale), Patricia/HAMT/CRDT-tree, Dolt /
TerminusDB existing precedents.
- Define IHierarchicalIndex contract.
- Empirical baseline benchmark on representative repo.
Composes with native F# git impl (#395 cluster as primary
consumer), Mode 2 protocol upgrade, Ouroboros bootstrap
meta-thesis (index correctness IS part of the closure
proof), blockchain-ingest (#394 — block hierarchy may
share the same abstraction).
Otto-275 log-don't-implement: row captures research scope,
does NOT authorize implementation start.
3 tasks
AceHack
added a commit
that referenced
this pull request
Apr 25, 2026
…aps itself) Maintainer 2026-04-24 directive — Ouroboros bootstrapping is the META-thesis tying together every 2026-04-24 same-day directive: the system uses its own substrate to bootstrap itself. Native F# git stores its own commits as Z-sets; permissions registry tracks the authority for its own creation; memory-sync uses memory-sync; Mode 2 hosts the factory dashboard for Mode 2. Three load-bearing properties of Ouroboros closures: (1) Provenance is closed under the substrate. (2) Every integration is testable from the inside. (3) Self-consistency is a detectable invariant. Cardano consensus protocol naming-overlap is intentional, not accidental — same self-referential property at the consensus layer vs the bootstrap layer. When blockchain-ingest activates and Cardano comes into scope (Phase 3+), the Ouroboros-protocol research will reinforce the Ouroboros-bootstrap thesis. Connection-map work owed at `docs/research/ouroboros-bootstrap-connection-map-2026.md` before any 2026-04-24 directive implementation begins. Maintainer standard: "exact integrations and connections to make sure we can do it right" — hand-waved "Mode 2 talks to Mode 1 somehow" is insufficient. This BACKLOG row + companion memory file are the meta-frame for the entire 2026-04-24 cluster: rename (#393), blockchain ingest (#394), Mode 1 admin UI + native F# git + protocol upgrade + permissions registry + UI split (this PR / #395).
AceHack
added a commit
that referenced
this pull request
Apr 25, 2026
… require 0) (#395) * backlog+memory: git-as-DB-interface + WASM-F#/git-storage; both modes require 0 Maintainer 2026-04-24 directive — two stretch goals filed as P3/way-back-backlog: (1) Git-as-first-class-DB-interface — Zeta commands ≈ git commands where semantics align (commit/branch/merge/log/ diff/tag/stash/cherry-pick map onto Z-set retraction- native semantics). (2) WASM-F# + git-as-storage-plugin — browser-only bootstrap mode. WASM-F# (Blazor + Fable) + isomorphic-git + Z-set semantics fitting git's branch-and-merge model. Bootstrap thesis confirmed: "so both require 0" — both modes are install-free at user-experience level. Maintainer corrected my draft recharacterization that Mode 1 needed .NET runtime; Mode 1 is tiny-seed AoT or single-file JIT (NOT framework-dependent). Mode 1 = download one binary; Mode 2 = open one tab. Honest assessment captured: Mode 2 is NOT a dream — pieces exist (Blazor WASM, Fable, isomorphic-git). Wild bit is performance: git ops are NOT fast enough for hot-path reads, so Mode 2 architecture is "browser viewer + git-backed durable substrate; hot-path lives in browser memory" — not "every read hits git". Write-amplification limits Mode 2 to low-volume workloads (notebooks, memory sync, config); Mode 1 stays load-bearing for streaming. Composes with Otto-243 (git-native memory-sync precursor), Otto-274 (progressive-adoption-staircase — both modes are Level-0 candidates), Otto-275 (log-don't-implement), and the companion 2026-04-24 blockchain-ingest absorb. Does NOT authorize starting POC code without Phase-0 feasibility doc landing first. * backlog+memory: + Mode 1 admin UI + native F# git impl (Zeta IS git client/server) Maintainer 2026-04-24 follow-up (after the bootstrap-thesis punchline) added two more pieces to the same conceptual cluster: (1) Mode 1 admin UI — SSMS/pgAdmin-class local management UI for Zeta. Distinct from the web-facing Frontier-UI (kernel-A/kernel-B). Two-UI architecture: web-facing (Frontier) + local-admin (this row). Ships with Mode 1 single-file binary. (2) Native F# git implementation — Zeta IS the git client AND server. No external git binary required. Git objects (commit/tree/blob) serialize as Z-set entries with retraction-native semantics. Per maintainer: "just another interface like SQL". Symmetric architecture gain: any Zeta Mode 1 instance can serve as a git remote for any Zeta Mode 2 browser client. The factory becomes self-hosting of its own git ecosystem — `git push my-zeta main` lands in Zeta's DB via Zeta's own git server. Two new BACKLOG rows added at top of P2 — research-grade. Memory file updated with verbatim follow-up. Composes with existing Mode-1/Mode-2 bootstrap thesis + Otto-243 git-native memory-sync precursor + the same-day blockchain ingest absorb (Mode 1 streaming). * backlog+memory: + protocol-upgrade negotiation + authority grant + permissions registry Three additions to the same #395 conceptual cluster (all maintainer 2026-04-24, captured per Otto-275 log-don't-implement): (1) Mode 2 → Mode 1 protocol-upgrade negotiation — Mode 2 opens with git as bootstrap LCD; both sides negotiate upgrade to a faster Zeta-specific binary protocol for hot-path traffic. ALPN/HTTP-Upgrade-style pattern. Git stays as fallback / audit-trail / durable-substrate. (2) Authority grant — `github-admin` granted to loop-agent role by maintainer, durable across sessions. Scope: branch-protection PATCH, repo settings, ruleset CRUD, workflow dispatch. NOT in scope: org-admin, repo deletion, force-push-main, bypass-protection-per-PR. Used 2026-04-24 to unblock #375 by migrating required-checks contexts. (3) Named-permissions registry — per-contributor scoped permission grants for factory agents. `docs/AUTHORITY-REGISTRY.md` (factory-authored current-state doc). 7 named permissions drafted (github-admin granted; org-admin / secrets / force-push-main / nuget-publish / slsa-signing-key / network-egress-broad NOT granted). Iterative hardening Phase 0-5 captured. All three compose with the bootstrap thesis + git-native architecture in this PR. Aaron's frame: "this is not super safe yet but we can make it more safe over time" — capture-and-cite-the-grant discipline beats silent expansion. * backlog: + Mode 2 UI architecture split (research-required + maintainer review) Maintainer 2026-04-24 question: is Mode 2 the SSMS/pgAdmin admin UI AND the factory operations dashboard? Or two UIs? Three candidate UI surfaces identified across this session's directives: Frontier-UI (kernel-A/kernel-B web-facing public surface) + SSMS/pgAdmin admin UI (database operator) + factory operations dashboard (factory maintainer). Loop-agent preliminary recommendation captured for maintainer review: Reading B (two surfaces, shared component library) over Reading A (one app with tabs). Audiences differ enough that forcing one chrome harms both; shared library captures composability without audience-blur. Three-app architecture: App A — Frontier-UI (public web) App B — Admin UI (Mode-1-bundled, operator audience) App C — Factory ops dashboard (maintainer audience) Shared library — WASM-F# primitives (auth/theme/query/etc). Phase 0 research doc owed at `docs/research/mode-2-ui-architecture-split-2026.md` before any UI implementation. Maintainer review required before kickoff. Composes with the existing #395 cluster (Mode 1 admin UI, native git impl, protocol-upgrade negotiation, named-permissions registry). * backlog+memory: + Ouroboros bootstrap meta-thesis (the system bootstraps itself) Maintainer 2026-04-24 directive — Ouroboros bootstrapping is the META-thesis tying together every 2026-04-24 same-day directive: the system uses its own substrate to bootstrap itself. Native F# git stores its own commits as Z-sets; permissions registry tracks the authority for its own creation; memory-sync uses memory-sync; Mode 2 hosts the factory dashboard for Mode 2. Three load-bearing properties of Ouroboros closures: (1) Provenance is closed under the substrate. (2) Every integration is testable from the inside. (3) Self-consistency is a detectable invariant. Cardano consensus protocol naming-overlap is intentional, not accidental — same self-referential property at the consensus layer vs the bootstrap layer. When blockchain-ingest activates and Cardano comes into scope (Phase 3+), the Ouroboros-protocol research will reinforce the Ouroboros-bootstrap thesis. Connection-map work owed at `docs/research/ouroboros-bootstrap-connection-map-2026.md` before any 2026-04-24 directive implementation begins. Maintainer standard: "exact integrations and connections to make sure we can do it right" — hand-waved "Mode 2 talks to Mode 1 somehow" is insufficient. This BACKLOG row + companion memory file are the meta-frame for the entire 2026-04-24 cluster: rename (#393), blockchain ingest (#394), Mode 1 admin UI + native F# git + protocol upgrade + permissions registry + UI split (this PR / #395). * drain #395: 8 review-thread fixes (Fable/Blazor split, P2/P3 alignment, MEMORY.md terseness, GOVERNANCE §31 citation, typo, naming) * drain #395: pr-preservation drain log (8 threads, all FIX)
AceHack
added a commit
that referenced
this pull request
Apr 25, 2026
… index)
Maintainer 2026-04-24 directive — closure-table substrate
needs hardening to support filesystem-class workloads
(deep + wide trees, 100k+ files) for the native F# git
implementation. Make the index pluggable so a faster
substrate can swap in if profiling shows it's the
bottleneck. Maintainer hasn't looked at space/time
tradeoffs; backlog research.
Phase 0 research scope captured in the row:
- State-of-the-art survey: nested-set, materialized-path,
closure-table, Postgres ltree, B-tree-prefix-index,
radix-trie, Verkle/Merkle Patricia.
- Substrates worth interface-compatibility: B-trees
(ZFS/btrfs scale), Patricia/HAMT/CRDT-tree, Dolt /
TerminusDB existing precedents.
- Define IHierarchicalIndex contract.
- Empirical baseline benchmark on representative repo.
Composes with native F# git impl (#395 cluster as primary
consumer), Mode 2 protocol upgrade, Ouroboros bootstrap
meta-thesis (index correctness IS part of the closure
proof), blockchain-ingest (#394 — block hierarchy may
share the same abstraction).
Otto-275 log-don't-implement: row captures research scope,
does NOT authorize implementation start.
AceHack
added a commit
that referenced
this pull request
Apr 25, 2026
… index) (#396) Maintainer 2026-04-24 directive — closure-table substrate needs hardening to support filesystem-class workloads (deep + wide trees, 100k+ files) for the native F# git implementation. Make the index pluggable so a faster substrate can swap in if profiling shows it's the bottleneck. Maintainer hasn't looked at space/time tradeoffs; backlog research. Phase 0 research scope captured in the row: - State-of-the-art survey: nested-set, materialized-path, closure-table, Postgres ltree, B-tree-prefix-index, radix-trie, Verkle/Merkle Patricia. - Substrates worth interface-compatibility: B-trees (ZFS/btrfs scale), Patricia/HAMT/CRDT-tree, Dolt / TerminusDB existing precedents. - Define IHierarchicalIndex contract. - Empirical baseline benchmark on representative repo. Composes with native F# git impl (#395 cluster as primary consumer), Mode 2 protocol upgrade, Ouroboros bootstrap meta-thesis (index correctness IS part of the closure proof), blockchain-ingest (#394 — block hierarchy may share the same abstraction). Otto-275 log-don't-implement: row captures research scope, does NOT authorize implementation start.
AceHack
added a commit
that referenced
this pull request
Apr 25, 2026
…indexes
Maintainer 2026-04-24 directive — every first-class interface on
Zeta's substrate (git, SQL, operator algebra, LINQ, future
GraphQL / blockchain query / WASM-RPC) must compose with every
other interface. Mixed-DSL queries must:
(1) parse + bind through unified type system
(2) plan through cost-based optimizer (full mixed AST)
(3) hit indexes for each constituent DSL
(4) preserve retraction semantics end-to-end
Architectural primitive captured: this is a direct application
of the 2026-04-22 semiring-parameterized Zeta substrate research
("one algebra to map the others"). With operator algebra
parameterized by a semiring, every other DSL's semantics maps
into the same one algebra by semiring-swap, and cross-DSL
composability falls out for free.
Phased: Phase 0 design proposal → pairwise adapters → unified
planner/binder → index-utilization audit → retraction-preservation
proof.
Composes with closure-table hardening (#396 — the hierarchical
index this layer hits), native F# git impl (#395), Ouroboros
bootstrap meta-thesis (cross-DSL composability IS an Ouroboros
closure), semiring-parameterized substrate, blockchain ingest
(#394 — chain queries compose via same substrate).
Otto-275 log-don't-implement: research scope captured; does NOT
authorize implementation start.
AceHack
added a commit
that referenced
this pull request
Apr 25, 2026
…indexes (#397) * backlog: cross-DSL composability — git/SQL/operator-algebra/LINQ hit indexes Maintainer 2026-04-24 directive — every first-class interface on Zeta's substrate (git, SQL, operator algebra, LINQ, future GraphQL / blockchain query / WASM-RPC) must compose with every other interface. Mixed-DSL queries must: (1) parse + bind through unified type system (2) plan through cost-based optimizer (full mixed AST) (3) hit indexes for each constituent DSL (4) preserve retraction semantics end-to-end Architectural primitive captured: this is a direct application of the 2026-04-22 semiring-parameterized Zeta substrate research ("one algebra to map the others"). With operator algebra parameterized by a semiring, every other DSL's semantics maps into the same one algebra by semiring-swap, and cross-DSL composability falls out for free. Phased: Phase 0 design proposal → pairwise adapters → unified planner/binder → index-utilization audit → retraction-preservation proof. Composes with closure-table hardening (#396 — the hierarchical index this layer hits), native F# git impl (#395), Ouroboros bootstrap meta-thesis (cross-DSL composability IS an Ouroboros closure), semiring-parameterized substrate, blockchain ingest (#394 — chain queries compose via same substrate). Otto-275 log-don't-implement: research scope captured; does NOT authorize implementation start. * drain(#397): fix 5 Copilot threads on cross-DSL composability row P0/P1/P1/P1/P2 from late Copilot re-review on the freshly-opened PR. All five fixes land as in-place edits to the new BACKLOG row (the row itself was added by this PR, so this is not an append-only-file violation). - title: rewrap so `operator-algebra` stays contiguous (P1). - body: rewrap `closure-table-hardening` contiguous (P1). - body: rewrap inline-code `query-optimizer-expert` contiguous (P0 — inline-code split breaks rendering and grep). - composes-with: closure-table dependency pointer made concrete — names `src/Core/Hierarchy.fs` and the "Closure-table over DBSP" research row under `## Research projects` instead of a non-existent "same section" hardening row (P2). - semiring memory pointer: add `memory/` prefix to match the convention used at the existing semiring rows (P1). Drain log at `docs/pr-preservation/397-drain-log.md` per Otto-250.
Merged
5 tasks
AceHack
added a commit
that referenced
this pull request
Apr 25, 2026
…ith-state-by-default Maintainer 2026-04-24 directive — THE UX thesis. Maintainer self-flagged: "this is a big and not very clear ask please backlog and untangle". Captures the killer-UX target: user code looks like normal sync I/O but actually durable-async, cluster-distributed, state auto-persisting, replay-on-fail. "Where does it run? Everywhere". Class membership: Temporal / Step Functions / Durable Functions / Cadence / Restate / DBOS / Inngest. Built on Zeta substrate + existing Reaqtor research substrate (IQbservable expression- tree machinery — DON'T reinvent). Hard prerequisite: DST determinism (Otto-272 — already factory default; "we will fit in perfect"). DX target: AddZeta() one-line DI registration. Ceremony in user code = thesis drift. Captured in companion memory + 11-point untangle in BACKLOG row: 1. OS-interface as UX killer 2. Durable-async runtime class 3. "Where does it run?" → "Everywhere" 4. AddZeta DX target 5. LINQ/Rx stream composition 6. Reaqtor tie-in (use existing substrate) 7. Usermode-first microkernel preparation 8. Actor interface (secondary, opt-in) 9. Cross-paradigm canonical examples (combinatorial) 10. Distributed event loop with mathematical guarantees 11. Auto runtime optimization + stats Phased: Phase 0 untangle research → Phase 1 single-machine prototype → Phase 2 multi-node → Phase 3 stream composition + cross-DSL examples → Phase 4 actor + formal verification → Phase 5 microkernel promotion. Composes with the ENTIRE 2026-04-24 cluster (#394 / #395 / 2026-04-22 semiring-parameterized operator algebra research (the math substrate). Otto-275 log-don't-implement applies.
AceHack
added a commit
that referenced
this pull request
Apr 25, 2026
…ith-state-by-default (#399) * backlog+memory: OS-interface — durable-async / AddZeta / serverless-with-state-by-default Maintainer 2026-04-24 directive — THE UX thesis. Maintainer self-flagged: "this is a big and not very clear ask please backlog and untangle". Captures the killer-UX target: user code looks like normal sync I/O but actually durable-async, cluster-distributed, state auto-persisting, replay-on-fail. "Where does it run? Everywhere". Class membership: Temporal / Step Functions / Durable Functions / Cadence / Restate / DBOS / Inngest. Built on Zeta substrate + existing Reaqtor research substrate (IQbservable expression- tree machinery — DON'T reinvent). Hard prerequisite: DST determinism (Otto-272 — already factory default; "we will fit in perfect"). DX target: AddZeta() one-line DI registration. Ceremony in user code = thesis drift. Captured in companion memory + 11-point untangle in BACKLOG row: 1. OS-interface as UX killer 2. Durable-async runtime class 3. "Where does it run?" → "Everywhere" 4. AddZeta DX target 5. LINQ/Rx stream composition 6. Reaqtor tie-in (use existing substrate) 7. Usermode-first microkernel preparation 8. Actor interface (secondary, opt-in) 9. Cross-paradigm canonical examples (combinatorial) 10. Distributed event loop with mathematical guarantees 11. Auto runtime optimization + stats Phased: Phase 0 untangle research → Phase 1 single-machine prototype → Phase 2 multi-node → Phase 3 stream composition + cross-DSL examples → Phase 4 actor + formal verification → Phase 5 microkernel promotion. Composes with the ENTIRE 2026-04-24 cluster (#394 / #395 / 2026-04-22 semiring-parameterized operator algebra research (the math substrate). Otto-275 log-don't-implement applies. * fix(#399): add MEMORY.md pointer for OS-interface memory file (paired-edit check) * fix(#399): clarify Reaqtor path is gitignored upstream-sync mirror, not in-tree
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Captures maintainer 2026-04-24 directive for first-class blockchain block ingestion into Zeta's distributed DB. BTC → ETH → SOL priority order. Verbatim directive preserved in memory.
Two motivations
Architectural frame (maintainer-explicit)
NOT a fork of bitcoind / geth / solana-labs. Full node layered ON TOP of Zeta's distributed DB — distributed-node support falls out of Zeta's multi-node primitives for free.
Phased scope (this row is the umbrella)
net_processing.cppDoS scoring, ETH devp2p/Snap reciprocity, SOL turbine-shred forwarding).Additional chains flagged for later
Cosmos Hub (IBC bridge primitive), Polkadot (parachain architecture), Cardano (Ouroboros pedagogy), Avalanche (subnets), L2 rollups (bridge-to-ETH substrate). Do NOT reorder BTC/ETH/SOL.
Does NOT authorize
Test plan
🤖 Generated with Claude Code