How can you copy and paste a crypto address, and still send your money to a stranger? It is a real trick, it is called address poisoning, and it works without hacking anything. Here is the mechanism, step by step.
First, the basics. A crypto address is like an account number. It is a long string of letters and numbers, for example starting with 0x on Ethereum. Wallets usually show it shortened, like 0x4f2a...9c1d, so you only see the first and last few characters.
Here is how the trick works.
1. The scammer watches the public blockchain, where every transfer is visible to anyone. They see that your address has sent money to a certain address.
2. They generate a new address that begins and ends with the same few characters as the real one. The middle is different.
3. They send you a tiny or zero-value transfer from that lookalike address. Now it sits in your transaction history, right next to the real one.
4. Later you want to pay the same person again. You open your history, copy what looks like the right address, and send.
Nothing was hacked. You just copied the wrong line. Crypto transfers cannot be reversed, so there is no undo button.
The habit that stops it: never copy an address from your transaction history. Get it from the source you trust, such as the person's own message, and compare the whole address, not just the start and end
How can you copy and paste a crypto address, and still send your money to a stranger? It is a real trick, it is called address poisoning, and it works without hacking anything. Here is the mechanism, step by step.
First, the basics. A crypto address is like an account number. It is a long string of letters and numbers, for example starting with 0x on Ethereum. Wallets usually show it shortened, like 0x4f2a...9c1d, so you only see the first and last few characters.
Here is how the trick works.
1. The scammer watches the public blockchain, where every transfer is visible to anyone. They see that your address has sent money to a certain address.
2. They generate a new address that begins and ends with the same few characters as the real one. The middle is different.
3. They send you a tiny or zero-value transfer from that lookalike address. Now it sits in your transaction history, right next to the real one.
4. Later you want to pay the same person again. You open your history, copy what looks like the right address, and send.
Nothing was hacked. You just copied the wrong line. Crypto transfers cannot be reversed, so there is no undo button.
The habit that stops it: never copy an address from your transaction history. Get it from the source you trust, such as the person's own message, and compare the whole address, not just the start and end
Binance could make users whole because it has a balance sheet. Code doesn't have one.
Binance says it covered about 95% of a $6.3 billion loss from its own funds: its SAFU reserve, a futures insurance fund and its corporate treasury. Tether and Circle froze more than $2.3 billion of assets tied to the incident.
That's what a company can do after a hack: pay from a balance sheet, and lean on issuers who can freeze funds.
Now ask the same questions about the DeFi protocols you use:
1. Is there a balance sheet, an insurance fund or a freeze switch behind it?
2. If not, what stops a bad change or a stolen key before it happens?
3. Can you check that yourself, in public?
Number 3 is the one you can answer today. Example: Compound's USDC market on Ethereum has had its code swapped 60 times since 2022. The admin contract that can approve a swap is owned by a timelock with a 48 hour delay, and the timelock answers to Compound's governance contract. Anyone can check it on Etherscan.
Reply with a protocol and we'll look up who can upgrade it, and post what we find
How to check it yourself, Compound USDC example:
Etherscan, the proxy 0xc3d688B66703497DAA19211EEdff47f25384cdc3. Events tab, filter for Upgraded: 61 entries, the first one is the deployment.
The admin is stored in a fixed storage slot. It points to 0x1ec63b5883c3481134fd50d5daebc83ecd2e8779, which is owned by the timelock 0x6d903f6003cca6255d85cca4d3b5e5146dc33925. delay() on the timelock returns 172800 seconds. That's 48 hours
Binance could make users whole because it has a balance sheet. Code doesn't have one.
Binance says it covered about 95% of a $6.3 billion loss from its own funds: its SAFU reserve, a futures insurance fund and its corporate treasury. Tether and Circle froze more than $2.3 billion of assets tied to the incident.
That's what a company can do after a hack: pay from a balance sheet, and lean on issuers who can freeze funds.
Now ask the same questions about the DeFi protocols you use:
1. Is there a balance sheet, an insurance fund or a freeze switch behind it?
2. If not, what stops a bad change or a stolen key before it happens?
3. Can you check that yourself, in public?
Number 3 is the one you can answer today. Example: Compound's USDC market on Ethereum has had its code swapped 60 times since 2022. The admin contract that can approve a swap is owned by a timelock with a 48 hour delay, and the timelock answers to Compound's governance contract. Anyone can check it on Etherscan.
Reply with a protocol and we'll look up who can upgrade it, and post what we find
@cahyorom@dev3pack@solana Rust on Solana is a great way to learn. Signer and account validation checks are worth drilling early, good luck with the bootcamp
@call_him_sudais@dantegaleazzi@X Escrow for ride bookings is a good use case. Dispute and refund paths are where those contracts usually get tricky, would love to see how you design it
@IamWeal12644247 Dalasi and Naira rails on stablecoins is a real need. Good luck with the launch, the rate source and the off ramp flow are the parts I'd be curious about
@Launchrfi Good luck with the launch tomorrow. Bonding curves plus holder rewards is a fun design space, curious how the curve math handles rounding at the edges
What is EIP-7702, and why is it in the Binance hack story?
Binance says the attackers bypassed its normal approval controls. About $6.3 billion moved anyway.
Here's what has been reported so far:
- Binance said it was dealing with a "complex attack" affecting around $6.3 billion. Early reports said $5.8 billion.
- Co-CEO Richard Teng said the attackers used EIP-7702 to gain on-chain execution authority over a hot wallet, bypassing Binance's normal approval controls.
- He said multiple people were involved, and that the attackers built self-destruct mechanisms that erased their tools and traces.
- Tether froze more than $1.5 billion in USDT and Circle more than $800 million in USDC tied to the incident.
- The FBI has tied the attack to North Korea's TraderTraitor group. Binance says it covered about 95% of the loss from its own funds and has started resuming withdrawals.
EIP-7702 is an Ethereum feature that lets an ordinary wallet hand its actions over to smart contract code. It's useful. It also means the rules about who can trigger those actions matter a lot.
The full technical root cause isn't public yet, and anyone claiming certainty this early is guessing. But the question it raises is already clear:
An approval control only works if nobody can route around it.
So for anything that holds your money, exchange or DeFi, ask three things:
1. Who can move it, or change the code that holds it?
2. What approval or delay has to happen first?
3. Can you check that yourself, in public?
On-chain, you often can. Example: Compound's USDC market on Ethereum. Its upgrade admin is owned by a timelock with a 48 hour delay, and the timelock answers to Compound's governance contract. Anyone can verify that on Etherscan. It doesn't make anything unbreakable. It makes the rule readable.
At Shieldara we audit smart contracts. If you're building something that holds other people's money and want a second pair of eyes before you ship, our DMs are open
What is EIP-7702, and why is it in the Binance hack story?
Binance says the attackers bypassed its normal approval controls. About $6.3 billion moved anyway.
Here's what has been reported so far:
- Binance said it was dealing with a "complex attack" affecting around $6.3 billion. Early reports said $5.8 billion.
- Co-CEO Richard Teng said the attackers used EIP-7702 to gain on-chain execution authority over a hot wallet, bypassing Binance's normal approval controls.
- He said multiple people were involved, and that the attackers built self-destruct mechanisms that erased their tools and traces.
- Tether froze more than $1.5 billion in USDT and Circle more than $800 million in USDC tied to the incident.
- The FBI has tied the attack to North Korea's TraderTraitor group. Binance says it covered about 95% of the loss from its own funds and has started resuming withdrawals.
EIP-7702 is an Ethereum feature that lets an ordinary wallet hand its actions over to smart contract code. It's useful. It also means the rules about who can trigger those actions matter a lot.
The full technical root cause isn't public yet, and anyone claiming certainty this early is guessing. But the question it raises is already clear:
An approval control only works if nobody can route around it.
So for anything that holds your money, exchange or DeFi, ask three things:
1. Who can move it, or change the code that holds it?
2. What approval or delay has to happen first?
3. Can you check that yourself, in public?
On-chain, you often can. Example: Compound's USDC market on Ethereum. Its upgrade admin is owned by a timelock with a 48 hour delay, and the timelock answers to Compound's governance contract. Anyone can verify that on Etherscan. It doesn't make anything unbreakable. It makes the rule readable.
At Shieldara we audit smart contracts. If you're building something that holds other people's money and want a second pair of eyes before you ship, our DMs are open
Is the smart contract holding your money still the one that was audited?
It's a fair question to ask before you deposit into any DeFi protocol, and the answer is public. You don't need to write code to find it. Here's how, using a real protocol as the example.
An audit reviews one specific version of the code. Think of it as a dated photo, not a live camera feed.
Many protocols are built so their code can be changed after launch. These are called upgradeable contracts, and it's useful: it's how bugs get fixed. It also means one question matters more than almost any other: who is allowed to change the code?
Let's look at a real answer. Compound's USDC market on Ethereum (0xc3d688B66703497DAA19211EEdff47f25384cdc3):
1. It is upgradeable. Since launching on 2022-08-13, its code has been swapped 60 times. The latest change was 2026-09-04. (Etherscan, contract page, Events tab, filter for "Upgraded".)
2. Right now, the account that can approve a swap is an admin contract (0x1ec63b5883c3481134fd50d5daebc83ecd2e8779) that is owned by a timelock (0x6d903f6003cca6255d85cca4d3b5e5146dc33925).
3. A timelock is a public waiting room. A change has to be queued and sit there before it can go live. This one waits 172,800 seconds. That's 48 hours.
4. The timelock answers to Compound's governance contract (0x309a862bbc1a00e45506cb8a802d1ff10004c8c0), so changes go through governance, not one person.
That is not the only valid setup. But it's the kind of answer you want to be able to find: a named owner, a public delay, and a trail you can read.
What to look for on any protocol:
- Who holds the upgrade power? One wallet means one private key decides. A multisig means several people must agree. A timelock adds a public waiting period. None of these is automatically wrong. You just want to know which one you're trusting.
- If there's a timelock, how long is the delay? Zero means no warning at all. 48 hours means a change is visible two days before it lands, which is time to read it and decide.
- When did the code last change, and was that after the audit? An audit report names the exact version it reviewed. If the code changed after that, the fair question is whether the new version was reviewed too.
- Does the audit match what's actually deployed? Check that the audited version and the live version are the same code.
At Shieldara we do smart contract audits, and this is the lens we care about: a review is only as useful as the code it was run against. If you're shipping an upgradeable protocol and want a second pair of eyes before you deploy, our DMs are open.
All numbers above were read from Ethereum mainnet on 2026-10-30. Anyone can reproduce them on Etherscan.
Is the smart contract holding your money still the one that was audited?
It's a fair question to ask before you deposit into any DeFi protocol, and the answer is public. You don't need to write code to find it. Here's how, using a real protocol as the example.
An audit reviews one specific version of the code. Think of it as a dated photo, not a live camera feed.
Many protocols are built so their code can be changed after launch. These are called upgradeable contracts, and it's useful: it's how bugs get fixed. It also means one question matters more than almost any other: who is allowed to change the code?
Let's look at a real answer. Compound's USDC market on Ethereum (0xc3d688B66703497DAA19211EEdff47f25384cdc3):
1. It is upgradeable. Since launching on 2022-08-13, its code has been swapped 60 times. The latest change was 2026-09-04. (Etherscan, contract page, Events tab, filter for "Upgraded".)
2. Right now, the account that can approve a swap is an admin contract (0x1ec63b5883c3481134fd50d5daebc83ecd2e8779) that is owned by a timelock (0x6d903f6003cca6255d85cca4d3b5e5146dc33925).
3. A timelock is a public waiting room. A change has to be queued and sit there before it can go live. This one waits 172,800 seconds. That's 48 hours.
4. The timelock answers to Compound's governance contract (0x309a862bbc1a00e45506cb8a802d1ff10004c8c0), so changes go through governance, not one person.
That is not the only valid setup. But it's the kind of answer you want to be able to find: a named owner, a public delay, and a trail you can read.
What to look for on any protocol:
- Who holds the upgrade power? One wallet means one private key decides. A multisig means several people must agree. A timelock adds a public waiting period. None of these is automatically wrong. You just want to know which one you're trusting.
- If there's a timelock, how long is the delay? Zero means no warning at all. 48 hours means a change is visible two days before it lands, which is time to read it and decide.
- When did the code last change, and was that after the audit? An audit report names the exact version it reviewed. If the code changed after that, the fair question is whether the new version was reviewed too.
- Does the audit match what's actually deployed? Check that the audited version and the live version are the same code.
At Shieldara we do smart contract audits, and this is the lens we care about: a review is only as useful as the code it was run against. If you're shipping an upgradeable protocol and want a second pair of eyes before you deploy, our DMs are open.
All numbers above were read from Ethereum mainnet on 2026-10-30. Anyone can reproduce them on Etherscan.