🧵THORChain is about to speed up $BTC deposits by 33%
(without compromising decentralization, of course)

Here’s everything you need to know about the proposal to reduce $BTC confirmations from 3 to 2⚡️

With 13 more votes to go, it’s all in the hands of Chads now

🔹Currently, THORChain waits for 3 Bitcoin confirmations before crediting deposits, and that’s ~30 mins before $BTC becomes usable for swaps or LP.

A new proposal aims to bring that down to 2 confirmations - a 33% latency cut.

This isn’t just a minor tweak. In a real-time trading environment, 10 minutes of saved latency can unlock huge capital efficiency for:
Arbitrage bots
High-frequency trades
Dynamic liquidity provision

🔹So why was it 3 in the first place?
When THORChain launched $BTC integration, conservative assumptions guided parameter design.

3 confirmations = reduced risk of a re-org wiping out an inbound deposit before it’s fully secured.

But the industry has evolved since then, and so have standards!

Today, major CEXs like Binance, Coinbase, and Kraken all operate with 2 $BTC confirmations.
They process billions in $BTC daily and have found that 2 confs = secure enough.

Sticking with 3 confirmations puts @THORChain out of sync with industry norms.
That mismatch introduces unnecessary friction for users who expect a 2-conf timeline, especially traders moving capital between venues.

🔹A reduced threshold would:
Speed up the entire swap lifecycle
Make THORChain more competitive in volatile markets
Align pricing across pools more rapidly via arbitrage
Better UX = more usage = stronger liquidity loops.
What about the risk?

The main concern is Bitcoin chain reorganizations - where a block is dropped and replaced by a longer chain, reversing transactions.
This is why confirmations exist in the first place.
But here's the data-backed reality:

🔹 1-block re-orgs are rare
🔹 2-block re-orgs are extremely rare
🔹 Bitcoin has among the strongest finality guarantees of any Layer 1
This isn’t reckless.

If conditions change and re-org risk increases, the confirmation setting can be reverted immediately through Mimir governance.

🔒Security isn’t sacrificed - it’s recalibrated for maturity

🔹Let’s talk governance
THORChain uses a decentralized parameter system called Mimir.
No code changes. No dev sign-off.

1. Node operators directly vote on parameters by submitting: make mimir MAXCONFIRMATIONS-BTC --> 2
2. Votes needed for quorum: 74
3. Votes secured so far: 61
4. Remaining: 13
With 110 validators, momentum is strong and the proposal is close to passing🔥

Check out the live tracker here: https://t.co/6e7j22eE4V

🔹What about the technical outcomes if the proposal passes?
$BTC deposits will clear ~10 minutes faster
Swaps involving $BTC will initiate more quickly
Arbitrage loops will tighten, increasing market efficiency

🔹And the behavioral outcomes:

1. Users will favor THORChain over slower DEXs
2. $BTC trading volumes likely to rise
3. Easier and faster liquidity provisioning
4. Improved competitive positioning vs CEXs
5. This also benefits arbitrage bots directly.

With faster deposit finality, bots can capture tighter windows, sync prices across chains faster, and reduce stale pricing across THORChain pools.

All of this improves capital flow for everyone.

🔹And for larger traders?
A 10-minute delay can mean missed market entries, reduced edge, or slower rotations.
Cutting that delay makes THORChain a more viable venue for bigger BTC-based trade

To sum it up, this proposal is:

✅A low-risk, high-impact refinement
✅A speed boost without sacrificing decentralization
✅An optimization made possible by governance maturity

THORChain isn’t cutting corners!

It’s tuning the engine, bringing protocol latency in line with how the market actually operates, while keeping risk in check.

This is what operational maturity looks like.
Will it go live? It’s in your hands, chads!