A weighted walk.
Markov Chain Monte Carlo provides a random-walk foundation for selecting vertices through the graph.
Inside the protocol
Complex engineering.
Beautifully connected.
A visual journey through VINE, the directed acyclic graph at the heart of Grape.
Based on VINE technical paper v.02VINE / EXPLORABLE ARCHITECTURE
One network. Many moving parts.
File referencesNFT ownershipTransactionsContract calls
01 / Ledger structure
One graph.
Many paths.
VINE groups transactions into entities called sites. Each new site links to two earlier sites, building a directed graph of direct and indirect confirmations.
A parallel sequence of commit transactions coordinates the evolving graph into shared ledger state.
VINE technical paper · p. 9VINE / TWO COMPLEMENTARY STRUCTURESConceptual visualization
Swipe across the graph to explore its connections ↔
Site connectionsCommit sequence
02 / Transaction lifecycle
From intent
to shared state.
Follow a transaction through the architecture. Each stage does a specific job, from a client’s signature to the network’s coordinated ledger view.
VINE technical paper · p. 11FOLLOW ONE TRANSACTION01 / 04
An intent becomes a signed transaction.
A client creates and signs a transaction, then sends it to a network node.
ILLUSTRATIVE TRANSACTION · NOT LIVE ACTIVITY
Select a stage or play the journey
03 / Vertex selection
Connection is
a considered choice.
VINE describes a family of selection algorithms that choose earlier sites to reference. The objective: grow the graph while managing confirmation and consistency.
Refining the path.
A VINE adaptation of the selection process, described in the paper’s algorithm sequence.
More context.
Extends site weighting with factors such as node ratings and commissions in the paper’s proposed model.
04 / Commit transactions
Parallel work.
Coordinated truth.
Commits organize verified sites, account balances and smart-contract results into a consistent reference point.
The paper describes a roughly five-second commit cadence. This is a document-era design parameter, not a current finality guarantee.
VINE technical paper · p. 20FROM ACTIVITY TO LEDGER STATEVINE / COMMITS
05 / Smart contracts
Programmable logic.
Consistent state.
Smart contracts use the ledger state published in commits. Changes in intervening sites become available through the next coordinated state update.
01
Create or call
A transaction deploys a contract or invokes an existing one.
02
Verify
Contract transactions pass through the verification process.
03
Execute
Execution produces results, receipts and state changes.
04
Coordinate
Commit data makes the resulting state available consistently.
The EVM connection
Grape’s current product direction brings EVM compatibility to this DAG foundation. The older VINE paper describes smart-contract processing; it does not define the current EVM integration, RPC endpoints or supported tooling versions.
06 / Synchronization
Separate nodes.
A connected view.
Every node keeps its own view of the network. See how a shared starting point, connected graph records and peer-to-peer updates bring those views together.
VINE technical paper · p. 2101
Start from a commit
Swipe to explore · Arrow keys when focused
A shared starting point.
A new node receives a recent commit reference: a coordinated view of ledger state. Related records follow, giving the node a foundation while synchronization continues.
In the paper’s implementation, a leader provides the initial commit.
02
Synchronize graph sites
Swipe to explore · Arrow keys when focused
Fill the gaps. Connect the records.
A node requests missing sites, including earlier records referenced by a newly received site. Structure and signature checks help it connect valid records to its local graph.
This brings relevant sites not yet included in a commit into the local view.
03
Exchange with peers
Swipe to explore · Arrow keys when focused
An update becomes shared knowledge.
Nodes pass new sites, contract transactions and commit references to connected peers. Those peers check and relay the updates, carrying information across the network.
The paper describes gossip communication based on a modification of HyParView.
04
Manage growth
Swipe to explore · Arrow keys when focused
More history. A considered path forward.
The paper proposes organizing fully verified history into slices to reduce repeated verification. It also identifies sharding as a direction for dividing future workloads.
Development concepts: slicing was not implemented at the paper’s publication stage.
Conceptual views of the architecture described in the VINE technical paper.Explore development directions
07 / Under the surface
The data behind
the network.
Different records do different jobs. Explore how a transaction becomes a site, how commits organize state, and what execution leaves behind.
Data formats · p. 2401
Sites
Swipe to explore · Arrow keys when focused
A transaction becomes a connected graph record.
A site carries a transaction with its identifier, timestamp and verification-related data. It references two earlier sites, connecting its activity to the wider DAG.
Those connections support direct and indirect graph confirmation.
02
Commit transactions
Swipe to explore · Arrow keys when focused
Parallel activity. An ordered ledger reference.
A commit gathers site references, included site records, balances and contract-execution data. Each commit links to its predecessor in a separate sequence alongside the transaction DAG.
Contract receipts and state differences occupy distinct parts of the record.
03
Account model
Swipe to explore · Arrow keys when focused
An account is a defined set of state fields.
The paper lists an address, balance, nonce, code hash and code. An account update carries a new account value; the commit’s balance map connects wallet identifiers with balances.
Account fields follow the format documented in Appendix A.
04
Contract receipts and state differences
Swipe to explore · Arrow keys when focused
What happened. What changed.
A receipt reports success or failure, execution fuel used, a status message and logs. State differences separately describe either a storage update or a new account value, and travel with the commit.
Execution results and state changes are related records with different responsibilities.
05
Confirmation and finality
Swipe to explore · Arrow keys when focused
Seen, referenced and accepted mean different things.
Propagation spreads an update to peers. Graph confirmation reflects sites that reference it directly or indirectly. Commit acceptance depends on the implemented verification and consensus rules; speed alone does not establish irreversible finality.
The paper states that validator consensus acceptance of commits was not implemented at its publication stage.
Conceptual explanations of the data structures documented in the VINE technical paper.Explore the original data formats
Go straight to the source.
VINE technical paper v.02 · 27 pages · PDF
A transparent view of the architecture
This visual guide explains the supplied VINE paper. It is an architecture reference, not certification of current mainnet behavior. The paper notes that validator acceptance of commits and slicing were not implemented at its publication stage, and its smart-contract flow used a leader implementation. Current benchmarks, deployed consensus, audit reports and operational parameters require separate release evidence.