Guraba Network

Whitepaper v1.0

Published by Guraba Inc. February 2026

Abstract

Guraba is an independent, high-performance Layer 1 blockchain network developed by Guraba Inc., built on a modern Proof-of-Stake consensus mechanism. Unlike most blockchain projects that create a token and then search for utility, Guraba takes the opposite approach: GRB is the native payment method for Guraba Inc.'s real-world services. The network is purpose-designed to enable fast, secure, and dollar-independent digital payments directly within Guraba Inc.'s service ecosystem — without dependence on traditional fiat currencies, banking intermediaries, or centralized payment processors.

This whitepaper outlines the technical architecture, economic model, governance framework, and long-term vision of the Guraba Network.

Introduction
Problem Statement
Solution: Guraba Network
Technical Architecture
Consensus Mechanism
GRB Token
Tokenomics
Staking & Validation
Block Rewards & Mining
Transaction Lifecycle
Use Cases
Governance
Roadmap
Security
Risk Factors
Conclusion
References
Legal Disclaimer

1. Introduction

1.1 Background

The global financial system, built over centuries, revolves around a small number of reserve currencies — most prominently the United States Dollar (USD). While this system has facilitated international trade, it has also created deep structural dependencies that disproportionately affect businesses and consumers in emerging markets. Exchange rate volatility, capital controls, and reliance on correspondent banking networks introduce friction, cost, and uncertainty into everyday economic activity.

Blockchain technology offers a fundamentally different paradigm: a decentralized, transparent, and programmable financial infrastructure that operates without borders or intermediaries. Since the launch of Bitcoin in 2009 and Ethereum in 2015, the blockchain ecosystem has demonstrated that peer-to-peer value transfer is not only possible but can be more efficient, more inclusive, and more resilient than traditional alternatives.

1.2 Vision

Guraba Inc. was founded with a singular vision: to build a blockchain network where digital currency has real utility — not as a speculative asset, but as the native payment method for real services. Guraba Inc. operates across multiple service sectors, and GRB is the primary currency for all transactions within this ecosystem. We envision a self-reinforcing economy where the value of GRB is backed by the real services it can purchase — independent of any single national currency or speculative market.

1.3 Mission

Our mission is to:

Build and maintain a secure, scalable, and energy-efficient blockchain network.
Create a native digital currency (GRB) with real-world purchasing power.
Onboard service sector businesses as GRB-accepting merchants.
Develop tools and infrastructure that make blockchain payments as simple as traditional ones.
Foster a decentralized community of validators, developers, and users.

2. Problem Statement

2.1 Dollar Dependency

Businesses operating outside the US dollar ecosystem face significant challenges:

Exchange rate volatility: A business that prices services in a local currency may see its purchasing power erode by 20-50% in a single year due to currency depreciation against the USD.
Conversion costs: Every cross-border transaction involves currency conversion, with banks and payment processors taking 2-7% in fees.
Access barriers: Many businesses in developing regions lack access to USD-denominated banking, limiting their ability to participate in the global economy.

2.2 Traditional Payment Infrastructure

The existing payment infrastructure was designed for a pre-digital era:

Slow settlement: Wire transfers take 1-5 business days. Even "instant" payment systems are limited to domestic transactions.
High intermediary costs: A typical international payment passes through 3-5 intermediary banks, each adding fees and delays.
Opaque pricing: Hidden fees, unfavorable exchange rates, and unpredictable costs make financial planning difficult for businesses.
Censorship risk: Centralized payment processors can freeze accounts, reverse transactions, or deny service without transparent due process.

2.3 Existing Blockchain Limitations

While existing blockchains have demonstrated the potential of decentralized payments, they face their own challenges:

Bitcoin: Slow block times (10 minutes), high fees during congestion, limited programmability.
Ethereum: High gas fees during peak usage (sometimes exceeding $50 per transaction), making it impractical for everyday payments.
Layer 2 solutions: While faster and cheaper, they add complexity and require users to understand bridging, which hampers adoption.
Speculation-driven ecosystems: Most alternative blockchains are dominated by speculative trading (DeFi, yield farming) rather than genuine economic activity tied to real services.

3. Solution: Guraba Network

3.1 Overview

Guraba Network is a sovereign Layer 1 blockchain that addresses these challenges through:

| Feature | Description | |---|---| | Fast transactions | 12-second block times with finality in ~2-3 epochs (~13-19 minutes) | | Low fees | Minimal gas costs denominated in GRB, making micropayments viable | | Dollar independence | A self-contained economy where GRB is the primary unit of account | | EVM compatibility | Full Ethereum Virtual Machine support for smart contracts and automation | | Real utility | Native payment method for Guraba Inc.'s service ecosystem | | Energy efficient | Proof-of-Stake consensus consumes 99.9% less energy than Proof-of-Work | | Accessible staking | Low minimum stake (100 GRB) enables broad validator participation |

3.2 Design Principles

Guraba Network is built on four core principles:

Utility over speculation: Every design decision prioritizes real-world usability over speculative trading appeal.
Simplicity: The network should be as easy to use as traditional payment systems — for both consumers and merchants.
Sovereignty: Guraba operates its own independent consensus, free from the security assumptions or governance decisions of any other chain.
Sustainability: The economic model is designed for long-term viability, with controlled inflation and deflationary mechanisms working in balance.

3.3 Why a New Chain?

Rather than deploying as a token on an existing blockchain or building a Layer 2, Guraba Inc. chose to build a sovereign Layer 1 because:

Full control over parameters: Block times, gas limits, staking requirements, and upgrade schedules are tailored to Guraba's specific use case.
No dependency on external chains: Guraba's security and availability do not depend on Ethereum, Binance Smart Chain, or any other network.
Custom economics: GRB's monetary policy is designed from the ground up, not constrained by the host chain's token model.
Network identity: A dedicated blockchain establishes Guraba as an independent ecosystem, not just another token in a crowded marketplace.

4. Technical Architecture

4.1 System Overview

Guraba's architecture follows the modular design pioneered by Ethereum's post-Merge architecture, separating the execution layer from the consensus layer:

┌──────────────────────────────────────────────────────────────┐
│                      Guraba Network                          │
│                                                              │
│  ┌────────────────┐  ┌────────────────┐  ┌────────────────┐ │
│  │    Node 1       │  │    Node 2       │  │    Node 3       │ │
│  │                 │  │                 │  │                 │ │
│  │  ┌───────────┐ │  │  ┌───────────┐ │  │  ┌───────────┐ │ │
│  │  │   Geth    │ │  │  │   Geth    │ │  │  │   Geth    │ │ │
│  │  │ Execution │ │  │  │ Execution │ │  │  │ Execution │ │ │
│  │  └─────┬─────┘ │  │  └─────┬─────┘ │  │  └─────┬─────┘ │ │
│  │        │Engine  │  │        │Engine  │  │        │Engine  │ │
│  │        │  API   │  │        │  API   │  │        │  API   │ │
│  │  ┌─────┴─────┐ │  │  ┌─────┴─────┐ │  │  ┌─────┴─────┐ │ │
│  │  │  Prysm    │ │  │  │  Prysm    │ │  │  │  Prysm    │ │ │
│  │  │ Consensus │ │  │  │ Consensus │ │  │  │ Consensus │ │ │
│  │  └─────┬─────┘ │  │  └─────┬─────┘ │  │  └─────┬─────┘ │ │
│  │        │       │  │        │       │  │        │       │ │
│  │  ┌─────┴─────┐ │  │  ┌─────┴─────┐ │  │  ┌─────┴─────┐ │ │
│  │  │ Validator │ │  │  │ Validator │ │  │  │ Validator │ │ │
│  │  └───────────┘ │  │  └───────────┘ │  │  └───────────┘ │ │
│  └────────────────┘  └────────────────┘  └────────────────┘ │
│                                                              │
│              P2P Network (libp2p + devp2p)                   │
└──────────────────────────────────────────────────────────────┘

4.2 Execution Layer (Geth)

The execution layer is responsible for processing transactions, executing smart contracts, and maintaining the world state. Guraba uses a custom fork of go-ethereum (Geth) — the most widely deployed Ethereum client with over 8 years of battle-testing.

Key capabilities:

EVM execution: Full support for all Ethereum opcodes and precompiled contracts.
State management: Patricia Merkle Trie for efficient state storage and proof generation.
Transaction pool: Mempool management with priority ordering based on gas price.
JSON-RPC API: Standard Ethereum JSON-RPC interface for wallet and dApp integration.
Peer discovery: devp2p protocol for finding and connecting to other execution nodes.

Network parameters:

| Parameter | Value | |---|---| | Chain ID | 5502 | | Currency Symbol | GRB | | Decimals | 18 | | Block Time | 12 seconds | | Gas Limit | 30,000,000 | | EVM Version | Shanghai / Electra | | RPC Endpoint | https://rpc.guraba.io | | Block Explorer | https://scan.guraba.io |

4.3 Consensus Layer (Prysm)

The consensus layer manages validator duties, block proposals, attestations, and finality. Guraba uses a custom fork of Prysm — a production-grade Ethereum consensus client written in Go.

Key capabilities:

Beacon Chain: Central coordination mechanism for all validators.
RANDAO: Cryptographically secure random number generation for validator selection.
Casper FFG: Finality gadget ensuring irreversible block confirmation.
LMD-GHOST: Fork choice rule for selecting the canonical chain.
Validator management: Registration, activation, exit, and slashing of validators.

Communication between layers:

The execution and consensus layers communicate via the Engine API — an authenticated JSON-RPC interface that allows the beacon chain to:

Request new execution payloads (blocks) from Geth.
Validate execution payloads received from the network.
Update the fork choice (head of the chain).

4.4 Networking

Guraba uses two peer-to-peer networking protocols:

devp2p (Execution Layer): Discovery and communication between Geth nodes for transaction propagation and state synchronization.
libp2p (Consensus Layer): Discovery and communication between beacon chain nodes for block proposals, attestations, and sync committees.

Both protocols use encrypted connections (TLS/Noise) and support NAT traversal for nodes behind firewalls.

4.5 Data Storage

| Component | Storage | Purpose | |---|---|---| | Execution state | LevelDB / PebbleDB | Account balances, contract storage, nonces | | Blockchain data | LevelDB / PebbleDB | Block headers, bodies, receipts, logs | | Beacon state | BoltDB | Validator registry, balances, slashings | | Beacon blocks | BoltDB | Beacon block headers and bodies |

4.6 API Endpoints

Guraba provides comprehensive API access for developers and integrators:

| API | Protocol | Purpose | |---|---|---| | JSON-RPC | HTTP/WebSocket | Transaction submission, state queries, event logs | | Beacon API | REST (HTTP) | Validator status, chain state, finality info | | Validator API | gRPC | Validator duties, key management |

5. Consensus Mechanism

5.1 Proof of Stake (PoS)

Guraba uses Proof-of-Stake consensus, a mechanism where validators lock up ("stake") GRB tokens as collateral to participate in block production and validation. This approach offers significant advantages over Proof-of-Work:

| Dimension | Proof-of-Work | Guraba PoS | |---|---|---| | Energy consumption | ~100 TWh/year (Bitcoin) | Negligible | | Hardware requirement | Specialized ASICs ($5,000+) | Standard server ($20-50/month) | | Minimum investment | Thousands of dollars | 100 GRB | | Attack cost | 51% of hashrate | 2/3 of total stake | | Finality | Probabilistic (~60 min) | Deterministic (~13-19 min) | | Throughput | ~7 TPS (Bitcoin) | ~100+ TPS |

5.2 How Consensus Works

The consensus process follows a predictable cycle:

Slot assignment: Every 12 seconds, the protocol randomly selects one validator to propose a block using RANDAO-based randomness.
Block proposal: The selected validator constructs a block containing pending transactions from the mempool and broadcasts it to the network.
Attestation: All other active validators verify the proposed block and submit attestations (votes) confirming its validity.
Aggregation: Attestations are aggregated into compact signatures using BLS (Boneh-Lynn-Shacham) cryptography.
Finality: After two consecutive epochs of successful attestations, blocks are finalized via the Casper FFG mechanism. Finalized blocks cannot be reverted under any circumstance without slashing 1/3 of all staked GRB.

5.3 Electra Upgrade (EIP-7251)

Guraba implements Ethereum's Electra upgrade, which introduces MaxEB (Maximum Effective Balance) — a significant improvement to validator economics:

Before Electra (traditional PoS):

Each validator is limited to exactly 32 ETH effective balance.
Large stakers must run multiple validators (100 validators for 3,200 ETH).
Excess balance above 32 ETH is not counted for rewards.

With Electra on Guraba:

Validators can have effective balances between 100 GRB (minimum) and 10,000 GRB (maximum).
A single validator can stake up to 10,000 GRB with compounding credentials.
Rewards scale proportionally with stake size.
Fewer validators needed for the same total stake, reducing network overhead.

5.4 Epochs and Slots

| Parameter | Value | Description | |---|---|---| | Slot duration | 12 seconds | Time between consecutive block slots | | Slots per epoch | 32 | Number of slots in one epoch | | Epoch duration | 384 seconds (6.4 min) | Time for one complete epoch | | Finality delay | 2-3 epochs | Time until a block is irreversible | | Sync committee period | 256 epochs (~27 hours) | Rotation period for sync committees |

5.5 Fork Choice Rule

When validators see multiple competing chain heads (forks), they follow the LMD-GHOST (Latest Message Driven Greedy Heaviest Observed Sub-Tree) algorithm:

Each validator's most recent attestation is considered.
The fork with the most accumulated attestation weight is selected as the canonical head.
This ensures the network converges on a single chain even in the presence of network partitions.

6. GRB Token

6.1 Overview

GRB is the native currency of the Guraba Network, serving as the fundamental unit of value within the ecosystem. Unlike ERC-20 tokens that exist as smart contract entries, GRB is a protocol-level currency — it exists at the base layer of the blockchain and is required for all network operations.

6.2 Functions

GRB serves four primary functions within the Guraba ecosystem:

1. Gas (Transaction Fees) Every operation on the Guraba Network — from simple transfers to complex smart contract interactions — requires gas, paid in GRB. Gas pricing follows the EIP-1559 mechanism:

Base fee: Algorithmically determined by network congestion. This fee is burned (permanently removed from supply).
Priority fee (tip): Optional fee paid directly to the block proposer for faster inclusion.
Gas limit: Maximum gas a transaction can consume.

2. Staking Validators must stake GRB to participate in consensus. The staked GRB serves as collateral — validators who act honestly earn rewards, while those who act maliciously lose their stake through slashing.

3. Medium of Exchange GRB is designed to be used as payment for goods and services within the Guraba ecosystem. Service providers set prices in GRB, creating a self-contained economy.

4. Governance In future phases, GRB holders will participate in on-chain governance, voting on protocol upgrades, parameter changes, and treasury allocation.

6.3 Denominations

GRB follows the same denomination structure as Ethereum's Ether:

| Unit | GRB Value | Wei Value | Common Usage | |---|---|---|---| | Wei | 0.000000000000000001 | 1 | Smart contract precision | | Kwei | 0.000000000000001 | 1,000 | — | | Mwei | 0.000000000001 | 1,000,000 | — | | Gwei | 0.000000001 | 1,000,000,000 | Gas prices | | Microether | 0.000001 | 1,000,000,000,000 | — | | Milliether | 0.001 | 1,000,000,000,000,000 | Small payments | | GRB | 1 | 1,000,000,000,000,000,000 | Standard unit |

6.4 EIP-1559 Fee Mechanism

Guraba implements EIP-1559, which introduces a dynamic base fee that adjusts based on network congestion:

When blocks are >50% full, the base fee increases (up to 12.5% per block).
When blocks are <50% full, the base fee decreases.
The base fee is burned, creating deflationary pressure on GRB supply during periods of high usage.

This mechanism provides:

Predictable fees: Users can estimate costs more accurately.
Reduced overpayment: The base fee algorithm prevents excessive fee bidding.
Supply pressure: High network activity burns GRB, potentially making it deflationary over time.

7. Tokenomics

7.1 Supply Overview

| Metric | Value | |---|---| | Genesis Supply | 100,000,000 GRB | | Maximum Supply | No hard cap (inflationary via staking rewards) | | Target Annual Inflation | ~2-5% (varies with staking participation rate) | | Deflationary Mechanism | EIP-1559 base fee burn | | Net Inflation | Depends on network activity vs. staking rewards |

7.2 Genesis Distribution

The initial 100,000,000 GRB is allocated as follows:

Genesis Supply: 100,000,000 GRB
│
├── Ecosystem & Development .... 30,000,000 GRB  (30%)
│   ├── dApp development grants
│   ├── Developer tooling
│   ├── Hackathons and bounties
│   └── Infrastructure costs
│
├── Staking Rewards Pool ....... 25,000,000 GRB  (25%)
│   ├── Validator block rewards
│   ├── Attestation rewards
│   └── Sync committee rewards
│
├── Team & Founders ............ 15,000,000 GRB  (15%)
│   ├── 6-month cliff
│   ├── 24-month linear vesting
│   └── Locked in smart contract
│
├── Service Partnerships ....... 15,000,000 GRB  (15%)
│   ├── Merchant onboarding incentives
│   ├── Payment integration rewards
│   └── Business development
│
├── Community & Airdrop ........ 10,000,000 GRB  (10%)
│   ├── Early adopter rewards
│   ├── Community campaigns
│   ├── Social media engagement
│   └── Testnet participation rewards
│
└── Reserve ..................... 5,000,000 GRB  ( 5%)
    ├── Emergency fund
    ├── Unforeseen opportunities
    └── Multisig-controlled

7.3 Allocation Details

Ecosystem & Development (30% — 30,000,000 GRB)

This is the largest allocation, reflecting Guraba Inc.'s commitment to building a thriving ecosystem. Funds will be used for:

Grants to developers building dApps on Guraba.
Development of core infrastructure (wallets, SDKs, APIs).
Hackathons and developer education programs.
Operational costs for running network infrastructure.
Marketing and community building.

Disbursement: Managed by Guraba Inc. with quarterly transparency reports.

Staking Rewards Pool (25% — 25,000,000 GRB)

Dedicated to rewarding validators who secure the network. This pool provides supplementary rewards on top of transaction fees:

Distributed proportionally based on validator stake and uptime.
Designed to last approximately 5-7 years at projected staking participation rates.
After pool depletion, validators earn exclusively from transaction fees and protocol-level inflation.

Team & Founders (15% — 15,000,000 GRB)

Allocated to the founding team at Guraba Inc. to align long-term incentives:

6-month cliff: No tokens accessible for the first 6 months after mainnet launch.
24-month linear vesting: After the cliff, tokens unlock gradually over 2 years.
Smart contract lock: Vesting is enforced on-chain, verifiable by anyone.

This ensures the team is committed to the long-term success of the network.

Service Partnerships (15% — 15,000,000 GRB)

Allocated to onboard real-world businesses into the GRB economy:

Incentives for merchants who accept GRB payments.
Integration grants for payment processors and POS systems.
Partnership deals with service providers in key sectors.

Community & Airdrop (10% — 10,000,000 GRB)

Distributed to build a broad base of GRB holders:

Airdrops to early community members.
Rewards for social media engagement and content creation.
Testnet participation bonuses.
Referral programs.

Reserve (5% — 5,000,000 GRB)

Held in a multisig wallet controlled by Guraba Inc. for:

Emergency situations requiring rapid response.
Strategic opportunities that arise unexpectedly.
Future service expansion capital.

7.4 Emission Schedule

New GRB is minted as staking rewards with each epoch. The emission rate is designed to decrease over time:

| Period | Annual Emission | Cumulative Supply | Inflation Rate | |---|---|---|---| | Year 1 (2026) | ~5,000,000 GRB | ~105,000,000 GRB | 5.0% | | Year 2 (2027) | ~4,000,000 GRB | ~109,000,000 GRB | 3.8% | | Year 3 (2028) | ~3,000,000 GRB | ~112,000,000 GRB | 2.8% | | Year 4 (2029) | ~2,500,000 GRB | ~114,500,000 GRB | 2.2% | | Year 5 (2030) | ~2,000,000 GRB | ~116,500,000 GRB | 1.7% |

Note: Actual inflation is offset by EIP-1559 base fee burns. At high network utilization, GRB could become net deflationary — meaning more GRB is burned than minted.

7.5 Supply Dynamics

                    Inflationary Pressure
                    ┌─────────────────────┐
                    │  Staking Rewards     │  (+) New GRB minted
                    │  (decreasing rate)   │      per epoch
                    └──────────┬──────────┘
                               │
    Total GRB Supply ──────────┼──────────── Balance Point
                               │
                    ┌──────────┴──────────┐
                    │  EIP-1559 Burns      │  (-) GRB permanently
                    │  (usage dependent)   │      destroyed
                    └─────────────────────┘
                    Deflationary Pressure

8. Staking & Validation

8.1 Becoming a Validator

Anyone can become a validator on the Guraba Network by meeting the following requirements:

Financial Requirements:

| Parameter | Value | |---|---| | Minimum stake | 100 GRB | | Maximum stake (per validator) | 10,000 GRB | | Deposit contract | On-chain at genesis | | Activation delay | ~16 epochs (~100 minutes) |

Hardware Requirements:

| Component | Minimum | Recommended | |---|---|---| | CPU | 4 cores | 8 cores | | RAM | 8 GB | 16 GB | | Storage | 100 GB SSD | 500 GB NVMe SSD | | Bandwidth | 10 Mbps | 100 Mbps | | Uptime | 95%+ | 99%+ |

Software Stack:

| Component | Software | Role | |---|---|---| | Execution client | Geth (Guraba fork) | Transaction processing | | Consensus client | Prysm (Guraba fork) | Block consensus | | Validator client | Prysm Validator | Key management & duties |

8.2 Validator Lifecycle

  Deposit 100+ GRB
        │
        ▼
┌───────────────┐
│   Pending     │  Waiting for deposit to be processed
│  Initialized  │  and included in beacon state
└───────┬───────┘
        │
        ▼
┌───────────────┐
│   Pending     │  In the activation queue, waiting
│   Queued      │  for epoch assignment
└───────┬───────┘
        │  (~16 epochs / ~100 minutes)
        ▼
┌───────────────┐
│    Active     │  Proposing blocks, making attestations,
│   Ongoing     │  earning rewards
└───────┬───────┘
        │
   ┌────┴────┐
   │         │
   ▼         ▼
┌───────┐ ┌──────────┐
│ Exit  │ │ Slashed  │  Voluntary exit or
│       │ │          │  malicious behavior
└───┬───┘ └────┬─────┘
    │          │
    ▼          ▼
┌───────────────┐
│ Withdrawable  │  Stake can be withdrawn
│               │  to designated address
└───────────────┘

8.3 Validator Rewards

Validators earn GRB through three mechanisms:

1. Block Proposals When selected to propose a block, the validator earns:

A base reward proportional to their effective balance.
Priority fees (tips) from all transactions included in the block.
Any MEV (Maximal Extractable Value) captured through transaction ordering.

2. Attestations Every epoch, validators attest to:

The head of the chain (LMD-GHOST vote).
The source and target checkpoints (Casper FFG vote).
Correct and timely attestations earn the full base reward.

3. Sync Committee Every ~27 hours, a random subset of validators is selected for the sync committee:

Sync committee members earn additional rewards for producing sync aggregates.
These aggregates help light clients verify the chain efficiently.

Estimated APY:

| Total Network Stake | Estimated APY | |---|---| | 300 GRB (3 validators) | ~15% | | 1,000 GRB | ~10% | | 10,000 GRB | ~6% | | 100,000 GRB | ~4% | | 1,000,000 GRB | ~2.5% |

APY decreases as more GRB is staked, incentivizing early validators.

8.4 Slashing Conditions

Slashing is the mechanism by which malicious or negligent validators are penalized:

Slashable offenses:

| Offense | Penalty | Description | |---|---|---| | Double proposal | 1/32 of stake | Proposing two different blocks for the same slot | | Double vote | 1/32 of stake | Casting two attestations for the same target | | Surround vote | 1/32 of stake | Creating an attestation that surrounds or is surrounded by a previous one | | Correlation penalty | Up to 100% | Additional penalty based on how many validators are slashed simultaneously |

Inactivity leak: If the network fails to finalize for more than 4 epochs, inactive validators begin losing stake at an accelerating rate. This ensures the network can recover even if a large portion of validators go offline.

8.5 Withdrawal Credentials

Guraba supports three types of withdrawal credentials, determining how rewards and stake withdrawals are handled:

| Type | Prefix | Max Effective Balance | Reward Handling | |---|---|---|---| | BLS | 0x00 | 100 GRB | Manual withdrawal required | | ETH1 (standard) | 0x01 | 100 GRB | Auto-withdrawal to designated address | | Compounding | 0x02 | 10,000 GRB | Rewards auto-restaked up to max |

Compounding credentials are recommended for validators who want to maximize their returns — rewards are automatically added to the validator's effective balance, earning compound interest.

9. Block Rewards & Mining

9.1 Proof-of-Stake "Mining"

In the blockchain industry, "mining" traditionally refers to Proof-of-Work computation — solving mathematical puzzles to earn the right to produce blocks. Guraba uses Proof-of-Stake, which achieves the same goal (block production and network security) through economic stake rather than computational work.

This is sometimes called "virtual mining" or "staking":

| Aspect | PoW Mining (Bitcoin) | Guraba PoS Staking | |---|---|---| | What you invest | Hardware + electricity | GRB tokens | | Annual energy cost | ~$10,000+ per miner | ~$300 (server hosting) | | Carbon footprint | ~700 kg CO2/BTC mined | Negligible | | Minimum investment | $5,000+ (ASIC miner) | 100 GRB | | Returns | Block rewards + fees | Block rewards + fees | | Risk of loss | Hardware depreciation | Slashing (only if malicious) | | Security model | 51% hashrate attack | 2/3 stake attack | | Barrier to entry | High (technical + capital) | Low (standard server + GRB) |

9.2 Fee Distribution

When a block is produced, fees are distributed as follows:

Transaction Fee
      │
      ├── Base Fee ──────────► BURNED (removed from supply permanently)
      │                        Deflationary pressure on GRB
      │
      └── Priority Fee ─────► Fee Recipient Address
           (tip)               Validator's designated wallet

9.3 Fee Recipient

Each validator configures a fee recipient address — the wallet that receives priority fees and MEV rewards. This can be any valid Guraba address and can be changed at any time without unstaking.

10. Transaction Lifecycle

10.1 From Submission to Finality

Understanding how a transaction moves through the Guraba Network:

Step 1: User signs transaction with private key
         │
Step 2:  ▼  Transaction broadcast to network via JSON-RPC
         │
Step 3:  ▼  Transaction enters the mempool (pending pool)
         │     Nodes validate: signature, nonce, balance, gas
         │
Step 4:  ▼  Block proposer selects transactions from mempool
         │     Ordered by priority fee (highest first)
         │
Step 5:  ▼  Block proposed to the network
         │     Includes execution payload (transactions)
         │
Step 6:  ▼  Validators attest to block validity
         │     2/3 of validators must agree
         │
Step 7:  ▼  Block included in chain (1 confirmation)
         │     ~12 seconds after submission
         │
Step 8:  ▼  Block finalized after 2-3 epochs
              ~13-19 minutes — IRREVERSIBLE

10.2 Transaction Types

Guraba supports all standard Ethereum transaction types:

| Type | Description | Typical Gas | |---|---|---| | GRB Transfer | Simple value transfer between accounts | 21,000 | | Contract Deployment | Deploy a new smart contract | 100,000+ | | Contract Interaction | Call a function on a deployed contract | 30,000+ | | ERC-20 Transfer | Transfer tokens deployed on Guraba | 65,000 | | ERC-721 Mint | Create an NFT | 80,000+ |

11. Use Cases

11.1 Guraba Inc. Service Ecosystem

Unlike most blockchain projects that launch a token and then search for utility, Guraba takes the opposite approach: GRB is the native payment method within Guraba Inc.'s existing and planned service offerings. This creates immediate, real demand for GRB from day one.

Guraba Inc. operates across multiple service sectors. All services are priced and payable directly in GRB, creating a closed-loop economy where the token has inherent value tied to real services:

How it works:

┌─────────────┐         ┌─────────────────┐         ┌─────────────┐
│  Customer   │  GRB ──►│  Guraba Inc.     │  GRB ──►│  Service    │
│  buys GRB   │         │  Service Portal  │         │  Delivered  │
└─────────────┘         └─────────────────┘         └─────────────┘
                              │
                              ▼
                        Price is set in GRB
                        No USD conversion
                        Instant settlement

Key difference from other crypto projects:

| Traditional Crypto | Guraba Approach | |---|---| | Token launched, then utility searched | Services exist, token is the payment method | | Value = speculation | Value = real services you can buy | | DEX/CEX trading drives price | Service demand drives price | | Pump and dump risk | Backed by real business activity |

11.2 Direct Service Payments

GRB is used as the primary payment method across Guraba Inc.'s service portfolio:

Digital services: Web hosting, domain registration, cloud infrastructure, SaaS subscriptions — all priced in GRB.
Professional services: Software development, consulting, design — contracted and paid in GRB.
Business solutions: Enterprise tools, API access, developer platforms — billed in GRB.
Future services: As Guraba Inc. expands into new service sectors, each new offering accepts GRB natively.

Pricing model: Services are priced directly in GRB, not converted from USD. This means:

A web hosting plan might cost 50 GRB/month.
A consulting engagement might cost 500 GRB.
Prices are stable in GRB terms, creating predictability for both provider and customer.

11.3 Dollar-Independent Economy

GRB creates a parallel economic system that operates independently from fiat currencies:

No conversion needed: Customers pay in GRB, service providers receive GRB. No bank, no exchange rate, no middleman.
Instant settlement: Payments confirm in 12 seconds, compared to 1-5 business days for credit cards and wire transfers.
Zero chargebacks: Once a GRB payment is confirmed, it is final. This eliminates chargeback fraud that costs businesses billions annually.
Borderless: A customer anywhere in the world can purchase services from Guraba Inc. without dealing with international wire transfers or currency conversion.
Inflation protection: GRB's controlled emission and EIP-1559 burn mechanism provide more predictable monetary policy than many national currencies.

11.4 GRB Value Proposition

The value of GRB is not driven by speculation — it is driven by demand for Guraba Inc.'s services:

More services offered by Guraba Inc.
        │
        ▼
More people need GRB to pay for services
        │
        ▼
Increased demand for GRB
        │
        ▼
GRB value strengthened by real utility
        │
        ▼
More service providers want to accept GRB
        │
        ▼
Ecosystem grows organically

This is fundamentally different from tokens that derive value from trading volume. GRB's value floor is set by the real services it can purchase.

11.5 Smart Contracts

Guraba's full EVM compatibility enables additional functionality:

Payment automation: Smart contracts for recurring subscriptions, escrow, and milestone-based payments.
Loyalty programs: Token-based reward systems for frequent customers.
Service agreements: On-chain contracts that automatically release payment upon service delivery.
Identity: Decentralized identity verification for service access.

11.6 Staking as Passive Income

GRB holders who don't want to spend their tokens can earn passive income through staking:

Earn estimated 5-15% APY depending on network participation.
Contribute to network security while earning rewards.
Compound earnings through compounding withdrawal credentials (0x02).
Exit staking at any time with a short withdrawal delay.

12. Governance

12.1 Current Governance (Phase 1)

During the initial phase, Guraba Inc. maintains governance over protocol parameters and upgrades. This centralized approach ensures rapid iteration and bug fixes during the early stages of the network.

12.2 Planned Decentralization (Phase 3+)

Guraba Inc. is committed to progressive decentralization. Future governance will include:

On-chain voting: GRB holders vote on protocol proposals weighted by stake.
Proposal system: Any GRB holder above a minimum threshold can submit governance proposals.
Timelock: Approved changes are subject to a waiting period before execution.
Parameter governance: Community votes on key parameters such as gas limits, staking minimums, and emission rates.
Treasury governance: Community-directed allocation of ecosystem funds.

12.3 Governance Principles

Transparency: All governance decisions and their rationale are published publicly.
Inclusivity: Low barriers to participation — any GRB holder can vote.
Gradual transition: Decentralization proceeds in stages, ensuring stability at each step.
Technical review: All protocol changes undergo technical review before community vote.

13. Roadmap

Phase 1 — Foundation (Q1 2026) ✅

[x] Mainnet launch with Proof-of-Stake consensus
[x] Genesis block with 100,000,000 GRB initial supply
[x] Block explorer deployment (scan.guraba.io)
[x] Multi-node validator infrastructure (3 geographically distributed nodes)
[x] MetaMask and EVM wallet integration
[x] Public RPC endpoint (rpc.guraba.io)
[x] Electra upgrade (EIP-7251) with flexible staking amounts

Phase 2 — Growth (Q2-Q3 2026)

[ ] Whitepaper publication and distribution
[ ] Community building (Telegram, Discord, Twitter/X)
[ ] First service partner integrations (pilot merchants)
[ ] Staking dashboard web application
[ ] Mobile wallet application (iOS & Android)
[ ] Faucet for developer testing
[ ] SDK and documentation for dApp developers

Phase 3 — Expansion (Q4 2026)

[ ] Full integration of GRB payments into Guraba Inc. service portfolio
[ ] Third-party validator onboarding program
[ ] On-chain governance system launch
[ ] Payment gateway for Guraba Inc. services
[ ] Security audit by independent firm
[ ] Developer grants program (funded from Ecosystem allocation)

Phase 4 — Adoption (2027)

[ ] Expansion of GRB-accepting services
[ ] Payment SDK for partner businesses
[ ] Point-of-sale (POS) integration for physical service locations
[ ] Multi-language wallet support
[ ] Merchant onboarding campaign
[ ] Automated subscription and recurring payment smart contracts

Phase 5 — Maturity (2027+)

[ ] Enterprise-grade API tier for service integrations
[ ] Layer 2 scaling solutions if demand requires
[ ] Regulatory compliance framework
[ ] Global expansion to new markets and service sectors
[ ] Full governance decentralization
[ ] Self-sustaining validator ecosystem

14. Security

14.1 Network Security

Guraba's security is rooted in economic incentives and cryptographic guarantees:

Proof-of-Stake security: Attacking the network requires controlling 2/3 of all staked GRB. Even acquiring 1/3 of stake (enough to prevent finality) would cost an attacker a significant amount, and the attack would result in the attacker's stake being slashed.
Slashing deterrence: The risk of losing staked GRB creates a strong economic incentive for validators to behave honestly.
Geographic distribution: Validator nodes are distributed across multiple data centers and jurisdictions, preventing single points of failure.
Client diversity: While currently running Geth and Prysm, the long-term plan includes support for multiple client implementations to prevent single-client bugs from affecting the entire network.

14.2 Cryptographic Primitives

| Primitive | Algorithm | Usage | |---|---|---| | Account keys | secp256k1 (ECDSA) | Transaction signing | | Validator keys | BLS12-381 | Block proposals, attestations | | Hashing | Keccak-256 | State root, transaction hash | | Beacon state hash | SHA-256 | Beacon block root | | Key derivation | EIP-2333 / EIP-2334 | Validator key generation |

14.3 Smart Contract Security

Guraba benefits from Ethereum's battle-tested EVM, with known vulnerabilities well-documented.
Developers are encouraged to use audited libraries (OpenZeppelin) for standard functionality.
Guraba Inc. will publish security guidelines and best practices for contract development.
A bug bounty program will be established for responsible vulnerability disclosure.

14.4 Operational Security

Validator keys are stored in encrypted keystores with strong passwords.
Withdrawal credentials are set at deposit time and cannot be changed, preventing key compromise from resulting in fund theft.
RPC endpoints implement rate limiting and DDoS protection.
Admin operations require multi-signature authorization.

15. Risk Factors

Guraba Inc. believes in transparent communication. The following risks should be considered:

15.1 Technical Risks

Software bugs: Despite thorough testing, software may contain undiscovered bugs. Guraba Inc. maintains an incident response plan and will pursue independent security audits.
Network attacks: While economically impractical, sophisticated attacks on the consensus mechanism remain theoretically possible.
Scalability: If transaction volume exceeds current capacity, network fees may increase. Layer 2 solutions are planned for this scenario.

15.2 Economic Risks

Volatility: Like all cryptocurrencies, GRB's value may fluctuate significantly.
Adoption uncertainty: The success of GRB as a medium of exchange depends on merchant and user adoption, which is not guaranteed.
Competition: Other blockchain networks may offer similar or superior features.

15.3 Regulatory Risks

Legal uncertainty: Cryptocurrency regulation varies by jurisdiction and is evolving rapidly. Future regulations could affect GRB's usability in certain regions.
Compliance costs: Regulatory compliance may require significant resources.

16. Conclusion

Guraba Network represents a new chapter in blockchain technology — not as another speculative asset platform, but as a practical, purpose-built infrastructure for real-world economic activity. By combining Ethereum's proven technology stack with custom parameters optimized for accessibility, speed, and real utility, Guraba Inc. has created an ecosystem where GRB serves as a genuine medium of exchange.

What sets Guraba apart:

Service-backed value: GRB's value is tied to real services offered by Guraba Inc., not speculative trading.
Dollar independence — a self-contained economy where value is measured in GRB.
No DEX, no speculation — GRB is a utility token for purchasing services, not a trading instrument.
Low barriers to entry — 100 GRB minimum stake, standard hardware, full EVM compatibility.
Sustainable tokenomics — controlled inflation, EIP-1559 burns, and long-term vesting schedules.
A committed team at Guraba Inc. with a clear roadmap and transparent governance plans.

We invite validators, service partners, and users to join us in building a dollar-independent digital economy where cryptocurrency has real meaning.

The future of payments is not speculation. It is utility. It is Guraba.

17. References

Nakamoto, S. (2008). Bitcoin: A Peer-to-Peer Electronic Cash System.
Buterin, V. (2014). Ethereum: A Next-Generation Smart Contract and Decentralized Application Platform.
Buterin, V., et al. (2020). Combining GHOST and Casper.
EIP-1559: Fee market change for ETH 1.0 chain. Ethereum Improvement Proposals.
EIP-7251: Increase the MAX_EFFECTIVE_BALANCE. Ethereum Improvement Proposals.
EIP-2333: BLS12-381 Key Generation. Ethereum Improvement Proposals.
Boneh, D., Lynn, B., Shacham, H. (2001). Short Signatures from the Weil Pairing.

18. Legal Disclaimer

This whitepaper is published by Guraba Inc. for informational purposes only. It does not constitute financial advice, an investment recommendation, or a solicitation to purchase GRB tokens.

GRB tokens are a utility token designed for use within the Guraba Network ecosystem.
The value of GRB may fluctuate and holders may lose some or all of their investment.
This whitepaper contains forward-looking statements based on current plans and expectations. Actual results may differ materially.
Guraba Inc. reserves the right to update this whitepaper as the project evolves.
Participation in the Guraba Network is subject to applicable laws and regulations in the user's jurisdiction.

| Resource | URL | |---|---| | Website | https://guraba.io | | Block Explorer | https://scan.guraba.io | | RPC Endpoint | https://rpc.guraba.io | | Chain ID | 5502 |

Guraba — Building a dollar-independent digital economy.