THORCHAIN 

⭐ FIRST — THE CORE PROBLEM THORCHAIN SOLVES

Normally, you cannot swap native BTC for native ETH directly.

Why?

Because:

• Bitcoin runs on the Bitcoin chain

• Ethereum runs on the Ethereum chain

• They don't talk to each other

• They have different consensus

• No smart contracts on Bitcoin

So everyone traditionally uses:

❌ Wrapped tokens (WBTC, WETH)
❌ Central exchanges (Binance)
❌ Bridges (which get hacked often)

THORChain fixes this WITHOUT wrapping and WITHOUT trusting a bridge.

---

⭐ SECOND — WHAT IS THORCHAIN?

It is a cross-chain AMM built on its own blockchain (Cosmos Tendermint-based).

It connects multiple chains and allows:

✔ Native BTC → Native ETH
✔ Native ETH → Native BNB
✔ Native ATOM → Native BTC
✔ etc.

NO wrapping.
NO centralized custody.
NO external oracles.

Everything is handled by THORChain nodes and vaults.

---

⭐ THIRD — HOW DOES THORCHAIN CONNECT MULTIPLE CHAINS?

This is the magic:

THORChain nodes run full nodes of every supported blockchain.

Meaning:

THORChain validator = runs:

• Full Bitcoin node

• Full Ethereum node

• Full Binance Chain node

• Full Litecoin node

• Full Dogecoin node

• Full Bitcoin Cash node

• Full Cosmos node

Each validator monitors ALL chains directly — no oracles.

This is why THORChain is sometimes called:

“A decentralized Binance.”

---

⭐ FOURTH — KEY COMPONENT: Threshold Signature Vaults (TSS)

This is the secret technology that makes native swaps possible.

✔ Validators together control multi-chain vaults

✔ Vault is a multi-signature wallet (Threshold Signature Scheme)
✔ No single node can seize funds
✔ Funds move ONLY when majority signs
✔ Vault exists on each blockchain (BTC, ETH, BNB, etc.)

Example:

• Bitcoin Vault = BTC address controlled by THORChain validators

• Ethereum Vault = ETH address controlled by THORChain validators

Users send native assets to these vaults.

---

⭐ FIFTH — HOW NATIVE SWAPS ACTUALLY WORK (Step-by-Step)

Let’s say you want to swap:

Native BTC → Native ETH

Process:

---

STEP 1: User sends BTC to Bitcoin Vault

THORChain validator nodes see this deposit through their Bitcoin full node.

They agree:

User deposited 0.1 BTC.

---

STEP 2: THORChain network updates AMM pool

THORChain has pools like:

• BTC/RUNE

• ETH/RUNE

• BNB/RUNE

• ATOM/RUNE

Why RUNE?

Because THORChain uses:

RUNE as the settlement asset
Just like how Uniswap uses ETH.

Swap path is always:

BTC → RUNE → ETH

But this is internal.
User does NOT receive RUNE.

---

STEP 3: THORChain executes AMM swap logic

Using the internal AMM (similar to Uniswap x*y=k), THORChain computes:

0.1 BTC = X amount of RUNE
X amount of RUNE = Y amount of ETH

---

STEP 4: THORChain nodes instruct ETH Vault to send ETH to user

Validators sign a TSS transaction on Ethereum:

Send Y ETH → user’s Ethereum address

User receives native ETH, not a wrapped version.

---

Final Result:

User deposits real BTC →
THORChain AMM swaps via RUNE →
User receives real ETH

NO wrapping.
NO bridging.
NO CEX.
NO custodians.

This is the genius of THORChain.

---

⭐ SIXTH — HOW SECURITY IS ACHIEVED?

✔ Vault uses threshold signatures

No single validator controls funds.

✔ Validators bonded with RUNE

Attack requires > ⅔ validators to collude.
Attacker must stake billions of dollars of RUNE.

✔ If attack detected → slash validator

Stolen funds compensated from validator bonds.

This design makes attacking THORChain extremely expensive.

---

⭐ SEVENTH — WHY RUNE IS REQUIRED?

Because RUNE provides:

✔ Incentives (fees, rewards)

✔ Security (validators bond RUNE)

✔ Settlement (every pool is RUNE-based)

✔ Pricing (keeps pools deep and unified)

Without RUNE, native cross-chain swaps would not be possible.

---

⭐ EIGHTH — WHY THORCHAIN IS NOT A BRIDGE

Bridges do:

• lock tokens

• mint wrapped tokens

• rely on a small multisig

• risky & hack-prone

THORChain does:

• deposit native tokens

• swap internally

• release native tokens

• vault controlled by decentralized nodes

• no wrapping

• no synthetic tokens

It is a decentralized cross-chain market maker.

---

⭐ NINTH — SIMPLE VISUAL EXPLANATION

[BTC Vault] <- deposit BTC 
     |
     v
THORChain AMM  (BTC <-> RUNE <-> ETH)
     |
     v
[ETH Vault] -> send ETH to user

Everything is executed on-chain, verified by THORChain nodes.

---

⭐ TENTH — SUMMARY (SUPER CLEAR)

✔ THORChain nodes run full nodes of all blockchains

✔ They control cross-chain vaults using threshold signatures

✔ User deposits native coin → vault receives it

✔ THORChain AMM executes swap internally

✔ Other vault sends out native destination coin

✔ No wrapping, no bridging, no CEX, no oracles

This is how THORChain enables:

• BTC → ETH

• ETH → BNB

• ATOM → BTC

• LTC → ETH

natively, trustlessly, and decentralized.

⭐ 1. WHAT IS A VAULT IN CODE? (IMPORTANT)

A THORChain vault is NOT a smart contract
and NOT an account inside THORChain's own chain.

It is simply:

✔ A MULTI-CHAIN WALLET ADDRESS

controlled by
✔ THORChain validator nodes
using
✔ Threshold Signature Scheme (TSS)

Vault is PURELY OFF-CHAIN on each chain

but managed by THORChain consensus ON-CHAIN.

Example vaults:

• Bitcoin vault = a Bitcoin address

• Ethereum vault = an Ethereum address

• BNB vault = a Binance Chain address

But the private key is never held by one person.
It is split across validators using TSS key shares.

---

⭐ 2. HOW IS VAULT CREATED IN CODE?

Step A — THORNodes perform a TSS Keygen

This happens inside:

bifrost/tss/

They run:

key-share generation ceremony

Where:

• No node knows the full private key

• Only partial key shares

• Signature requires >⅔ of nodes

• Based on GG18 or GG20 TSS protocols

---

Step B — The public key generated becomes the “Vault Address”

On Bitcoin:

public key → P2WSH address

On Ethereum:

public key → ETH address (0x...)

In code this is stored in THORChain state:

type Vault struct {
    PubKey       string
    Chain        string  // BTC, ETH, BNB, etc.
    Coins        []Coin
    Status       Active/InActive
    Membership   []ValidatorAddress
}

This is stored on THORChain’s blockchain (Cosmos SDK).

---

⭐ 3. HOW USER SENDS BTC TO THE VAULT (REAL FLOW)

User deposits:

0.1 BTC → Bitcoin Vault Address

This is a normal Bitcoin transaction.

THORChain nodes see it because THEY RUN FULL BTC NODES.

Node software called Bifrost monitors BTC chain.

Code piece:

bifrost/pkg/chainclients/bitcoin/

The BTC client watches for:

• UTXOs sent to vault address

• Confirmations

• Block height

When detected, it sends an inbound event to THORChain:

msg = MsgObservedTxIn{
    TxHash: "0xabc...",
    FromAddress: "vault address",
    ToAddress: "THORChain inbound address",
    Chain: "BTC",
    Amount: 0.1 BTC,
    Memo: "SWAP:ETH:0xUser"
}

This is broadcast into THORChain’s blockchain.

---

⭐ 4. HOW THORCHAIN PROCESSES THE DEPOSIT

Inside THORChain:

x/thorchain/handler_observed_txin.go

When the inbound is confirmed by threshold of validator observers:

✔ THORChain marks deposit as valid
✔ Parses memo (e.g., SWAP:ETH:0xUser)
✔ Looks up pool (BTC/RUNE pool)
✔ Runs AMM swap logic

---

⭐ 5. INTERNAL AMM SWAP IN CODE (BTC → RUNE → ETH)

Swap logic in THORChain is similar to x*y=k of Uniswap but with different mathematics.

Code:

x/thorchain/keeper/pool.go

The swap is ALWAYS:

BTC → RUNE → ETH

AMM calculate:

• slip fee

• network fee

• pool fee

• output amount

Result:

User should receive Y ETH

This is recorded on THORChain chain.

---

⭐ 6. HOW THORCHAIN TELLS ETH VAULT TO SEND ETH?

Now THORChain issues an outbound instruction:

MsgOutboundTx{
   Chain: "ETH",
   ToAddress: user_ETH_address,
   Amount: Y ETH,
   Memo: "OUT:SWAP",
}

This message is committed to the THORChain blockchain.

Nodes see this message and ETH nodes execute the send.

---

⭐ 7. HOW ETH VAULT SENDS ETH (CODE PATH)

ETH vault is controlled by:

• TSS public key (Ethereum address)

• Validators holding TSS key shares

Validator software Bifrost ETH client monitors outbound instructions.

Code:

bifrost/pkg/chainclients/ethereum/

Steps:

(1) Bifrost sees new outbound instruction:

OUT: Send Y ETH to user

(2) It creates an Ethereum transaction (unsigned)

tx = {
  to: user_address,
  value: Y ETH,
  data: ...,
  gas: ...
}

(3) TSS signing process (MULTI-NODE)

Nodes run a distributed signing protocol:

tss.Sign(tx_hash)

This requires threshold of validators (e.g., 67% nodes).

No single validator knows full private key.

They collaborate to produce ONE valid ECDSA signature.

(4) Bifrost broadcasts transaction to Ethereum network

Ethereum network confirms it →
User receives native ETH.

---

⭐ 8. HOW THORCHAIN KNOWS ETH WAS SENT?

• Bifrost ETH client watches ETH chain

• Detects outbound tx matching instruction

• Reports success to THORChain

• THORChain marks swap as completed

---

⭐ 9. SUMMARY OF UNDER-THE-HOOD FLOW (SUPER CLEAR)

🟠 Inbound

User sends BTC → BTC vault (address controlled by TSS)
THORNodes detect it → THORChain blockchain processes swap

🔵 Internal Swap

THORChain AMM swaps BTC→RUNE→ETH inside its own chain
No wrapping
No bridge

🟢 Outbound

THORChain instructs ETH vault → TSS nodes sign ETH tx → User receives native ETH

---

⭐ 10. VISUAL CODE-LEVEL ARCHITECTURE

User: send BTC
    ↓
BTC Full Node (inside THORNodes)
    ↓  ObservedTxIn
THORChain Blockchain (Cosmos)
    ↓  Swap in AMM (x*y=k)
Outbound Tx Instruction
    ↓
ETH Bifrost Client
    ↓ TSS Signature
ETH Full Node
    ↓
User receives native ETH

---

⭐ 11. WHERE THE MAGIC LIVES IN CODE

🔹 Vault structure

x/thorchain/types/vault.go

🔹 Inbound Tx processing

x/thorchain/handler_observed_txin.go

🔹 Swap logic

x/thorchain/keeper/pool.go

🔹 Outbound instruction

x/thorchain/keeper/outbound.go

🔹 Bifrost cross-chain clients

bifrost/pkg/chainclients/bitcoin/
bifrost/pkg/chainclients/ethereum/
bifrost/pkg/chainclients/binance/
bifrost/pkg/chainclients/litecoin/

🔹 TSS Signing

bifrost/tss/

This is EXACTLY how THORChain works under the hood.