# How 3DPass Handles Deterministic Finality with the GRANDPA Protocol

> Discover how 3DPass ensures deterministic finality using the GRANDPA protocol. Learn how PoScan and GRANDPA votes guarantee irreversible blocks on the blockchain.

- Repository: [3Dpass/3dp](https://github.com/3dpass/3dp)
- Tags: deep-dive
- Published: 2026-02-23

---

**3DPass achieves deterministic finality by combining its PoW-based PoScan engine with Substrate’s GRANDPA finality gadget, where GRANDPA provides super-majority finality votes that override fork-choice rules and guarantee irreversible blocks.**

The 3DPass blockchain utilizes a hybrid consensus model that merges proof-of-work security with deterministic finality guarantees. Within the `3dpass/3dp` repository, the network implements Substrate’s GRANDPA (GHOST-based Recursive Ancestor Deriving Prefix Agreement) protocol to finalize blocks after they are produced by the PoScan mining algorithm. This architecture ensures that once a block is finalized by GRANDPA, all honest nodes permanently agree on its place in the canonical chain regardless of network latency or temporary forks.

## Hybrid Consensus Architecture (PoW + GRANDPA)

The 3DPass consensus stack operates as a two-layer system. The **PoScan** engine handles block production through computational work (PoW), while **GRANDPA** handles finalization through Byzantine fault-tolerant voting. This separation allows the network to maintain high throughput via PoW while achieving the deterministic finality necessary for secure settlement and cross-chain interoperability.

## GRANDPA Integration in the Node Service

The node implementation in [`nodes/poscan-consensus/src/service.rs`](https://github.com/3dpass/3dp/blob/main/nodes/poscan-consensus/src/service.rs) orchestrates the interaction between PoW verification and GRANDPA finality.

### Block Import Pipeline

The service constructs a chained block import pipeline where GRANDPA wrapping occurs first, followed by PoW validation. The `sc_finality_grandpa::block_import` function creates the GRANDPA block import instance and its associated communication link:

```rust
let (grandpa_block_import, grandpa_link) = sc_finality_grandpa::block_import(
    client.clone(),
    &(client.clone() as Arc<_>),
    select_chain.clone(),
    telemetry.as_ref().map(|x| x.handle()),
)?;

```

This `grandpa_block_import` is then wrapped by the PoW block import, ensuring every block undergoes PoW verification before GRANDPA processes it for finality:

```rust
let pow_block_import = sc_consensus_poscan::PowBlockImport::new(
    grandpa_block_import.clone(),
    client.clone(),
    poscan_grid2d::PoscanAlgorithm::with_skip_check(client.clone(), skip_check),
    0,
    select_chain.clone(),
    CreateInherentDataProviders { author: Some(auth.encode()) },
    can_author_with,
);

```

### GRANDPA Voter Task

An essential voter task runs continuously to cast votes and finalize blocks. The service spawns this task using `sc_finality_grandpa::run_grandpa_voter`, configured with network parameters and voting rules. If this voter task fails, the entire node service shuts down, enforcing that only GRANDPA-finalized blocks are accepted:

```rust
let grandpa_config = sc_finality_grandpa::GrandpaParams {
    config: grandpa_config,
    link: grandpa_link,
    network,
    voting_rule: sc_finality_grandpa::VotingRulesBuilder::default().build(),
    prometheus_registry,
    shared_voter_state: shared_voter_state.clone(),
    telemetry: telemetry.as_ref().map(|x| x.handle()),
};
task_manager.spawn_essential_handle().spawn_blocking(
    "grandpa-voter",
    sc_finality_grandpa::run_grandpa_voter(grandpa_config)?,
);

```

## Deterministic Finality Guarantees

GRANDPA provides **deterministic finality** by requiring a super-majority vote (two-thirds) from the authority set defined in the runtime. Unlike probabilistic finality systems where blocks become increasingly secure with more confirmations, GRANDPA-finalized blocks are irreversible and agreed upon by all honest nodes instantly, independent of network latency or fork-choice rules.

### Light-Client Finality Shortcut

For light clients or resource-constrained nodes, 3DPass offers a `skip_check` mode that optimizes synchronization by trusting GRANDPA finality digests exclusively. When enabled, the PoW verifier skips full seal verification and accepts blocks solely based on valid GRANDPA finality proofs. This configuration appears in [`consensus/poscan_grid2d/src/lib.rs`](https://github.com/3dpass/3dp/blob/main/consensus/poscan_grid2d/src/lib.rs):

```rust
// The skip_check option allows a node to trust only GRANDPA finality digests.
if self.skip_check {
    // In this mode we *do not* verify the PoW seal; we accept the block
    // when a valid GRANDPA finality digest is present.
    return Ok(true);
}

```

This demonstrates that GRANDPA’s finality digest serves as the ultimate source of truth, even superseding PoW verification in certain operational modes.

## Runtime Support for GRANDPA

The runtime in [`runtime/src/lib.rs`](https://github.com/3dpass/3dp/blob/main/runtime/src/lib.rs) implements the `GrandpaApi` trait required by the GRANDPA gadget. This API exposes authority set information and scheduled changes, enabling the voter to query the current validator set and manage transitions:

```rust
impl sp_finality_grandpa::GrandpaApi<Block> for Runtime {
    fn current_set_id() -> sp_finality_grandpa::SetId { … }
    fn pending_change() -> Option<sp_finality_grandpa::ScheduledChange<BlockNumber>> { … }
    // other required methods …
}

```

The runtime also defines the `GRANDPA_ENGINE_ID` constant used to identify GRANDPA-related digests within block headers, ensuring the consensus engine correctly parses finality information.

## Summary

- **Hybrid Architecture**: 3DPass combines PoScan (PoW) for block production with GRANDPA for deterministic finalization, implemented in the `3dpass/3dp` repository.
- **Chained Import**: The node service wraps GRANDPA block import within PoW verification at [`nodes/poscan-consensus/src/service.rs`](https://github.com/3dpass/3dp/blob/main/nodes/poscan-consensus/src/service.rs), ensuring blocks are valid before finalization.
- **Essential Voter**: The GRANDPA voter task runs as an essential service component; its failure triggers node shutdown to prevent participation in unfinalized chains.
- **Super-Majority Finality**: GRANDPA achieves deterministic finality through Byzantine fault-tolerant voting requiring agreement from two-thirds of the authority set.
- **Light-Client Optimization**: The `skip_check` mode in [`consensus/poscan_grid2d/src/lib.rs`](https://github.com/3dpass/3dp/blob/main/consensus/poscan_grid2d/src/lib.rs) allows nodes to trust GRANDPA finality digests exclusively, skipping PoW verification when appropriate.

## Frequently Asked Questions

### What is deterministic finality in 3DPass?

Deterministic finality in 3DPass means that once a block is finalized by the GRANDPA protocol, it becomes irreversible and permanently canonical. Unlike probabilistic systems where reversals are theoretically possible (though unlikely) after many confirmations, GRANDPA guarantees that all honest nodes will agree on the finalized block immediately after the super-majority vote completes, regardless of network partitions or latency.

### How does GRANDPA interact with the PoScan PoW mechanism?

GRANDPA operates as a finality layer atop the PoScan PoW engine. Miners produce blocks using the PoScan algorithm, and these blocks undergo PoW verification via `sc_consensus_poscan::PowBlockImport`. After passing PoW checks, blocks enter the GRANDPA finalization pipeline where validators vote to finalize them. This separation allows 3DPass to combine the decentralization benefits of PoW with the fast, irreversible finality of GRANDPA.

### What happens if the GRANDPA voter fails in 3DPass?

If the GRANDPA voter task fails, the entire node service shuts down. The service spawns the voter using `task_manager.spawn_essential_handle().spawn_blocking()`, which marks it as an essential task. This design ensures that nodes cannot continue operating or accepting blocks if they are unable to participate in or verify the finality process, maintaining network consistency and preventing split-brain scenarios.

### Can light clients skip PoW verification in 3DPass?

Yes, light clients can skip PoW verification by enabling the `skip_check` flag in the `PoscanAlgorithm` configuration. When activated, the verifier in [`consensus/poscan_grid2d/src/lib.rs`](https://github.com/3dpass/3dp/blob/main/consensus/poscan_grid2d/src/lib.rs) accepts blocks based solely on the presence of valid GRANDPA finality digests rather than verifying the PoW seal. This optimization reduces computational overhead for light clients while maintaining security through GRANDPA's deterministic finality guarantees.