Cronos POS Chain Docs
  • Getting Started
    • 📑Cronos POS Chain Introduction
    • 🔰Architecture
  • For USERS
    • 🌟New brand and domains
    • 💰Wallets
      • chain-maind
      • Ledger Hardware Wallets with chain-maind
      • Crypto.com DeFi Desktop Wallet
      • Conducting IBC Transfer with Keplr Wallet
      • Using Ledger Device with Keplr Wallet
      • Mainnet Address Generation
      • Mainnet Address Verification
      • Multisig Account
      • Delegation Guide
      • Key Principles for Wallet Security
    • 🛠️Token Migration Web Tool
    • 🚰Croeseid Testnet Faucet
  • For Node Hosts
    • ⛓️Running Nodes
      • Public Node Sync
      • Quicksync
      • Cronos POS Chain Mainnet: Running a Full Node
        • Upgrade Guide
          • The "V5" upgrade guide (v4.* to v5.0.1) :
          • The "V4" upgrade guide (v3.* to v4.2.2) :
          • The "DRACO II" upgrade guide (v2.* to v3.3.2) :
          • The "Canis Major" upgrade guide (v1.* to v2.0.1) at block height 922,363:
          • Running "Canis Major" network upgrade with cosmovisor
      • Cronos POS Chain Mainnet: Running a Validator
      • Cronos POS Chain Mainnet Validator Security Checklist
      • Croeseid Testnet: Running Nodes
      • Mainnet/Testnet: Running Nodes using AWS 1-click Deployment
      • Mainnet/Testnet: Running Nodes using Azure 1-click Deployment
      • Croeseid Testnet: Running Nodes With Nix
      • Devnet: Running Latest Development Node
    • 🔄Advanced TMKMS Integration
    • 💫Notes on Performance
    • 🔃Notes on Production Deployment
  • Block Explorers
    • 📊Cronos POS Chain Mainnet Explorer
    • 📊Croeseid Testnet Explorer
  • Cronos PoS Chain Protocol
    • ⛓️Chain Details
      • Genesis
      • Protocol Documentation
      • Chain ID, Address Format and Signatures
      • Create the IBC-enabled tokens on the Cronos POS Chain with Solo Machine
      • List of parameters
      • Proposal Process
      • Technical glossary
    • 🎛️Modules
      • module_supply
      • module_slashing
      • module_authz
      • module_bank
      • module_mint
      • module_gov
      • module_staking
      • module_distribution
      • module_nft
  • Cronos PoS Integration
    • 🔄Integration documentation
    • 🛂Node Setup and RPC node
    • 🔲Blocks and Transactions
Powered by GitBook
On this page
  • Cronos POS Chain
  • Design Goals
  1. Getting Started

Cronos POS Chain Introduction

What is Cronos POS Chain and its design goals?

The development of blockchain technology and cryptocurrencies represents a cryptography and security breakthrough as significant as that created by the internet in the 1990s. This technology, however, is still at a very nascent stage; in order to generate mass adoption, it will therefore be necessary to find compelling real-life use cases that can appeal to an audience larger than the small group of industry professionals and experts.

Cronos POS Chain

Accordingly, we propose Cronos POS Chain, the next-generation public blockchain that enables transactions worldwide between people and businesses. It is also the technology that powers Crypto.com Pay, mobile payment solution, and will be used to power our trading & financial services offerings in the near future.

We believe enabling cryptocurrency spending in the real world will be an adoption catalyst. Current traditional payment institutions and existing blockchains have failed to provide a secure, scalable and decentralized solution to support cryptocurrency payment. The key limitations of existing blockchain-powered payment networks are that they are:

  • Too complex to setup and use;

  • Not friendly to crypto first-timers; and

  • Rarely supported beyond their own blockchain;

Design Goals

On the technical side, Cronos POS Chain has the following design goals:

  1. "Security": robust and well-understood primitives and implementation are favoured

  2. "Scalability": parts that hinder overall latency, throughput, lightweight client support, etc. should be mitigated

  3. "Multi-party": the system should permit multi-party operation; anything that puts trust in a single party should be opt-in

  4. "Long-term operation": there needs to be a leeway for backward- and forwards-compatibility etc.

  5. "Developer ecosystem": external developers can easily work with Chain, regardless of their used programming language; better support for DeFi use cases, e.g., support cross-chain asset transfers and communications.

NextArchitecture

Last updated 10 months ago

📑
Page cover image