home.social

Search

4 results for “hexaheximal”

  1. … which is frustrating because my goal for is _entirely_ to make Unix time more useful and intuitive with the familiar vocabulary of time and date intervals.

    The problem was that, while the three most significant digits of Unix time in hexadecimal, currently 06A, were clearly closest in magnitude to a **year**, and the five most significant digits, currently 06ADA were closest in magnitude to a **day**, how to best represent months and weeks?

  2. Next year, 06Byr, begins 2026-11-20. The first month is 06B1m, and the first week is 06B0w.

    In designing hexunixtime, I have striven to map the common time and date ontology to parts of unix time in hexadecimal matching as closely as possible the magnitude of the interval. In the case of weeks and months, this turned out a little awkward, and became one of the least intuitive quirks of hexunixtime.

  3. It is the month 06ADm; the penultimate month of the hexunixtime year, 06Ayr.
    On 2026-10-27 (UTC) the last month of the year begins: 06AFm.

    If you are interested in how the digits of Unix time (in hexadecimal) can track time…

    Hexunixtime months are always odd. They have about 24 days each, composed of two hexunixtime weeks. So on 2026-10-27 (Oct 26, about 6 PM in California), the "week" 06AEw will begin at the same time as 06AFm. Then, 06AFw is the last week of the year 06Ayr.

  4. By send21

    Many crypto theft stories involve a hacked exchange or a leaked seed phrase. Address poisoning needs neither. No key is stolen and no code is exploited. The victim signs a perfectly valid transaction from their own wallet, to an address they chose themselves. It just happens to be the wrong address.

    This post explains how the attack works, what the research says about its scale, and the habits that make it much harder to fall for.

    How the attack works


    On chains like Ethereum and BNB Smart Chain, an address is a 40-character hexadecimal string. Nobody memorizes those. So, as a peer-reviewed USENIX Security 2025 paper titled "Blockchain Address Poisoning" puts it, users often select addresses from their recent transaction history. That habit is the whole attack surface.

    The attack runs in three steps:

    1. Watch. The attacker monitors the chain for transfers. When you send tokens to an address, they note who you paid.
    2. Generate a lookalike. They brute-force a new address whose first and last characters match the one you paid. Wallets often shorten addresses to something like 0xAbC12…9f3E, so a match on the visible ends is enough to look right.
    3. Poison your history. They make that lookalike address show up in your transaction list, ideally near the top.

    Then they wait. The next time you go to pay the same counterparty and grab the address from your history, there's a chance you grab theirs.

    The paper describes three ways attackers plant the lookalike:

    • Tiny transfers: a small amount of the same token, sent from the lookalike address to you.
    • Zero-value transfers: a transfer of zero tokens that appears to go from you to the lookalike address. Popular token implementations let anyone trigger a zero-value transferFrom with an arbitrary sender, so your history can show an outgoing "payment" you never made. The researchers call these potentially even more dangerous than tiny transfers, because it looks as if you've paid that address before.
    • Counterfeit token transfers: a fake token with a name close to a real one, "sent" from you to the lookalike.

    Because blockchain transactions are irreversible, a single mistake is usually final.

    How big is it?


    The USENIX paper measured address poisoning on Ethereum and BNB Smart Chain between 1 July 2022 and 30 June 2024. On those two chains alone, the researchers found:

    • over 270 million attack attempts,
    • targeting over 17 million victims,
    • 6,633 successful incidents, with at least $83.8 million lost.

    The authors call their loss figure a conservative lower bound: they only tracked a handful of major stablecoins. They also note the attack can affect any blockchain whose addresses are hard for people to compare at a glance, not only hexadecimal ones.

    It hasn't slowed down. Blockaid reported in March 2026 that it had flagged over 65.4 million address poisoning transactions on-chain since January 2025.

    The December 2025 case: the test transfer didn't help


    On 20 December 2025, a trader lost 49,999,950 USDT, nearly $50 million, to address poisoning. According to The Block, the trader had withdrawn the funds from Binance and was moving them to their own wallet. They did what security guides tell you to do: they sent a small test transaction first, 50 USDT, to the right address.

    That test is what the attacker was waiting for. An automated script generated a lookalike address that matched the intended one in its first five and last four characters. The differences were only in the middle, which many wallet interfaces hide behind an ellipsis. The attacker then sent small transactions from the lookalike to the victim's wallet. When the victim copied an address from their history for the full transfer, they likely picked the attacker's.

    Etherscan data cited by The Block puts the test transaction at 3:06 UTC and the big transfer about 26 minutes later, at 3:32 UTC. Within 30 minutes the attacker had swapped the USDT to DAI (which can't be frozen the way USDT can), then to ETH, and moved around 16,680 ETH into Tornado Cash.

    Blockaid describes this as test-transaction interception: bots watch for small "test" transfers, plant a lookalike right after, and wait for the big one. In Blockaid's words, the technique "specifically targets security-conscious users."

    The lesson isn't that test transfers are useless. A test checks that the address you typed works. It does nothing to check that the address you use next is the same one.

    Habits that actually help


    None of these are new, but the December case shows why they matter.

    1. Never copy a payee address from your transaction history. This is the attack vector. Get the address from a source you trust: your saved contacts, the recipient's own page or invoice, or direct confirmation from them.

    2. Use an address book or saved contacts. Save and label addresses you pay often, once, after checking them properly. Then always pay from the saved entry. The USENIX researchers list building an allow-list of trusted addresses as a user-level mitigation, and Blockaid recommends the same.

    3. Verify the full address, not just the ends. Attackers generate addresses that match exactly the characters people check. Compare the middle too, character by character, ideally on your hardware wallet's screen before you sign.

    4. Ignore zero-value and dust transfers. An unexpected tiny transfer from an address that looks like one of your contacts is a warning sign, not a payment. A zero-value "transfer" from you that you don't remember making is almost certainly poisoning. Don't interact with it, and don't use it as a source of addresses.

    5. Treat a test transfer as one step, not as proof. After a test, confirm with the recipient through a separate channel that it arrived. Then send the full amount to the same verified address, from your address book, not from history. Blockaid notes that a test alone is not sufficient without independent verification.

    Where pay links fit in


    We build send21: crypto pay links and an API for people and AI agents. It's relevant here because of where the address comes from, not because it makes the attack go away.

    Address poisoning works when the payer copies the payee's address from their own transaction history. With a pay link, the payer doesn't do that. The receiver sends a link, and the payer gets the address and amount from it as a standard QR code or payment URI (BIP-21, Solana Pay, EIP-681 or a Lightning invoice). They then sign and send from their own wallet, straight to the receiver's own address. send21 is non-custodial: it never holds private keys or funds, and never signs or broadcasts a transaction.

    On the receiving side, the owner decides which addresses get used. An AI agent working through the send21 API or MCP server can only propose a receiving address. The owner signs in to the app, compares it character by character, and approves it with a passkey or an authenticator code. On new accounts, an API key that names any other address gets 422 address_not_approved and nothing is created.

    The limits matter just as much:

    • A fake link sent by someone pretending to be the receiver still points to the wrong address. Only open links that came from someone you know, through a channel you trust.
    • If the receiver's account is compromised, the attacker could get an address of their own approved.
    • Your wallet history can still be poisoned. A pay link only changes where the address comes from for that payment.

    So the habit from the top of this post still applies: before you sign, check the full address in your wallet.

    Summary


    Address poisoning doesn't break cryptography. It works on a habit: copying addresses from history and checking only the first and last few characters. Break that habit. Pay from saved contacts or from the recipient's own link, read the whole address, ignore dust and zero-value transfers, and don't let a successful test make you relax for the next transfer.

    Questions or corrections: [email protected].#security #crypto #blockchain #web3 #software #coding #development #engineering #inclusive #community
    Address poisoning: the copy-paste habit that cost one trader 49,999,950 USDT

Share on Mastodon

Enter the server where you have an account.