Evonode — executes
go · dashpay/tenderdash
Tenderdash
BFT consensus; each block signed by one quorum BLS threshold signature
rs-drive-abci
Drive ABCI
Execution layer: validates state transitions, commits the root hash as app hash
rs-drive
Drive
State layout, secondary indexes, the query engine, deterministic fees
grovedb
GroveDB
Hierarchy of Merkle trees under a single provable root hash
merk · mmr · bulk-append · commitment
Tree structures
Merkle AVL trees plus append-only structures for special workloads
grovedb-storage
RocksDB storage
Key-value bottom: 4 column families, blake3 prefix per subtree
Shared edge
rs-dapi · dapi-grpc · envoy
DAPI
Decentralized API on every evonode — no central RPC
⟵ gRPC · queries · broadcasts · proofs ⟶
rs-dpp
DPP
The shared protocol: identities, contracts, documents, tokens, state transitions
Client — verifies
e.g. SwiftExampleApp
Client app
UI + platform persistence; keys stay in the OS keystore
swift-sdk · kotlin-sdk · js-evo-sdk
SDK bindings
Thin native shells over one Rust core — C ABI, JNI, and WASM
rs-platform-wallet-ffi
Platform Wallet FFI
371-function C ABI; host apps plug persistence in via a callback vtable
rs-platform-wallet
Platform Wallet
Identities, DashPay contacts, names, tokens, asset locks, shielded notes
rs-sdk
RS SDK
Fetch & broadcast with proofs on by default
rust-dashcore
Rust Dash Core
key-wallet · SPV · masternode-list engine
rs-drive --features verify
Drive Verify
The server's own query code, recompiled to check its answers
grovedb --features verify
GroveDB Verify
Proof execution without storage — runs in WASM and on phones
rs-drive-proof-verifier
Proof verification
Rebuilt root hash + quorum key → one BLS check settles everything
LAYER 1
Dash Core
Both columns stand on it: evonodes read it over RPC (chainlocks, masternode lists, quorums); clients sync it over P2P (dash-spv). Credits enter via asset locks, leave via quorum-signed asset unlocks.