Kaon
  • INTRODUCTION
    • What is Kaon?
    • Why Kaon?
    • Who Should Use Kaon?
    • Who Should Build On Kaon?
    • How Does it Work?
    • Terminology
  • QUICKSTART
    • Getting Started
    • 5-Minute Setup
    • Hello KAON!
  • CORE CONCEPTS
    • Fundamentals Overview
      • Unifying Bitcoin and Ethereum(EVM)
    • Cross-Chain Interactions
      • Bridge-less Token Transfers
      • Oracle-less Cross-chain Message
      • Cross-Chain Transaction Management
      • Gasless Operating Process
      • Bridge-less ERC cross-chain Transfers
    • BTC Transaction Lifecycle
      • BTC Locking and Mirroring
      • BTC Withdrawal
    • EVM Integrations
      • mirrorBTC and EVM Interactions
      • mirrorBTC Transfer To EVM Chain
      • Restore mirrorBTC From Wrap Process
      • Metamask and other Offchain EVM Wallets Support
    • Consensus Mechanisms
      • Kaon Chain Consensus (dPoS)
      • Cross-Chain BFT Consensus
      • Slashing Incidence Process
    • Key Innovations
  • NETWORK & TOOLS
    • Kaon Testnet
    • Kaon CLI
    • Network and Tools
  • GUIDES & TUTORIALS
    • Creating a Time-Locked Bitcoin Vault
Powered by GitBook
On this page
  1. CORE CONCEPTS
  2. EVM Integrations

mirrorBTC and EVM Interactions

PreviousEVM IntegrationsNextmirrorBTC Transfer To EVM Chain

Last updated 6 months ago

It is crucial to understand the unique properties of mirrorBTC (mBTC), it is basically dual-record token, where BRC standard token part keep transaction records for specific tokens, while ERC metadata facilitates interaction with EVM smart contracts.\

  1. The user sends mirrorBTC to a designated smart contract.

  2. The transaction first enters the BRC20 section, where the mirrorBTC verifies its data and balance.

  3. After verification, the transaction transitions to the EVM state.

  4. Predefined ERC token metadata is injected at this stage.

  5. The EVM state executes its standard methods, which are masked calls to the BRC/EVM processor that actually handles the responses.

  6. This forms EVM state updates, including updates to the EVM store and the transactions Merkle Tree.

  7. After verification by the BRC/ERC processor, the state updates produce UTXO sub-transactions, which are submitted to the mempool (essentially, they are appended to the end of the block during its composition).

  8. Once the block is verified and accepted locally, it is spread across the entire blockchain network using an inventory system.