Imagine you’re buying a coffee with Bitcoin. You tap your phone, then wait ten minutes for a confirmation, then pay a fee that costs more than the coffee. Nobody would call that a payment system.

Bitcoin was never designed to be fast. It was designed to be unbreakable. That choice made it the most secure and decentralized blockchain in the world, and it also left it with a speed limit.

Layer-2 networks are the industry’s answer: keep Bitcoin’s security, but move the everyday activity somewhere faster and cheaper.

The Problem: Security Has a Price

Bitcoin’s base layer processes only a handful of transactions per second. Blocks arrive roughly every ten minutes, and each block has limited space. When demand surges, users compete for that space by bidding up fees.

This isn’t a bug. It’s a trade-off. A slow, simple, conservative base layer is easy for thousands of independent nodes to verify, and that is what keeps Bitcoin decentralized.

So instead of making Bitcoin’s foundation faster, developers asked a different question: what if we build on top of it?

What Is a Layer-2, Really?

Think of Bitcoin as a high-security vault, and Layer-2s as the busy bank counters built around it. Customers do their everyday business at the counter, and the vault only gets involved for final settlement.

A Layer-2 network is a system that:

• Processes transactions off the main chain
• Periodically anchors or settles results back to Bitcoin
• Aims to inherit Bitcoin’s security to some degree
• Offers lower fees and faster confirmations

The word “to some degree” matters. Different Layer-2s make very different security promises, and we’ll come back to that.

The Main Players

1. The Lightning Network: The Payments Veteran

Lightning is the oldest and best-known Bitcoin Layer-2. Two users open a payment channel by locking Bitcoin in a shared on-chain transaction. They can then send each other payments back and forth, instantly and for tiny fees, without touching the blockchain each time. When they’re done, they close the channel and settle the final balance on-chain.

Even if you don’t have a direct channel with someone, payments can hop through other nodes on the network.

Best for: small, fast, frequent payments, such as tipping, remittances, and micropayments.

Limitations: channels need liquidity, routing can fail on large payments, and it’s built for payments rather than complex applications.

2. Sidechains: Independent Chains, Bitcoin-Pegged

Sidechains are separate blockchains with their own rules and validators. You move Bitcoin onto them through a peg and receive a Bitcoin-backed token to use there.

• Liquid Network focuses on fast settlement and confidential transactions, mainly for exchanges and traders.
• Rootstock (RSK) brings smart contracts to Bitcoin and is compatible with Ethereum-style tooling.

Best for: programmable finance and faster trading.

Trade-off: security depends largely on the sidechain’s own validators or federation, not purely on Bitcoin.

3. Stacks: Smart Contracts Anchored to Bitcoin

Stacks runs its own chain but records its activity on Bitcoin, tying its history to Bitcoin’s. Its Clarity smart-contract language is designed to be predictable and easy to audit. The goal is to let developers build apps, NFTs, and DeFi products connected to Bitcoin’s base layer.

4. Rollup-Style Designs and BitVM: The New Frontier

This is where things get interesting. Rollups, a model popularized on Ethereum, bundle many transactions together and post proofs of their correctness to the base layer.

Bitcoin can’t natively verify these proofs the way Ethereum can. Projects built around ideas like BitVM try to work around this by using clever cryptographic challenge-and-response mechanisms, so that dishonest behavior can be disputed on Bitcoin without changing its rules.

These designs are still maturing, but they represent the most ambitious attempt to give Bitcoin Ethereum-like programmability while preserving its security model.

Why Layer-2s Matter

The impact goes beyond cheaper coffee. Strong Layer-2s could unlock:

• Everyday payments: near-instant, low-cost transfers anywhere in the world
• Financial inclusion: cheap cross-border remittances for people who need them most
• Bitcoin-native DeFi: lending, trading, and savings without leaving the Bitcoin ecosystem
• Productive Bitcoin: BTC that earns yield or powers apps instead of sitting idle
• Developer growth: a new wave of builders attracted to the most trusted network in crypto

Bitcoin’s market value is enormous, but most of it simply sits still. Layer-2s are the infrastructure that could put some of that capital to work.

The Risks Nobody Should Ignore

A good story tells the whole truth, and Layer-2s come with real caveats:

• Security isn’t uniform. A federated sidechain is not the same as Lightning, and neither is the same as Bitcoin itself. Always ask: who can freeze, censor, or lose my funds?
• Bridges are attack targets. Moving assets between chains has been one of the most exploited areas in all of crypto.
• Complexity breeds bugs. Newer systems have had less time to be tested by real-world adversaries.
• Liquidity can fragment. Funds scattered across many networks can make the experience confusing and inefficient.
• User experience is still rough. Channel management, wallets, and bridging remain harder than they should be.

The healthy approach is curiosity paired with caution. Start small and read how the system actually works before trusting it with serious value.

How to Evaluate Any Bitcoin Layer-2

Before using one, ask these five questions:

1. Who controls the funds? Can you exit on your own, without anyone’s permission?
2. What secures the network? Bitcoin miners, a federation, or a separate validator set?
3. How does the peg work? Is it trust-minimized or custodial?
4. Has it been battle-tested? Look at its track record, audits, and time in production.
5. What happens if it fails? Is there a clear, on-chain path to recover your Bitcoin?

If the answers are vague, that tells you something too.

The Road Ahead

The Bitcoin community is famously cautious about changing the base protocol, and for good reason. That means Layer-2 progress will likely come from careful engineering rather than dramatic overhauls.

Watch for improvements in Lightning’s usability, better trust-minimized bridges, and ongoing debate about whether small protocol upgrades could make Layer-2s safer and simpler. The outcome will shape what Bitcoin becomes.

Final Thoughts

Bitcoin’s first chapter was about proving that decentralized digital money could exist. Its next chapter may be about proving it can be used, at scale, by ordinary people.

Layer-2 networks are the bridge between those two stories. They won’t all succeed, and some will fail along the way, but the best of them could let Bitcoin keep its unbreakable foundation while finally learning to move at the speed of everyday life.

The vault is built. Now the world is building the bank counters around it.

Bitcoin Layer-2 Networks: Giving the World’s Most Secure Blockchain a Second Gear was originally published in CoinsBench on Medium, where people are continuing the conversation by highlighting and responding to this story.

# How the $6.3B Binance Hack Proves Why Every Web3 Developer Needs Automated Security Tools

*The largest crypto heist in history wasn’t caused by a smart contract vulnerability. But the lessons it teaches should change how every Web3 developer writes code.*

## The $6.3 Billion Wake-Up Call

On October 29, 2026, the cryptocurrency world witnessed the largest hack in its history. Approximately **$6.36 billion** was stolen from Binance, the world’s largest crypto exchange, in a matter of minutes.

According to blockchain analytics firms Chainalysis and TRM Labs, the attack is attributed to North Korea’s Lazarus Group (also known as TraderTraitor). The attackers compromised a DevOps engineer’s laptop, which gave them the ability to authorize unauthorized withdrawals from Binance’s hot wallets across multiple blockchains.

Within 20–40 minutes, billions of dollars in crypto assets were moved to hacker-controlled wallets. Binance quickly responded, froze approximately $3 billion of the stolen funds, and pledged to cover all user losses from their own reserves.

**But here’s the critical insight that most analysts are missing:** This wasn’t a smart contract vulnerability. It wasn’t a reentrancy attack, a flash loan exploit, or a missing signature check. It was a **DevOps failure** — a compromised laptop, likely through phishing or weak authentication.

So why should smart contract developers care?

## The Illusion of “Not My Problem”

When a centralized exchange gets hacked through infrastructure compromise, many smart contract developers breathe a sigh of relief: *”Well, at least my Solidity code is safe.”*

This is a dangerous mindset.

The Binance hack reveals a fundamental truth about security in Web3: **attacks don’t respect boundaries**. The same threat actors (Lazarus Group, and others) who compromise exchange infrastructure are also actively hunting for vulnerabilities in smart contracts. The tools, techniques, and automation they use don’t care whether your vulnerability is in a laptop or a line of Solidity code.

More importantly, the **root cause** is often the same: **human error**.

- A DevOps engineer clicks a phishing link.
- A developer accidentally commits a hardcoded test key to production.
- A team forgets to verify signatures on a CEX integration.
- Someone pastes a full error log containing API keys into an AI chatbot at 6pm during a failing deploy.

The attack vector changes, but the underlying vulnerability — human fallibility — remains constant.

## Defense in Depth: The Only Real Strategy

The security industry has a term for this: **Defense in Depth**. It means you never rely on a single layer of protection. You build multiple, independent security barriers so that if one fails, others still stand.

For Binance, Defense in Depth would have looked like:
1. **Perimeter security**: Strong authentication, hardware keys, phishing-resistant MFA for all engineers.
2. **Network segmentation**: Hot wallets isolated from general corporate infrastructure.
3. **Transaction limits**: Automated caps on withdrawal amounts without multi-sig approval.
4. **Anomaly detection**: Real-time monitoring for unusual withdrawal patterns.
5. **Incident response**: Ability to freeze funds quickly (which they did, recovering ~$3B).

For smart contract developers, Defense in Depth looks like:
1. **Manual code review**: Experienced auditors reading every line.
2. **Automated static analysis**: Tools like Slither catching common patterns.
3. **Custom detectors**: Project-specific rules for your unique architecture.
4. **Formal verification**: Mathematical proofs for critical functions.
5. **Bug bounties**: Incentivizing external researchers to find what you missed.
6. **Monitoring**: Post-deployment alerts for suspicious on-chain activity.

**The key insight:** Automation isn’t a replacement for human expertise. It’s a **safety net** for when humans inevitably make mistakes.

## The Human Factor: Why Automation Is Non-Negotiable

Let’s be honest: developers are human. We get tired. We rush deployments at 6pm when production is on fire. We copy-paste code from Stack Overflow without fully understanding it. We hardcode test credentials “just for now” and forget to remove them.

This isn’t a criticism — it’s a fact of software engineering. And in Web3, where a single mistake can drain millions of dollars irreversibly, we can’t afford to rely solely on human diligence.

**Enter automated security tooling.**

Static analysis tools like Slither don’t get tired. They don’t rush deployments. They don’t forget to check for hardcoded credentials. They apply the same rigorous checks to every line of code, every time, without exception.

But here’s the problem: **generic tools catch generic vulnerabilities**. They’re great at finding reentrancy, integer overflows, and unchecked return values. But they don’t know about your specific architecture, your unique integrations, or the specific mistakes your team tends to make.

That’s where **custom detectors** come in.

## A Real-World Example: The $152K Mistake

Let me share a concrete example from my own work.

Recently, I was analyzing a Web3 project that had suffered a **$152,000 loss**. The root cause? A developer had accidentally left a **Hardhat test private key** in the production smart contract. This key, intended only for local testing, gave the attacker full control over critical functions.

The vulnerability sat in production for **months** before being exploited. Multiple developers had reviewed the code. Manual audits had been conducted. But no one caught the hardcoded test key buried in the constructor.

**Why?** Because humans are bad at finding patterns in large codebases. We skim. We assume. We miss things.

So I built a **custom Slither detector** that specifically searches for:
- Hardcoded Hardhat test addresses (like `0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266`)
- Plaintext API credentials in smart contracts
- Missing signature verification on CEX interface calls
- Constructor variables that look like test environment artifacts

The detector runs in seconds. It catches patterns that human reviewers miss. And it integrates directly into CI/CD pipelines, **blocking deployments** that contain these vulnerabilities.

**The result?** What took months to discover manually now takes milliseconds to catch automatically.

## The Binance Lesson: Automation at Every Layer

The $6.3B Binance hack should be a wake-up call for the entire Web3 industry. Not because smart contracts were vulnerable, but because **security cannot be siloed**.

If you’re a smart contract developer, here’s what you should take away:

### 1. Your code is only as strong as your weakest layer
Even if your Solidity is perfect, vulnerabilities in your deployment pipeline, CI/CD configuration, or developer workflows can undermine everything.

### 2. Automate the boring stuff
Hardcoded credentials, missing signature checks, unsafe external calls — these are pattern-based vulnerabilities. They’re perfect candidates for automated detection. Don’t waste human auditors’ time on what a script can catch.

### 3. Build custom detectors for your specific risks
Generic tools are a starting point, not the finish line. Every project has unique architecture, unique integrations, and unique risks. Invest time in building custom detectors that understand your specific threat model.

### 4. Integrate security into CI/CD, not as an afterthought
Security checks should run on every pull request, not just before major releases. Make it impossible to deploy vulnerable code by blocking merges that fail security checks.

### 5. Assume human error will happen
Design your systems to be resilient to mistakes. Use multi-sig for critical operations. Implement transaction limits. Add automated monitoring. And yes — run static analysis on every commit.

## Practical Steps: Getting Started with Custom Slither Detectors

If you’re convinced that automated security tooling is essential (and after a $6.3B hack, you should be), here’s how to get started:

### Step 1: Install Slither

pip install slither-analyzer
Step 2: Run existing detectors

slither your_contract.sol
This will catch common vulnerabilities like reentrancy, unchecked calls, and more.
Step 3: Identify your project-specific risks
Ask yourself:
What integrations does my contract have? (CEX APIs, oracles, bridges)
What patterns are unique to my architecture?
What mistakes has my team made in the past?
Step 4: Build custom detectors
Slither’s Python API makes it straightforward to write custom detectors. Here’s a simplified example:

from slither.detectors.abstract_detector import AbstractDetector, DetectorClassification

class HardcodedTestKeys(AbstractDetector):
ARGUMENT = ‘hardcoded-test-keys’
HELP = ‘Detect hardcoded Hardhat test addresses’
IMPACT = DetectorClassification.HIGH
CONFIDENCE = DetectorClassification.HIGH

def _detect(self):
results = []
# Known Hardhat test addresses
test_keys = [
‘0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266’,
‘0x70997970C51812dc3A010C7d01b50e0d17dc79C8’,
# … more test keys
]

for contract in self.compilation_unit.contracts:
for func in contract.functions:
for node in func.nodes:
for var in node.state_variables_read:
if var.name in test_keys:
info = [f”Hardcoded test key in {func.name}\n”]
res = self.generate_result(info)
res.add(node)
results.append(res)
return results
Step 5: Integrate into CI/CD
Add Slither to your GitHub Actions, GitLab CI, or any pipeline:

- name: Run Slither
run: |
pip install slither-analyzer
slither . — detect hardcoded-test-keys,cex-interface-security
The Future: AI-Assisted Security
The Binance hack was executed by sophisticated actors using advanced automation. The defense must evolve accordingly.
We’re already seeing the emergence of AI-assisted security tools — systems that can:
Analyze code patterns and suggest potential vulnerabilities
Generate custom detectors based on project architecture
Monitor on-chain activity and flag anomalies in real-time
Correlate off-chain threat intelligence with on-chain behavior
Companies like Consensys Diligence are already investing heavily in AI-assisted auditing tools. The future of Web3 security isn’t human vs. machine — it’s human + machine, working together to create systems that are resilient to both technical vulnerabilities and human error.
Conclusion: The $6.3B Lesson
The Binance hack will be studied for years. Analysts will dissect the attack chain, the response, the recovery. But for smart contract developers, the lesson is simpler:
Security is not optional. Automation is not optional. Defense in Depth is not optional.
The attackers are sophisticated, well-funded, and relentless. They don’t care whether your vulnerability is in a laptop or a smart contract. They’ll exploit whatever they find.
Your job as a Web3 developer is to make it as hard as possible for them to succeed. That means:
Writing secure code
Reviewing code thoroughly
Automating security checks
Building custom detectors for your specific risks
Integrating security into every layer of your development process
The $6.3B hack is a tragedy. But if it pushes the industry to take automated security seriously, it might also be a turning point.
Don’t wait for your own $152K mistake to start building custom detectors. Start today.
If you found this article useful, check out my open-source Slither detector project on GitHub: https://github.com/rdin777/slither-cex-detector.
It includes detectors for hardcoded test keys, CEX interface vulnerabilities, and more. Contributions and feedback welcome!
Follow me for more Web3 security insights and practical guides on building automated security tools.

How the $6.3B Binance Hack Proves Why Every Web3 Developer Needs Automated Security Tools was originally published in CoinsBench on Medium, where people are continuing the conversation by highlighting and responding to this story.

Picture this. It’s Sunday night, and you tell your phone: “Find me running shoes under $120, size 9, delivered by Friday.” You go back to your show. Twenty minutes later, the shoes are bought. You never opened a store, typed a card number, or tapped “Pay.”

That is agentic commerce: AI agents that don’t just recommend products but search, compare, decide, and pay on your behalf. For fintech founders, it is the biggest shift in how money moves since the smartphone checkout button. And the window to build in it is open right now.

Why This Is Different From Every Other Payments Trend

Every payments system built so far assumes a human is on the other side. Fraud engines look for human behavior. Checkout pages rely on human attention. Authentication depends on a human’s thumb, face, or one-time code.

Agents break all three assumptions. A software agent browses at machine speed, never gets distracted by banner ads, and doesn’t have a thumb. Suddenly, the old rails need a new layer built for delegation.

The big players have noticed. In 2025 alone:

• Visa launched Intelligent Commerce, letting AI agents transact using tokenized credentials.
• Mastercard introduced Agent Pay, built around agent-specific tokens.
• Stripe and OpenAI published the Agentic Commerce Protocol for buying inside chat.
• Google unveiled the Agent Payments Protocol (AP2), focused on verifiable user authorization.

When incumbents publish protocols, they are telling you the plumbing matters. But protocols are only the skeleton. Someone has to build the products on top.

The Four Problems Waiting for a Founder

Talk to people building in this space and the same four gaps keep surfacing:

• Identity and trust. How does a merchant know an agent really represents a verified customer? Think “know your agent” alongside know your customer.
• Authorization and limits. Users need guardrails: spend caps, approved merchants, time windows, and a clear kill switch. Delegation without control is just risk.
• Fraud and disputes. If an agent buys the wrong item, who is liable: the user, the agent developer, the merchant, or the bank? Nobody has settled this.
• Merchant readiness. Most stores are designed for human eyes. Product data, pricing, and inventory must become machine-readable, or agents will skip them.

Each gap is a company waiting to be built. Think of the early days of online payments: someone had to invent the gateway, the fraud scorecard, and the checkout button before e-commerce could scale. The same trio of invisible infrastructure is needed again.

What Smart Fintech Founders Are Doing Differently

The founders gaining traction are not chasing the flashiest demo. They are making quiet, practical choices:

• Building on open protocols. Betting on one closed ecosystem is dangerous when standards are still forming. Interoperability wins.
• Starting narrow. Instead of “agents that buy anything,” they pick one vertical, such as travel, groceries, or B2B procurement, and own it.
• Designing for consent first. Every transaction carries a clear, auditable record of what the user approved.
• Talking to regulators early. Compliance in a world of autonomous payments is unwritten territory. Founders who help shape it avoid painful surprises.

Notice the pattern. Trust, not intelligence, is the real product. Anyone can wire a language model to a payment API in a weekend. Very few can convince a bank, a merchant, and a nervous customer that the transaction is safe.

Where Agentic Commerce Shows Up First

Early adoption clusters around repeat, rules-based spending:

• Travel: agents re-book flights when prices drop or plans change.
• Groceries and household items: automatic reordering within a monthly budget.
• Business procurement: agents compare suppliers and raise purchase orders for approval.
• Subscriptions: agents cancel unused services and negotiate better plans.

Each use case shares three traits: clear rules, low emotional stakes, and measurable savings. That makes them ideal proving grounds. Win here, build a track record, and then expand toward bigger, riskier purchases like electronics or financial products.

Merchants Face a New Kind of Customer

For merchants, the shift is just as big. Search engine optimization taught brands to write for algorithms. Agent optimization goes further: structured product feeds, accurate stock levels, transparent returns, and prices an agent can verify in milliseconds.

Brand loyalty also changes. If an agent picks the best deal every time, emotional branding matters less and reliability matters more. Merchants who deliver on time, honor returns, and keep data clean will win agent recommendations. Fintech founders can sell the tools that make this possible: payment orchestration, product-data validation, and agent-aware analytics.

The Risks Nobody Should Ignore

Optimism needs a reality check. Agentic commerce carries real dangers that founders must treat seriously:

• Prompt injection. A malicious web page can trick an agent into sending money somewhere it shouldn’t.
• Runaway spending. Without hard limits, a misinterpreted instruction can repeat at machine speed.
• Opaque decisions. If users can’t see why an agent chose a product, trust erodes fast.
• Hidden bias. Agents may favor merchants that pay for placement, quietly turning “assistant” into “advertiser.”

These aren’t reasons to wait. They are product requirements. Every risk above is also a startup idea: agent security, spend controls, explainability dashboards, and audit tooling.

A Practical Playbook for the Next 12 Months

If you are a founder, or thinking about becoming one, here is a simple path:

1. Pick one painful workflow. Look for repetitive purchases where humans waste hours, like reordering supplies or comparing insurance quotes.
2. Prototype with sandbox tools. Use existing protocols and test environments before touching real money.
3. Add guardrails on day one. Spend limits, confirmations for large purchases, and clear logs are features, not extras.
4. Partner with one merchant and one bank. Real integrations teach more than a hundred pitch decks.
5. Measure trust, not just volume. Track approval rates, reversals, and how often users override the agent.

The Bottom Line

Every major commerce shift created a new class of winners. The web gave us marketplaces. Mobile gave us super-apps. Agents will give us something stranger: markets where software negotiates with software, and humans only set the goals.

The founders who thrive will not be the ones with the cleverest agents. They will be the ones who make delegation feel safe: clear identity, firm limits, honest records, and fair outcomes. Build the trust layer, and the rest follows.

So the next time you tell your phone to buy something, remember: someone had to build the rails that made that sentence safe to say. Maybe that someone is you.

Your Next Customer Won’t Have a Wallet was originally published in CoinsBench on Medium, where people are continuing the conversation by highlighting and responding to this story.

Part of the series — “Snail On A Slope”

Introduction

Jesus famously expelled the money-changers, borrowers, lenders and all kinds of merchants from the temple, but what if he couldn’t? Logically, if you can’t beat them — join them, but what if rewarding them turned out to be impossible too?

A classic lending protocol allows suppliers to invest tokens into a pool and borrowers to take tokens out of that pool against a collateral that they have previously supplied, meanwhile keeping and calculating a borrow index to keep the mechanism balanced. Liquidations happen when the borrowed amount of a user exceeds the limit, set to the borrowing power of his collateral (say 75%).

All this lending, borrowing and liquidating happens with a simple restriction, it is on one chain only. What we are going to look at today is a cross chain lending (dummy) protocol that lets users supply collateral on chain A, which will be the guarantee, and take debt on chain B, which will be sent to the user on B. All this usually happens via LayerZero, which we have simplified to keep the focus on the bug, we are about to explore.

Understanding the Protocol

Our dummy protocol consists of five contracts and four of them are deployed once per chain:

• MarketPool
• LedgerStorage
• HomeRouter
• BridgeRouter
• MockEndpoint

For simplicity there is only one asset that the protocol works with — USDC (in e18 on both chains) and it is priced at $1 so no oracle is needed. Redeem and liquidate functions are not implemented for the dummy protocol as they are not relevant for the problem we are going to discuss. Lastly, the MockEndpoint is a very simplified LayerZero substitute so that we can simulate cross chain messaging.

The MarketPool is the pool of a chain, which holds its liquidity and tracks the total borrow (principal). This principal is updated with a borrow index, which grows with time.

The LedgerStorage keeps track of users’ collateral, single and cross chain debt. Worth noting here is that cross chain debt leaves two records in two mappings. A funds request from chain A saves the requested funds amount in outboundLoans and when these funds are paid to the user on chain B, a debt record is saved for the amount in foreignBackedLoans on chain B. Both these mappings live inside LedgerStorage.

The HomeRouter is the contract for same chain operations like supply, borrow and repay and is responsible for the moving of the funds for cross chain borrows.

Finally, the BridgeRouter is the entry point for initiating cross chain borrows and repays as well as the cross chain messaging.

Looking at the code can be a bit confusing at first but when we follow the chain of execution it becomes clear:

Alice (chain A)
|
| supply() — 10 000 USDC collateral giving 7500 borrowing power (75%)
|
-> HomeRouter (chain A)

Alice (chain A)
|
| startRemoteBorrow() — 5000 USDC on B
|
-> BridgeRouter (chain A)
|
| OpenRemoteBorrow message via send()
|
-> MockEndpoint
|
| _onOpenRemoteBorrow()
|
-> BridgeRouter (chain B)
|
| payOutRemoteBorrow()
|
-> HomeRouter (chain B)
|
| release() — 5000 USDC on B is tranferred to Alice (wallet on B)
|
-> MarketPool (chain B)
|
| returns to HomeRouter, which returns to _ onOpenRemoteBorrow()
|
-> BridgeRouter (chain B)
|
| Saves amount: 5000 to foreignBackedLoans mapping and
| BorrowConfirmed message via send()
|
-> MockEndpoint
|
| _onBorrowConfirmed()
|
-> BridgeRouter (chain A)
|
| save amount: 5000 to outboundLoans mapping
|
-> End

Alice has 10 000 tokens as collateral on chain A, 5000 tokens as debt on chain B. Chain B has foreignBackedLoans record of the 5000 and Chain A has outboundLoans record of the 5000. Now let’s follow the repayment, which has to happen in reverse:

Alice (chain B)
|
| repayRemoteBorrow() — 5000
|
-> BridgeRouter (chain B)
|
| takeRemoteRepayment() — 5000 tokens are taken from Alice
|
-> HomeRouter (chain B)
|
| returns to repayRemoteBorrow()
|
-> BridgeRouter (chain B)
|
| Reduces/removes amount: 5000 from foreignBackedLoans mapping and
| RepayNotice message via send()
|
-> MockEndpoint
|
| _onRepayNotice()
|
-> BridgeRouter (chain A)
|
| Reduces/removes amount: 5000 from outboundLoans mapping
|
-> End

Now, after a more clear understanding of the dummy protocol I can list a few things that are simplified and may cause confusion in the code:

• Every contract on chain A has a twin brother on chain B, the code knows which one it is by comparing with currentEid
• Two records are kept — outboundLoans & foreignBackedLoans — so that a user only has a record in one of those on one chain, that way the contract knows on which side of the loan this chain stands
• srcEid and destEid are fixed per loan and show the collateral side and funds side. When collateral is on chain A — srcEid is chain A — therefore funds are taken on chain B — destEid, logically, is chain B
• crossChainDebt() function doesn’t allow a user to have both mappings populated, a simplification on our part, so no user can have cross chain loans on both chains (in both directions)
• The borrow index is transferred with the loan data but each chain calculates the debt with its own index. This works in the dummy protocol because both markets on both chains have the same rate and start time.

Anatomy Of The First Attack — Money-changers can’t be expelled

Sorry to disappoint, but there is no actual attack here, it is more of an implementation bug. When there is a cross chain borrow, as it is shown in the example above, the repayment has to be processed on the chain, which gave the funds — chain B in our example. The repayment process looks up the debts of the user, as HomeRouter calls the internal _debtToRepay():

    function _debtToRepay(
        address borrower,
        address market,
        bool isSameChain
    ) internal view virtual returns (uint256) {
        return
            isSameChain
                ? ledger.sameChainDebt(borrower, market)
                : ledger.crossChainDebt(borrower, market);
    }

The HomeRouter has no way to know what kind of debt the user is repaying so it asks the right question to the storage based on the isSameChain boolean.

For a cross chain borrow, as it is for Alice’s case, the call lands on the crossChainDebt() in the ledger, which calculates the debt from the point of view of chain B:

function crossChainDebt(
        address borrower,
        address market
    ) public view virtual returns (uint256) {
        ...
        if (outbound.length > 0) {
            for (uint256 i = 0; i < outbound.length; i++) {
                if (outbound[i].srcEid == currentEid) {
                    borrowedAmount +=
                        (outbound[i].principal * index) /
                        outbound[i].borrowIndex;
                }
            }
        } else {
            for (uint256 i = 0; i < foreign.length; i++) {
                // count the record only when both the collateral chain and the funds chain are this one
                if (
                    foreign[i].destEid == currentEid &&
                    foreign[i].srcEid == currentEid
                ) {
                    borrowedAmount +=
                        (foreign[i].principal * index) /
                        foreign[i].borrowIndex;
                }
            }
        }
        return borrowedAmount;
    }

The first branch, if(outbound.length > 0), works as expected, it calculates the debt that originated from collateral on the current chain, so srcEid has to be the currentEid. But the second branch, else, which runs when Alice wants to repay debt cross chain debt on chain B backed by collateral on chain A, fails. The branch loops the foreignBackedLoans mapping records and searches for one that has a srcEid and destEid equal to the currentEid, but a cross chain loan by definition has as source one chain and as destination another. Alice repays currently on chain B so destEid matches the currentEid but srcEid is chain A. In this way the loop runs and rejects all the cross chain borrows, returning 0 as the borrowedAmount, which later reverts in HomeRouter as the code says that there is no borrowed money to repay.

The sequence of the bug:

• LPs have supplied liquidity on both chains A and B
• Alice supplies $10 000 on chain A
• Alice calls BridgeRouter.startRemoteBorrow() on chain A for $5000 and receives $5000 on chain B
• 30 days pass with interest sitting at 5% a year so her debt becomes ~$5020
• Alice calls BridgeRouter.repayRemoteBorrow() on chain B for the full $5020 amount
• The call reverts with “Borrowed amount is 0”

There is no possible path for success here as repaying the exact amount, repaying with type(uint256).max, repaying in portions or somebody else repaying on her behalf, all revert. The problem is not the whole function, for debt originating from the current chain crossChainDebt() answers perfectly the question “how much debt did this person initiate from this chain”. The bug is that the same function was reused to answer a different question — “how much was taken out of the pool” — and that question is about the foreignBackedLoans mapping, so it doesn’t really care where the collateral is, therefore no need for srcEid check.

The real cost here is that when the cross chain debt can’t be repaid, it will surely get liquidated, in a real protocol, somewhere along the way and the person who has taken the debt will suffer losses on his collateral that he did not deserve.

Conclusion of Part I

Not every protocol exposes a cool way to be exploited and it is not needed. Big problems lurk in small mistakes, the devil is in the details, as they say. Many times protocols specify invariants that should always hold but developers, and people in general, think in ways that usually have hidden assumptions that they themselves do not realize. Exactly identifying these unconscious mistakes is as rewarding and cool as writing a big exploit contract and attacking. In this part we saw how the money-changers can’t be expelled and in the next we are going to see why they can’t be rewarded either. Stay tuned!

Full dummy protocol code & tests can be found at:

MediumArticlesCodeExamples/SnailOnASlope/moneyChangers at master · BozhidarBonev/MediumArticlesCodeExamples

SOAS V1 — The money-changers who can neither be expelled from temple nor rewarded: Part 1 was originally published in CoinsBench on Medium, where people are continuing the conversation by highlighting and responding to this story.

The largest crypto theft on record, explained: how the wallets were drained, what got frozen, and what didn’t.

On October 29, 2026, an attacker moved about $6.36 billion out of Binance wallets on ten blockchains, according to TRM Labs. Chainalysis puts the total at $6.4 billion, Binance at about $6.3 billion. Most of it left in roughly 20 minutes starting at 20:05 UTC, with a second wave on Avalanche and Polygon around 23:05. Both analytics firms call it the largest crypto theft on record, and TRM puts it at roughly four times the Bybit hack.

How the wallets were drained

A hot wallet is an internet-connected wallet an exchange uses to process withdrawals. On Ethereum, the attacker used EIP-7702, which lets an ordinary wallet hand its behavior to a smart contract by signing an authorization. The arrangement stays until a new one replaces it.

TRM reports one transaction carrying 50 authorizations signed by a Binance hot wallet, each pointing to a sweeper contract that obeyed only the attacker. An authorization works only at the wallet’s current transaction count, and a busy hot wallet’s count keeps moving. Signing 50 consecutive counts guaranteed one would match.

But EIP-7702 was the delivery method on Ethereum, not the root cause. On the other nine chains, funds left through ordinary signed transfers, which led TRM to assess that Binance’s hot wallet signing infrastructure was compromised. Binance’s preliminary findings point to a compromised engineer’s laptop, with further breach points found since. It says it found no evidence of a leaked private key and that the delegation bypassed its normal approval controls. A full post-mortem is pending.

The freeze race

Stablecoin issuers can blacklist their own tokens. Tether froze 971.1 million USDT in the main receiving wallet at 21:01 UTC, 37 minutes after the main sweep. Circle froze 823 million USDC three minutes later. Ripple, World Liberty Financial and Arbitrum’s Security Council added more. Totals depend on the snapshot: about $2.7 billion (TRM, October 30 at 00:30 UTC), $2.8 billion (Chainalysis) and $3 billion (Binance).

The attacker raced the freezes. TRM traced about 325 million USDT sold to market makers through UniswapX and other intent-based contracts for roughly 122,300 ETH, a discount of more than 10% to market. Another wallet deposited 60 million USDT on Aave and borrowed about 19,760 ETH. Chainalysis also saw $500 million in stablecoins sent to a wallet built to swap freezable assets into non-freezable ones. In my assessment, accepting that discount suggests speed mattered.

As of TRM’s October 30 snapshot, the attacker held more than 420,000 ETH and 18,270 BTC, about $2.4 billion. No issuer can freeze those. That doesn’t make them immune to seizure or exchange-level action, so disruption now depends on tracing and on where the funds exit.

Who did it

TRM attributes the attack to North Korea’s TraderTraitor with high confidence, citing on-chain and off-chain intelligence plus features shared with the Bybit hack: Tornado Cash funding the operator wallet, staging at least 36 hours earlier, and signatures prepared in advance. Chainalysis points to a separate on-chain observation: stolen Binance funds commingled with proceeds of last month’s Bitget theft, already attributed to North Korea. These are private-sector assessments, not official attribution, and Binance hasn’t confirmed the attacker’s identity.

The laundering looks new. TRM notes market-maker swaps and lending protocols, unlike the bridge-heavy pattern after Bybit. Chainalysis sees thousands of rapid transactions, many through addresses that receive exactly 1 TRX first, which suggests automation.

What compliance teams should watch

TRM expects funds from a Bitcoin peel chain (repeated splitting into smaller pieces) and the ETH consolidation wallets to reach exchanges, swap services and OTC desks. Screening labeled addresses is the baseline. My takeaway is that most exposure will arrive indirectly, through intermediate hops. TRM also advises treasury teams to alert on any unexpected EIP-7702 delegation on a hot wallet.

Replenished is not recovered

Binance says it has set aside more than $6.34 billion in company funds and that it had replaced about 95% of the stolen assets by November 1, up from 90% the day before, using its corporate treasury, part of its futures insurance fund and its SAFU reserve. It says the remaining 5% is in less liquid tokens outside the top ten, which take longer to source. It has also taken a Proof of Reserves snapshot dated October 31, with the full zero-knowledge proof expected by November 3. Binance said phase one of withdrawals would resume on November 1 between 06:00 and 09:00 UTC. That is financial cover for users, not recovery of the stolen crypto. The ledger makes movement visible. It doesn’t make assets reversible.

Written November 1, 2026. TRM figures are as of October 30 and Binance figures as of November 1. On-chain estimates are still moving.

Sources:

• TRM Labs: https://www.trmlabs.com/resources/blog/north-korea-steals-usd-6-36-billion-from-binance-in-the-largest-hack-in-history
• Chainalysis: https://www.chainalysis.com/blog/binance-exploit-latest-findings-and-response/
• Cointelegraph live coverage (Binance statements, Arbitrum freeze): https://cointelegraph.com/news/live-updates-binance-63b-hack-linked-to-north-koreas-tradertraitor
• CoinDesk (Binance says 90% replaced): https://www.coindesk.com/business/2026/10/31/binance-says-it-has-replaced-90-of-stolen-crypto-after-massive-usd6-3-billion-breach
• Bloomberg (phased withdrawals): https://www.bloomberg.com/news/articles/2026-11-01/binance-to-resume-customer-withdrawals-in-phases-after-hack
• Binance, Security Incident Update #3 (90% replenished, Proof of Reserves): https://x.com/binance/status/2116538196259684457
• Binance, Security Incident Update #4 (95% replenished, phased withdrawals): https://x.com/binance/status/2116744986096292263

Binance Lost $6.3B. The Harder Question Is Who Can Still Move What’s Left was originally published in CoinsBench on Medium, where people are continuing the conversation by highlighting and responding to this story.

A decade ago many believed cryptocurrency would be the tool for hiding illegal money. It seemed anonymous, borderless and beyond the reach of banks. That made it a nightmare for compliance officers.

Reality turned out to be much different. Bitcoin, Ethereum and most major blockchains are not truly anonymous. They are pseudonymous. Every transaction is recorded on a ledger that anyone can view. For investigators this is not a weakness. It is an advantage.

Blockchain analytics is the practice that turns this data into useful information. It helps answer questions: Who moved the money? Where did it come from? Where is it going?

What Is Blockchain Analytics?

Blockchain analytics means collecting organizing and understanding data from blockchain transactions. It takes on-chain records and turns them into insights.

Analysts don’t read bank statements. They read transaction graphs. They use software to group wallet addresses that likely belong to the person or business. Then they label those groups using real-world information — like exchanges, mixers, illegal marketplaces or sanctioned organizations.

Why Traditional AML Falls Short

Traditional anti-money laundering systems were built for banks. They depend on customer identity, account history and fixed rules.. Crypto breaks all of those assumptions.

• Wallets can be made in seconds without any identity check.
• Funds move across borders in minutes.
• Value can jump between blockchains and tokens in seconds..
• Decentralized services have no central office to question.

Legacy systems see the points where crypto meets fiat. Everything in between is invisible. Blockchain analytics fills that gap.

The Core Techniques

1. Address Clustering

This uses rules like the common-input-ownership heuristic. It groups addresses that likely belong to the person. A thousand wallets can become one entity.

2. Entity Attribution and Labeling

Clusters are linked to known services and risk types. Knowing a wallet belongs to an exchange or a sanctioned mixer changes the whole picture.

3. Transaction Tracing

Analysts follow money from one transaction to the next. They go forward and backward to see where funds came from and where they are going.

4.. Risk Scoring

Each wallet or transaction gets a score based on how it is linked to harmful activity.

5. Behavioral Pattern Detection

Machine learning tools spot money laundering behaviors.

Red Flags Analytics Can Detect:

• Peeling chains: large amounts split into small transfers to hide the source.
• Chain hopping: moving assets across chains or bridges to break the trail.
• Tumbler use: blending funds with others to obscure ownership.
• Structuring: sending small transfers to avoid reporting rules.
• Rapid pass-through: receiving and forwarding funds within minutes with no purpose.
• Sanctioned or high-risk exposure: direct or indirect links to banned addresses.

How an Investigation Unfolds

A typical case follows five steps:

• Alert: a transaction or wallet crosses a risk threshold.
• Trace: analysts map the flow of money across hops and services.
• Attribute: clusters are linked to known entities and risk types.
• Assess: the team reviews the context, customer profile and transaction purpose.
• Act: clear the alert ask for details or file a suspicious activity report.

Each step is recorded. This creates an audit trail that regulators expect.

A Simple Example

Imagine an exchange gets a deposit of 50 ETH from a customer. On the surface nothing seems wrong.. Blockchain analytics shows the sending wallet got the funds three steps back from a group linked to a ransomware attack.

Without analytics the exchange would have credited the account. With it the deposit is flagged. The account is frozen. A suspicious activity report goes to the financial intelligence unit. A possible compliance failure becomes a documented success. From deposit to alert: seconds, not weeks.

Where It Fits in a Compliance Program

Blockchain analytics does not replace compliance programs. It strengthens them.

1. Customer onboarding: screen wallet addresses before approving users.
2. Transaction monitoring: get real-time alerts on outgoing transfers.
3. Investigations: visualize fund flows for case files and law enforcement.
4. Travel Rule compliance: support information sharing between asset service providers.
5. Regulatory reporting: create audit- evidence of due diligence.

Global standards from the Financial Action Task Force now classify asset service providers as obligated entities. Regulators in countries expect crypto businesses to monitor activity risk-based.

Why It Matters Beyond Compliance

Blockchain analytics is not about corporate risk. It is now key to public interest work.

Law enforcement uses on-chain tracing to support seizures tied to ransomware, fraud and sanctions evasion. Victims can sometimes see where their money went.

Because the ledger is permanent evidence does not disappear. A trail from years ago can still be followed today. That changes the risk for anyone thinking about using crypto for purposes.

Limitations Worth Knowing

No tool is perfect. Honest compliance means seeing the limits.

1. False positives: clustering tools work on probability not proof.
2. Privacy coins and tools: Monero and others resist tracing.
3. Cross-chain complexity: bridges and wrapped assets make analysis harder.
4. Off-chain activity: analytics cannot see cash deals or private trades.
5. Privacy concerns: monitoring data raises ethical questions.

The best programs use analytics with judgment solid KYC and clear escalation paths.

What Comes Next

The field is changing fast. Things to expect:

• AI-driven detection that adapts to laundering methods.
• Cross-chain tracing that follows value across networks.
• Better coverage of DeFi, NFTs and stablecoins.
• Closer teamwork between analytics firms, exchanges and law enforcement.

Key Takeaways

• Blockchains are pseudonymous and traceable not anonymous.
• Analytics turns data into risk intelligence.
• It complements, not replaces, KYC and human judgment.
• Regulators increasingly expect it from crypto businesses.

Final Thoughts

The promise of crypto was transparency without trusting intermediaries. Ironically that same transparency makes it traceable. Criminals who think the blockchain is a hiding place often find out it is a witness.

For compliance professionals the message is clear: understanding blockchain analytics is no longer optional. It is the foundation of AML in a digital asset world.

If you work in fintech, compliance or crypto start by asking one question: Could we trace a dollar through three hops today? If the answer is no you know where to begin.

Following the Money on a Public Ledger: How Blockchain Analytics Is Reshaping AML was originally published in CoinsBench on Medium, where people are continuing the conversation by highlighting and responding to this story.

Do you have any questions for us?”

Most blockchain developers treat this as a formality. They ask about the tech stack, the roadmap, maybe token allocation. Then they say thanks and hang up.

Hiring managers notice. In Web3, one bad deployment can drain a protocol, and they’re listening for whether you understand that. Your last question is often the one they remember.

We recently ran a discussion on ArtofBlockchain where a developer asked a simple question: which one or two closing questions actually make an interviewer think, “this person gets blockchain work beyond code”?

The answers came from people who hire for L1, L2, rollup, and DeFi teams, and they were sharper than we expected. Here’s one.

The question that changed the whole interview

A member interviewing for an EVM protocol role skipped the usual architecture questions. He asked how a hotfix or emergency pause would actually get approved mid-sprint. Who signs the multisig, and where in the world are they?

The engineering lead paused and then answered honestly. Their signers were spread across three continents, with no on-call rotation. In a real emergency, the response could stall for hours.

The conversation changed after that. They stopped talking about textbook design and started talking about how the protocol really runs day to day. The candidate came across as someone who thinks about production, not just code. He also learned something important about on-call stress on that team before any offer was on the table.

Why this works

A good closing question works two ways. It shows the interviewer how you think, and the answer tells you how mature the team really is. A team that can explain clearly who owns risk after deployment is a very different job from a team whose answer is “we move fast.”

That’s one question. There are more.

The thread has others that hiring managers specifically called out, including:

• The question most candidates skip, even though it matters most for DeFi and bridge roles
• A slightly uncomfortable question that gets teams to tell you what really worries them
• A simple question whose answer shows whether a team has dealt with real production risk or is still reactive
• How to choose your question depending on whether it’s a security-heavy, protocol-ops or early-stage startup role

👉 Read the full discussion on ArtofBlockchain: Top Questions to Ask Interviewers in a Web3 Job Interview

If you’ve got a Web3 interview coming up, it takes five minutes to read and could change how your next one ends.

If you have a question that worked for you, add it to the thread. That’s how this list keeps getting better.

Stop Asking “What’s the Tech Stack?” at the End of Your Blockchain Interview was originally published in CoinsBench on Medium, where people are continuing the conversation by highlighting and responding to this story.

A contract goes live after an audit. The audit checked the code on one day. From then on, the contract changes owner, gets upgraded, moves money and talks to bots, and somebody has to notice when one of those things is not supposed to happen.

Most small teams notice from users, from a block explorer tab left open, or from a post on X. SmartAlert is a monitor for that gap: you paste a contract address, and it tells your team in Telegram, Slack or Discord when something on the contract is off.

This post covers what it watches, and then takes a contract from “nobody is watching” to working alerts in about five minutes.

What it watches

SmartAlert reads public chain data on Ethereum, BNB Chain, Base and Arbitrum. It does not touch your contract and needs no code change.

- Admin changes. Ownership transferred, a role granted or revoked, a proxy upgraded, the proxy admin changed, Safe owners or threshold changed, the contract paused. These are the first on-chain signs of most takeovers.
- Money, in dollars. A transfer above $X, priced at the block and optionally filtered by sender. The total value of a treasury below a floor, including when a price drop crosses it. Prices come from Chainlink, with CoinGecko as a fallback.
- Operations. A keeper or relayer wallet with gas for fewer than N days. A balance that is low and got no top-up in an hour. Failed transactions from your bots.
- Activity. Any event count or value per hour: transfers, swaps, deposits, claims. Spikes, and a contract that suddenly goes quiet.
- State. Values read through view functions, such as paused() returning true.

Two things keep the alerts useful:

- A norm for each hour. Activity on most contracts is low at night and high during the day. One fixed threshold is either noisy at peak hours or silent at night. SmartAlert can compare each hour with the same hour on previous days instead, so a burst at 3 a.m. is caught and a busy afternoon is not an alert.
- A check on history before a rule runs. Every rule shows, on a chart of the contract’s real past, where it would have fired. If it would have fired forty times last month, you see that before it wakes anyone up.

Setup

You need a contract address on one of the four networks and a Telegram account. The free plan is enough; the first 14 days of a project work with Pro limits.

Step 1. Add the contract (1 minute)

1. Sign up and create a project.
2. Choose Add contract, pick the network and paste the address.
3. For a verified contract, the ABI is loaded for you. For an unverified one, paste the ABI.

If SmartAlert has not seen the contract before, it first collects its history. The contract shows a “backfilling” status, and rules wait until it is done. If the contract is already tracked, its history is there at once.

Step 2. Turn on the first rules (2 minutes)

Open the contract. SmartAlert suggests rules from its ABI: ERC-20, ERC-721 and ERC-1967 proxies get matching templates. Select the ones that fit and choose Enable selected.

If you are not sure what to start with, these six cover the most common ways a contract gets taken over or drained:

• Ownership transferred. A new owner can call every admin function. Setting: Any event, Critical.
• Role granted. A new admin on an AccessControl contract. Setting: Any event, Critical.
• Proxy upgraded. The code behind the address changed. Setting: Any event, Critical.
• Transfer above $X. The drain itself, priced at the block. Setting: from = your contract, a threshold above normal flow.
• Unusual transfer activity. Bursts that a fixed number misses at night. Setting: Against the norm for each hour.
• Contract went quiet. A broken integration or a stuck bot. Setting: Against the norm for each hour.

If you run keepers or relayers, add their wallets and a gas runway rule. For a treasury, add its address and a total below $X rule.

Step 3. Check each rule on history (1 minute)

Open a rule and look at the chart. It shows the metric, the norm or your threshold, and marks where the rule would have fired.

- Admin rules should show zero or a few marks, each one a change you remember making.
- For value and activity rules, too many marks means the threshold is too low. Raise it, or set a target such as “no more than 2 a week” and let SmartAlert pick the threshold.

Use against the norm for each hour (the default) for activity, and own threshold for amounts in dollars and admin events.

Step 4. Connect Telegram (1 minute)

1. Open Channels, enter a name and press Add.
2. Open the link SmartAlert gives you and press Start in the bot. For a team chat, add the bot to the group and run the command there.
3. The bot replies with the project name. The channel is active.

The link works for 15 minutes. On Pro you can also add Slack, Discord, email, PagerDuty or a webhook.

What an alert looks like

The message has the value, the threshold or this hour’s norm, the time and a link to the transaction. When the condition clears, a “Back to normal” message follows, and PagerDuty incidents close on their own.

What it does not do

- It does not pause or block anything. It alerts. Send Critical alerts to people who hold a pause key; an alert that reaches nobody who can act is a log entry.
- It does not read the mempool. It reads confirmed blocks. On Ethereum that is 12 confirmations, about 144 seconds, then a rule check: every 5 minutes on Free, every minute on Pro, every 30 seconds on Business. If an attacker drains a contract within two minutes of the first sign, the first loss is gone before any confirmed-block monitor can speak. Later steps of the same attack are not.
- It does not replace an audit. It is the part that notices.

Two more habits:

- Repeat on every chain you are deployed on. Attackers often go chain by chain, and the first chain’s alert is the warning for the others.
- Watch contracts you depend on, not only your own. A locker, a bridge or a vault that holds your tokens is public, and you can watch it without anyone’s permission.

Next

- Alert recipes
- Post-audit monitoring checklist
- How to monitor an upgradeable proxy

*I build SmartAlert. Questions about a specific contract are welcome in the comments.*

Smart contract monitoring in 5 minutes: what to watch and how to set it up was originally published in CoinsBench on Medium, where people are continuing the conversation by highlighting and responding to this story.