Skip to content

Igniter Staking Flow (v1)

Jump to bottom
Julio Henriquez edited this page Jun 29, 2025 · 6 revisions

Igniter Staking Flow - System Overview

📢 Transition Notice

This document describes the v1 architecture of the Igniter staking flow, used from its initial concept through June 2025.

As of July 2025, a new architecture (v2) is being developed to accommodate for changes introduced in the Shannon protocol upgrade.

You are viewing the soon to be deprecated v1 flow. For the latest architecture, visit 👉 Igniter Staking Flow (v2).

A complete summary of changes and rationale is available in 👉 Architecture Evolution.

🎯 Purpose

Enable end users to easily stake POKT using a web dapp, with key provisioning and node configuration handled by Providers. The system coordinates the lifecycle of a transaction from preparation to on-chain verification.

🧩 Key Components

🔹 End User

  • Interacts via the StakeIgniter Web Dapp.
  • Signs transactions using the Soothe Wallet Extension.

🔹 Stake Igniter

  • Web-based dapp used to:

    • Select amount and provider.
    • Orchestrate transaction creation.
    • Request keys and metadata from Providers.

  • Includes Automated workflows that:

    • Periodically checks for pending transactions.
    • Broadcasts and verifies transactions via RPC.

  • Stores signed transactions (without private keys).

🔹 Provider

  • Offers node key generation and services configuration.

  • Exposes API endpoints to:

    • Generate new wallet keys (node keys).
    • Include service metadata (e.g., per-service revenue share).

  • Stores generated keys in a dedicated database. (Private keys encrypted)

  • Allows exporting these generated in a relay miner friendly format

🔹 RPC / REST

  • Interface to the Pocket Network for:

    • Broadcasting transactions.
    • Querying transaction status.

🔹 Databases

  • Transactions DB (Igniter):

    • Stores signed transactions and metadata.

  • Keys DB (Provider):

    • Stores generated or imported node keys.

🔄 End-to-End Flow

1. Initiation

  • User selects stake on the home page of the Igniter web DApp
  • Selects the desired owner address for this stake (if connected with multiple accounts)
  • Selects amount to stake.
  • Chooses from a list of available providers.

2. Provider Interaction

  • Igniter DApp calls the user selected Provider:

    • Generates new node wallet keys.
    • Configures supplier metadata (services and revenue share).
    • Stores keys in the Provider's DB.
    • Returns keys and service info.

3. Transaction Preparation

  • Igniter uses the supplied keys and metadata to prepare the staking transaction.
  • Prompts user to sign transaction using the Soothe Wallet Extension.
  • Signed transaction is stored in the Transactions DB.

4. Broadcast and Verification

  • A periodic workflow in the Igniter companion worker picks up pending transactions.
  • Broadcasts transaction to the blockchain via RPC.
  • Queries the blockchain for at least 1 block after the submission (~30s).
  • Once confirmed, marks transaction as Success or Failure.

⚙️ Provider Configuration

  • Each Provider can:

    • Pre-configure supported services.
    • Assign revenue share percentages.
    • Manage node keys (currently new per request, but importable in the future).

  • Providers operate independently, allowing the Igniter to support multiple providers.

🧠 Notes and Future Considerations

  • Key generation is currently non-deterministic (new wallets).
  • Future updates will allow manual key management by providers.
  • System is designed for asynchronous processing, decoupling signature and broadcast phases.
  • Transaction integrity and timing is maintained via workflows.

📌 Diagram Reference

image

✅ Summary

This architecture allows staking of POKT to be modular, provider-extensible, and fault-tolerant through the use of workflows, signed transaction persistence, and periodic verification.

Clone this wiki locally