DEV Community: Victor Eduardo Oliveira

Someone Backdoored axios on npm. Here is How to Check if You Were Hit

Victor Eduardo Oliveira — Tue, 31 Mar 2026 11:32:58 +0000

On March 31, 2026, two malicious versions of axios were published to npm: axios@1.14.1 and axios@0.30.4. Both were live for roughly three hours before npm pulled them down. During that window, anyone who ran npm install axios could have had a Remote Access Trojan (RAT) dropped silently on their machine or CI runner, with no errors and no warnings.

This post breaks down what happened, how the attack worked, and the exact commands to check if you were affected.

What happened

The attacker compromised the npm account of the primary axios maintainer. Using stolen credentials, they published two new releases across both the 1.x and 0.x branches within 39 minutes of each other. The account's registered email was quietly changed to an attacker-controlled ProtonMail address before the releases went out.

Here is what makes this attack stand out: there is zero malicious code inside axios itself. Both releases simply added one new runtime dependency to package.json: a package called plain-crypto-js@4.2.1, which had never appeared in any legitimate axios version.

When you ran npm install, npm resolved and installed that dependency automatically, which triggered its postinstall script and silently executed the dropper.

The malicious dependency: plain-crypto-js

plain-crypto-js@4.2.1 was staged 18 hours before the axios releases, by a separate attacker-controlled account. It masquerades as a clone of the legitimate crypto-js library, with an identical description and the real author's name in the manifest. Visually, it looks harmless. The only difference from the real package is a single extra field in package.json:

"scripts": {
  "test": "grunt",
  "postinstall": "node setup.js"
}

That setup.js is a cross-platform RAT dropper.

What setup.js does

The dropper detects your operating system and then:

macOS: writes an AppleScript to /tmp, executes it via nohup osascript, downloads a binary to /Library/Caches/com.apple.act.mond (named to blend in with Apple system processes), makes it executable and launches it
Linux: fetches a Python script from the C2 server to /tmp/ld.py and runs it in the background
Windows: copies PowerShell to %PROGRAMDATA%\wt.exe (disguised as Windows Terminal), then uses a VBScript to silently fetch and execute a PowerShell payload

All of this runs in under two seconds from the moment npm install starts. The npm install itself exits with code 0 and shows no errors.

The anti-forensics layer

After launching the payload, the dropper:

Deletes setup.js from node_modules/plain-crypto-js/
Deletes the malicious package.json
Renames a pre-staged clean stub (package.md) to package.json, which reports version 4.2.0 with no scripts

After the swap, running npm audit reveals nothing. Running npm list plain-crypto-js shows version 4.2.0. The only reliable on-disk evidence is the existence of the node_modules/plain-crypto-js/ directory, since this package was never a dependency of any real axios release.

A note on the publish metadata

Every legitimate axios 1.x release is published via GitHub Actions with npm's OIDC Trusted Publisher mechanism, meaning the publish is cryptographically tied to a verified workflow. axios@1.14.1 breaks that pattern entirely. There is no corresponding tag or commit in the axios GitHub repository. It was published manually using a stolen npm access token.

Am I affected?

The malicious versions were live between approximately 00:21 UTC and 03:15 UTC on March 31, 2026. If you did not run npm install (or a fresh npm ci) during that window, you were likely not hit.

Run through these steps to verify.

Step 1: Check for the malicious axios versions

npm list axios 2>/dev/null | grep -E "1\.14\.1|0\.30\.4"
grep -A1 '"axios"' package-lock.json | grep -E "1\.14\.1|0\.30\.4"

No output means you are probably fine. Any output means those versions were installed.

Step 2: Check for plain-crypto-js in node_modules

ls node_modules/plain-crypto-js 2>/dev/null && echo "POTENTIALLY AFFECTED"

If the directory exists, the dropper ran. Do not rely on the version number inside it.

Step 3: Check for RAT artifacts on the system

macOS

ls -la /Library/Caches/com.apple.act.mond 2>/dev/null && echo "COMPROMISED"

Linux

ls -la /tmp/ld.py 2>/dev/null && echo "COMPROMISED"

Windows (cmd.exe)

dir "%PROGRAMDATA%\wt.exe" 2>nul && echo COMPROMISED

Step 4: Check for C2 activity in logs

grep -r "sfrclak.com" ~/.npm/_logs/ 2>/dev/null
grep "sfrclak" ~/.bash_history ~/.zsh_history 2>/dev/null

Step 5: Check your CI/CD pipelines

Review any npm install runs in GitHub Actions or other CI systems between 00:20 UTC and 03:15 UTC on March 31. Any pipeline that ran with those axios versions should be treated as compromised, and all secrets injected in that workflow should be rotated immediately.

If you got multiple projects running

for dir in ~/projects/*/; do
  if [ -f "$dir/package.json" ]; then
    result=""
    if ls "$dir/node_modules/plain-crypto-js" 2>/dev/null | grep -q .; then
      result="DROPPER FOUND"
    fi
    axios_hit=$(grep -A1 '"axios"' "$dir/package-lock.json" 2>/dev/null | grep -E "1\.14\.1|0\.30\.4")
    if [ -n "$axios_hit" ]; then
      result="$result | MALICIOUS AXIOS VERSION"
    fi
    if [ -n "$result" ]; then
      echo "⚠️  $dir → $result"
    else
      echo "✅  $dir"
    fi
  fi
done

Remediation

1. Downgrade to a safe version

# 1.x users
npm install axios@1.14.0

# 0.x users
npm install axios@0.30.3

2. Pin the version in your package.json

{
  "overrides":   { "axios": "1.14.0" },
  "resolutions": { "axios": "1.14.0" }
}

3. Remove plain-crypto-js and reinstall

rm -rf node_modules/plain-crypto-js
npm install --ignore-scripts

4. Block the C2 domain (macOS / Linux)

echo "0.0.0.0 sfrclak.com" | sudo tee -a /etc/hosts
sudo iptables -A OUTPUT -d 142.11.206.73 -j DROP

5. Add --ignore-scripts to your CI installs going forward

npm ci --ignore-scripts

This prevents any postinstall hook from running during automated builds, which would have stopped this attack entirely.

If you found a RAT artifact

Do not try to clean the machine in place. Rebuild from a known-good state and rotate everything that was accessible during the compromised install: npm tokens, AWS access keys, SSH private keys, cloud credentials, CI/CD secrets, and any .env values present at install time.

Indicators of Compromise

Category	Value
Malicious packages	`axios@1.14.1`, `axios@0.30.4`, `plain-crypto-js@4.2.1`
C2 domain	`sfrclak.com`
C2 IP	`142.11.206.73`
C2 port	`8000`
macOS artifact	`/Library/Caches/com.apple.act.mond`
Linux artifact	`/tmp/ld.py`
Windows artifact	`%PROGRAMDATA%\wt.exe`
Safe 1.x version	`axios@1.14.0` (shasum `7c29f4cf2ea91ef05018d5aa5399bf23ed3120eb`)

Takeaways

This attack did not require any vulnerability in axios itself. It exploited the trust developers place in a well-known package name and a familiar maintainer account. The entire weapon was a single extra line in package.json.

A few habits that would have reduced exposure here:

Run npm ci --ignore-scripts in CI pipelines as a standing policy
Use npm's Trusted Publisher provenance statements to verify releases were published from the expected CI workflow
Watch for new dependencies appearing in transitive installs that were not there before
Pin your lockfile and review package-lock.json diffs in pull requests

The full technical breakdown, including the decoded dropper, process tree, and file swap events captured at runtime, is in the StepSecurity report.

Stay safe.

Understanding blockchain RPCs from scratch

Victor Eduardo Oliveira — Sat, 28 Mar 2026 18:09:00 +0000

A few days ago I deployed gasfee.oeduardoal.dev, a small tool that shows real-time transaction fees across 7 different blockchains.

The UI is simple, but building it forced me to understand something I had always glossed over: how does your code actually talk to a blockchain?

If you are a backend dev who has never touched Web3, this one is for you.

What is a blockchain, from a backend perspective?

Think of a blockchain as a database you do not own. It is a distributed ledger running across thousands of nodes worldwide. There is no single server. It is a network of computers that all agree on the same state.

As a backend dev, your instinct is: "okay, so how do I query it?" That is where RPCs come in.

What is an RPC?

RPC stands for Remote Procedure Call. In the blockchain world, it is the interface between your app and a node on the network. You do not run the node, you just call it.

It works over HTTP and looks like this:

POST https://eth.llamarpc.com
Content-Type: application/json

{
  "jsonrpc": "2.0",
  "method": "eth_gasPrice",
  "params": [],
  "id": 1
}

A regular HTTP POST. The node responds with the current gas price in wei. Libraries like viem or ethers.js wrap this for you, but under the hood it is just JSON over HTTP.

RPC endpoints are to blockchains what REST APIs are to web services. You are calling a server you do not control, and it returns data from the network.

What is gas?

Every operation on an EVM blockchain costs gas. Think of it as a fee you pay to compensate the validators who process and store your transaction.

The price fluctuates with demand, just like Uber surge pricing. When the network is busy, fees go up. When it is quiet, they drop.

Gas is measured in gwei, which is just a small unit of ETH:

1 ETH = 1,000,000,000 gwei
1 gwei = 0.000000001 ETH

A standard ETH transfer costs 21,000 units of gas. So if the gas price is 10 gwei, your transaction costs 21000 × 10 gwei = 0.00021 ETH, which you then convert to USD using the current ETH price.

Why 7 chains?

All 7 chains in the tracker are EVM-compatible, meaning they speak the same RPC protocol as Ethereum. The same method names, the same response format. The only difference is the endpoint URL and the native token price.

This is what makes building cross-chain tools surprisingly approachable. Ethereum, Base, Polygon, Arbitrum, Optimism all use the same call, just a different URL.

const chains = [
  { name: "Ethereum", rpc: "https://eth.llamarpc.com" },
  { name: "Base",     rpc: "https://base.llamarpc.com" },
  { name: "Polygon",  rpc: "https://polygon.llamarpc.com" },
  // ...
]

const fees = await Promise.allSettled(
  chains.map(c => fetchGasPrice(c.rpc))
)

Promise.allSettled instead of Promise.all, so a single chain being down does not break the whole UI.

Wrapping up

Blockchain is not magic. It is a distributed system with an HTTP interface. If you know how to call an API, you already know most of what you need to start exploring Web3.

The tracker is live at gasfee.oeduardoal.dev. Questions? Drop a comment, happy to go deeper on any of this.

Where Is the Real Risk in Cross-Chain Bridges?

Victor Eduardo Oliveira — Sat, 28 Mar 2026 15:28:17 +0000

Every bridge has risk. The question is where.

When people talk about bridge security, the conversation usually jumps to "bridges got hacked." And that's true, some did, spectacularly. But treating all bridges as equally dangerous misses the point. The risk profile depends entirely on the model: what's being trusted, who controls it, and what happens when something breaks.

I've spent enough time working with cross-chain stablecoins to develop a mental model for this. Here's how I think about it.

Risk in Lock & Mint

Canonical bridges (the lock & mint model) concentrate risk in one place: the bridge contract.

When you lock 100 USDC in a bridge contract on Ethereum to mint 100 USDC.e on Arbitrum, that contract is now holding your USDC. Scale that up across thousands of users and you get a contract sitting on hundreds of millions of dollars. That's a honeypot.

The attack surface is straightforward:

Smart contract bugs. The bridge contract itself might have vulnerabilities. The Wormhole exploit ($320M, Feb 2022) happened because an attacker bypassed signature verification and minted tokens without an actual deposit. The Ronin bridge ($625M, March 2022) was compromised through validator key theft. Five out of nine validators were controlled by the attacker.

Admin key compromise. Most bridge contracts have upgrade mechanisms or admin functions. If those keys are compromised (phishing, operational security failures, insider action), the attacker can drain the locked funds or modify the contract logic. Multi-sig setups reduce this risk but don't eliminate it. The number of signers and their operational security matter enormously.

Upgrade risks. Upgradeable contracts mean the code you audited yesterday might not be the code running today. A malicious or compromised upgrade can change the rules silently.

The core issue with lock & mint is structural: all value is concentrated in one contract. The more successful the bridge, the bigger the target. And the wrapped tokens on the other side are only worth anything as long as that contract is intact and solvent.

Risk in CCTP

CCTP shifts the trust model. Instead of trusting a contract holding pooled funds, you're trusting Circle's attestation infrastructure.

Here's the flow: USDC is burned on the source chain, Circle's attestation service (Iris) observes the burn and signs a message, and that signed message authorizes minting on the destination chain. There's no pool of locked tokens to steal.

The risk profile is different:

Attestation service availability. If Iris goes down, transfers stop. No attestation, no mint. This is a liveness risk, not a safety risk. Your funds aren't lost, they're just stuck until the service recovers. But for applications that depend on timely transfers, downtime is a real problem.

Circle's authority. Circle can pause the protocol. They can blacklist addresses. They can refuse to attest. This is by design. It's how they comply with regulations and prevent illicit use. But it means your ability to move USDC cross-chain depends on Circle's continued willingness to process your transfer.

Centralization trade-off. CCTP is operationally centralized. Circle runs Iris. There's no decentralized fallback if Circle decides to stop, gets shut down by a regulator, or changes their terms. For USDC specifically, this isn't a new trust assumption. You're already trusting Circle to honor the reserves. But it's worth being explicit about it.

No honeypot, but single point of failure. The good news: there's no giant pool of locked funds to hack. The bad news: the entire system depends on one company's infrastructure.

Risk in LayerZero / USDT0

USDT0 uses LayerZero's messaging layer, which introduces a different security architecture.

On Ethereum, USDT is locked in the OFT Adapter. That's a lock & mint step, and the adapter contract carries the same honeypot risk as any canonical bridge. Between other chains, USDT0 uses burn & mint, so there's no pooled fund risk there.

The cross-chain messaging security comes from DVNs (Decentralized Verifier Networks). Here's how the trust model works:

Configurable security. The token deployer (in this case, Tether) chooses which DVNs must verify each cross-chain message. This could be a single verifier, a required set of multiple verifiers, or a threshold (e.g., 2 out of 3). The security depends on this configuration.

DVN collusion. If the required DVNs collude or are compromised, they could forge a message and authorize a mint on the destination chain without a corresponding burn on the source. Think of it like validator collusion in a proof-of-stake system. The more independent DVNs required, the harder this attack becomes.

Relayer independence. Messages in LayerZero are delivered by relayers, which are separate from verifiers. The security doesn't depend on the relayer being honest (anyone can relay a message). But the relayer being operational matters for liveness.

Issuer control. Tether retains control over the OFT contracts. They can pause, upgrade, or blacklist. Similar to Circle with CCTP, the issuer has ultimate authority over their token. The difference is the transport layer: LayerZero's DVN model vs Circle's proprietary Iris service.

What Can Actually Break

It's useful to distinguish two categories of failure: safety failures (tokens minted without a valid lock or burn — a double-spend) and liveness failures (transfers stuck because an attestation service or verifier is down). Lock & mint concentrates safety risk in the bridge contract. CCTP and OFT largely trade safety risk for liveness risk — there's less to steal, but more that can stall.

Across all three models, the failure modes fall into a few categories:

Source chain reorgs. If the source chain reorganizes after a bridge transaction is processed, you can end up with minted tokens on the destination chain without a valid burn or lock on the source. This is why bridges wait for block confirmations before processing, but the wait time is always a trade-off between speed and safety.

Message delivery failures. In CCTP, if Iris doesn't produce an attestation. In LayerZero, if DVNs don't verify or relayers don't deliver. These are liveness failures. Funds aren't lost, but they're stuck. Applications need to handle this gracefully.

Contract upgrades gone wrong. All three models involve upgradeable contracts. A bug in an upgrade, a compromised deployer key, or a malicious governance proposal can change the rules. Timelocks and multi-sig controls help, but they shift the question to "who holds those keys and how secure are they?"

Regulatory action. Both CCTP and USDT0 have centralized issuers. A regulatory order to freeze assets, pause operations, or delist a chain is a real possibility. Lock & mint bridges with decentralized governance are more resistant to this, but they carry the other risks mentioned above.

How I Think About It

I don't rank these models from safe to unsafe. I think about them in terms of where the risk sits.

	Pooled fund risk	Centralization risk	Messaging risk
Lock & Mint	High (bridge contract)	Varies (depends on governance)	Low (usually direct L1 verification)
CCTP	None (no locked pool)	High (Circle controls everything)	Medium (depends on Iris uptime)
USDT0/OFT	Ethereum adapter only	High (Tether controls token)	Medium (depends on DVN config)

Lock & mint puts risk in the contract. CCTP puts risk in Circle. LayerZero puts risk in the DVN configuration and the Ethereum adapter.

None of these are zero-risk. The question is which risks you're comfortable with for your use case. If you're building a protocol that processes millions in stablecoin transfers, you need to understand these trade-offs at a mechanical level, not just "bridges are risky."

There's no perfect model, only trade-offs. The best you can do is understand exactly what you're trusting and make that decision consciously.

This is the final post in a 3-part series on cross-chain stablecoins. See also: Post 1: Lock & Mint vs Burn & Mint and Post 2: Liquidity Fragmentation. Official protocol docs: CCTP · USDT0 · LayerZero OFT.

Liquidity Fragmentation Is More Expensive Than It Looks

Victor Eduardo Oliveira — Sat, 28 Mar 2026 15:27:41 +0000

Go to any DEX on Arbitrum and search for USDC. You'll find at least two: USDC and USDC.e. Same dollar. Same peg. Different contracts.

Now try to swap USDC.e for something. You might get a worse price than if you had native USDC, because the liquidity pool for USDC.e is thinner. Or the router sends you through an extra hop (USDC.e → USDC → your target token) and you eat the slippage twice.

This is liquidity fragmentation. And it costs more than most people realize.

The Problem: One Dollar, Five Tokens

When multiple bridges connect the same token to a chain, each bridge creates its own wrapped version. On Arbitrum alone, you've had USDC.e (Arbitrum's canonical bridge), and native USDC (issued by Circle). On other chains, you might see bridged versions from Wormhole, Multichain (before it collapsed), Synapse, and others, each with a different contract address.

They're all supposed to be worth $1. But DeFi doesn't care about your intentions. It cares about contract addresses.

Each version needs its own liquidity pool. Each pool competes for the same TVL. The result:

Thinner pools everywhere. Instead of $100M in one USDC pool, you get $60M in USDC and $40M split across USDC.e, USDC.wh, and others.
Worse prices for users. Thinner pools mean more slippage on larger trades.
More complex routing. DEX aggregators have to route through multiple hops, each one adding gas costs and slippage.
Arbitrage overhead. Someone has to keep these versions at parity. That's capital being deployed just to maintain a peg between tokens that represent the same thing.

What This Looks Like in Practice

Say you're building a lending protocol on an L2. You need to decide which USDC to accept as collateral. Native USDC? USDC.e? Both?

If you accept both, your collateral pool has two tokens and you need oracle prices for each. If you only accept one, users holding the other version have to swap first. Friction, gas, maybe slippage.

Now multiply this by every protocol on the chain. Every DEX, lending market, yield vault, and payment app makes the same decision. The ecosystem ends up with a patchwork of liquidity that doesn't compose cleanly.

I've seen this firsthand. Integrating with protocols that only accept native USDC means users bridging through the canonical bridge have an extra step. Some don't realize USDC.e isn't "the" USDC. Support tickets follow.

How Burn & Mint Fixes This

The fundamental fix is simple: if there's only one version of the token on each chain, fragmentation disappears.

That's exactly what CCTP does for USDC. When you transfer USDC from Ethereum to Arbitrum via CCTP, you get native USDC on Arbitrum. The same contract that Circle deployed. Not a wrapped version.

Lock & Mint world:
  Ethereum USDC ──bridge A──► Chain X: USDC.e
  Ethereum USDC ──bridge B──► Chain X: USDC.b
  Ethereum USDC ──bridge C──► Chain X: USDC.c
  Result: 3 pools, fragmented liquidity

Burn & Mint world:
  Ethereum USDC ──CCTP──► Chain X: USDC (native)
  Result: 1 pool, unified liquidity

Every protocol on Chain X integrates with one USDC contract. One liquidity pool. One oracle feed. Users don't have to think about which version they're holding.

USDT0 does the same thing for USDT through the OFT model. Wherever USDT0 is deployed, it's the canonical version. There's no USDT.e competing for liquidity. Just USDT0. If you bridge from Arbitrum to Optimism, you burn USDT0 on Arbitrum and mint USDT0 on Optimism. Same token, same contract standard, unified liquidity on every chain.

The Costs You Don't See

Fragmentation has costs that don't show up on a balance sheet but erode the system:

Capital inefficiency. Liquidity providers have to spread capital across multiple versions of the same token. This means each pool is shallower, which means worse execution for traders, which means LPs earn less. A negative feedback loop.

Integration burden. Every protocol team has to decide which token versions to support. Every version they add is another contract to audit, another oracle to configure, another edge case to handle. This is real engineering time spent on a problem that shouldn't exist.

User confusion. Most users don't understand why their USDC.e can't be deposited into a vault that says "USDC." They see the dollar sign, they see the peg, and they expect it to work. When it doesn't, the experience feels broken.

Arbitrage as a tax. Keeping wrapped versions at peg requires arbitrageurs. Their profit comes from price discrepancies, which means someone else is getting a worse price. The tighter the peg needs to be, the more capital is tied up in this unproductive work.

It's Not Fully Solved

Burn & mint models reduce fragmentation significantly, but they don't eliminate all the complexity.

CCTP only works for USDC. If you need to move ETH, WBTC, or any other token, you're still using lock & mint bridges and dealing with wrapped versions. The fragmentation problem is solved for one token, not the ecosystem.

USDT0 solves it for USDT but requires chains to adopt the OFT-based version. Chains that already have USDT through other bridges may end up with both USDT and USDT0 coexisting, which is its own kind of fragmentation.

And both models introduce different centralization trade-offs. CCTP centralizes control with Circle. USDT0 centralizes with Tether and depends on LayerZero's infrastructure. Whether that's better or worse than fragmentation depends on what you value.

My Take

Fragmentation is a hidden tax on the entire cross-chain ecosystem. It makes everything slightly worse (prices, UX, developer experience, capital efficiency) in ways that are easy to overlook because no single instance looks catastrophic.

Burn & mint models are a real improvement. Having one canonical token per chain is strictly better than having five wrapped versions competing for liquidity. But it comes with centralization costs, and it only works when the issuer is willing and able to operate the burn & mint infrastructure.

For now, the practical advice is: if you're building on a chain where both USDC.e and native USDC exist, default to native USDC. Encourage users to bridge via CCTP. Minimize your exposure to wrapped versions when you can. The fewer token versions in your system, the simpler everything becomes.

Next post: Where Is the Real Risk in Cross-Chain Bridges?

Lock & Mint vs Burn & Mint: What I Learned About Cross-Chain Stablecoins

Victor Eduardo Oliveira — Sat, 28 Mar 2026 15:27:18 +0000

Very recently at LootRush where I work as Senior Software Engineer, I had to implement a bridge tool to help our users to transfer stablecoins to different networks, what we call a bridge and I used to think all bridges worked the same way. You send tokens on one chain, they show up on another. Done.

Then, after working with stablecoins across multiple chains, I realized the mechanics underneath are very different. Those differences have real consequences for liquidity, risk, and what token you actually end up holding.

Here's what I've learned.

Canonical Bridges: Lock & Mint

This is the oldest model. Most L2 bridges work this way.

You deposit USDC into a bridge contract on Ethereum. The contract locks your tokens. On the destination chain (say, Arbitrum), the bridge mints a wrapped version: USDC.e.

Ethereum                          Arbitrum
┌──────────────┐                  ┌──────────────┐
│  User sends  │                  │  Bridge mints│
│  100 USDC    │───────────────►  │  100 USDC.e  │
│              │   lock & mint    │              │
└──────────────┘                  └──────────────┘
       │                                 │
       ▼                                 ▼
  Bridge contract                  Wrapped token
  holds 100 USDC                   (not the real thing)

The USDC.e you receive isn't USDC. It's an IOU. It's backed by the USDC sitting in the bridge contract on Ethereum, but it's a different token with a different contract address. DEXs need separate pools for it. Protocols may or may not accept it.

To go back, you burn the USDC.e on Arbitrum and the bridge releases the original USDC on Ethereum.

This model works, but it has a structural problem: the bridge contract becomes a giant pool of locked funds. That's a honeypot. And the token you hold on the destination chain is only as good as the bridge that issued it.

CCTP: Burn & Mint

Circle's Cross-Chain Transfer Protocol takes a different approach. Instead of locking tokens on one side and minting a wrapped version on the other, CCTP burns USDC on the source chain and mints native USDC on the destination.

Ethereum                          Arbitrum
┌──────────────┐                  ┌──────────────┐
│  100 USDC    │                  │  100 USDC    │
│  burned      │───────────────►  │  minted      │
│              │   burn & mint    │  (native)    │
└──────────────┘                  └──────────────┘
       │                                 │
       ▼                                 ▼
  Supply decreases                 Supply increases
  on Ethereum                      on Arbitrum

Here's the flow:

Your app calls depositForBurn on the source chain. USDC is burned.
Circle's attestation service (called Iris) observes the burn event and signs an attestation.
The attestation is submitted on the destination chain, and receiveMessage mints new USDC.

No wrapped tokens. No liquidity pools. The USDC you receive on Arbitrum is the same native USDC that Circle issues on that chain. One contract address, one token, full composability with every protocol on that chain.

The trade-off is clear: you're trusting Circle. Iris is the bottleneck. Circle can pause the protocol, blacklist addresses, or delay attestations. But for USDC specifically, you're already trusting Circle with the reserves, so this isn't a new trust assumption. It's the same one.

Note: Circle now positions CCTP V2 as the canonical version (launched March 2025), adding Fast Transfers and Hooks. The core mechanic — burn, attest, mint — is unchanged. Official docs: developers.circle.com/cctp. Runnable simulation: examples/cctp/simulate-burn-mint.ts.

USDT0: The OFT Model

Tether went a different route with USDT0, built on LayerZero's Omnichain Fungible Token (OFT) standard.

It's a hybrid. On Ethereum, USDT is locked in an OFT Adapter contract, similar to a canonical bridge. But on every other chain, USDT0 is the token, and transfers between non-Ethereum chains use burn & mint.

Ethereum (source of truth)
┌──────────────────────┐
│  USDT locked in      │
│  OFT Adapter         │
└──────────┬───────────┘
           │ lock
           ▼
    ┌──────────────┐         ┌──────────────┐
    │  Arbitrum    │◄───────►│  Optimism    │
    │  USDT0       │  burn   │  USDT0       │
    │  (minted)    │  & mint │  (minted)    │
    └──────────────┘         └──────────────┘

So Ethereum → Arbitrum is lock & mint. But Arbitrum → Optimism is burn & mint. No need to go back through Ethereum.

The cross-chain messaging goes through LayerZero's network, which uses Decentralized Verifier Networks (DVNs) to validate messages. Unlike CCTP's single attestation service, it's a configurable security stack where the token deployer chooses which verifiers to require.

USDT0 gives Tether a single canonical token across all chains where it's deployed. No USDT.e, no USDT.arb. Just USDT0 everywhere. The supply is always backed 1:1 by USDT locked in the Ethereum adapter.

Official docs: docs.usdt0.to · Security model. OFT standard: LayerZero OFT quickstart. Runnable simulation: examples/usdt0-oft/simulate-oft-transfer.ts.

How They Compare

Lock & Mint (Canonical Bridges)

Creates wrapped tokens (USDC.e, WETH, etc.)
Bridge contract holds all locked funds
Each bridge creates its own version of the token
Risk is concentrated in the bridge contract

Burn & Mint (CCTP)

No wrapped tokens, native USDC on every chain
Supply is managed globally by Circle
Trust is in Circle's attestation service
Only works for USDC (Circle-controlled tokens)

OFT / USDT0 (LayerZero)

Lock on Ethereum, burn & mint everywhere else
Single canonical token across all chains
Cross-chain security depends on DVN configuration
Issuer (Tether) retains full control

Why This Matters

If you're building anything that touches stablecoins across chains, the bridge model determines:

What token your users actually hold. Native vs wrapped.
How deep the liquidity is. One pool vs fragmented across versions.
Where the risk sits. Bridge contract, attestation service, or messaging layer.
Whether protocols on the destination chain accept it. Not every protocol lists USDC.e.

I used to think the bridge was just plumbing. It's not. It's architecture. The model you use shapes the token economics, the risk profile, and the user experience on the other side.

Next post: Liquidity Fragmentation Is More Expensive Than It Looks

Monorepo - Single Repository, many modules

Victor Eduardo Oliveira — Mon, 29 Jun 2020 20:29:36 +0000

Part 1 - Monorepos, porquê dessa abordagem?

What and Why?

Um monorepo é um conceito de arquitetura, que basicamente é o que diz.

Em vez de gerenciar vários repositórios, você mantém todas as suas partes de código isoladas dentro de um repositório.

Monorepo não tem nada em comum com monolíticos.

Você pode manter Vários tipos de aplicativos lógicos em um repositório; por exemplo, um site e seu aplicativo para iOS.

Este conceito é relativamente antigo e apareceu cerca de uma década atrás.

Você pode perguntar, se ele existe há uma década, então por que esse assunto é tão popular agora?

Principalmente, ao longo dos últimos 5-6 anos, muitas coisas sofreram mudanças. ES6, pré-processadores SCSS, gerenciadores de tarefas, npm etc.

atualmente, para manter um pequeno aplicativo baseado no React, você precisa lidar com vários pacotes, suítes de testes, scripts de CI/CD, configurações do Docker sei lá o que mais.

Imagine que você precise manter várias apps.

Cada pacote precisará ter sua própria configuração de ambiente, significa que toda vez que você desejar criar um novo pacote, precisará tudo de novo, copiar todos os arquivos e assim por diante.

Outro exemplo, é se você precisar alterar algo build da aplicação por exemplo, vai precisar olhar cada repositório, fazer a correção, abrir um PR em todos eles, aguardar build em cada projeto, ver se deu certo..

Granularidade de configuracoes

Enfim, o torna muito lento. Nessas situacoes, faz sentido usar monorepo.

Em vez de ter muitos repositórios com suas próprias configurações, imagine ter uma fonte de verdade - o monorepo:

suite de testes
Centralizar configurações como eslint, CI/CD
Arquivo de configuração Docker
Configurações Webpack
Pacotes semelhantes em cada aplicativo
Executando comandos semelhantes
bibliotecas com componentes e vários pacotes

Não é um mundo de flores.

Vantagens

Um local para armazenar todas as configurações e testes.

você pode configurar seu CI / CD e bundler uma vez. O mesmo vale para testes de unidade, e2e e integração - seu CI poderá iniciar todos os testes sem precisar lidar com configurações adicionais.
Refatorar facilmente recursos globais.

Em vez de abrir um PR em cada repositório, ver qual ordem de alteração, abre em um só lugar.
Publicação de pacotes simplificada.

Se você pretende criar um lib de components e publicar isso em um registry. e os comandos são os mesmo pra isso, vale a pena usar monorepo
Gerenciamento de dependência mais fácil. package.json

Apenas um. Não é necessário reinstalar dependências em cada repositório sempre que você desejar atualizar suas dependências.
Reutilize o código com pacotes compartilhados, mas ainda sim isolados.

O Monorepo permite que você reutilize seus pacotes de outros pacotes, mantendo-os isolados um do outro.

Desvantagens

Não há como restringir o acesso apenas a algumas partes do aplicativo
Baixo desempenho do Git ao trabalhar em projetos de grande escala
Maior tempo de construção e configuração. Quanto mais coisas ter que configurar, build, eslint, tests...

Exemplos (Github)

babel - https://github.com/babel/babel
Facebook CRA - https://github.com/facebook/create-react-app
jest - https://github.com/facebook/jest
Gatsby - https://github.com/gatsbyjs/gatsby
nextjs - https://github.com/zeit/next.js/
UAI - https://github.com/belezanaweb/uai

Part 2 - Lerna

Introduction

A tool for managing JavaScript projects with multiple packages.

Realmente ajuda a lidar com versões, a configurar o workflow de pacotes, publicação pro npm ou github, etc. A principal ideia do Lerna é que o projeto tenha uma pasta packages, que contém todas as partes de código isoladas.

Quase todos os comandos do lerna funcionam assim: O comando é repetido para todos os pacotes, como se entrasse em cada pasta. Por exemplo, bump de versão, limpar projeto, instalar dependencias, build...

Using Lerna

Installing

npm install -g lerna // yarn global add lerna

Init

lerna init // --independent or -i 

ls -l

-rw-r--r--  1 user  staff    288B Mar 16 12:06 .git
-rw-r--r--  1 user  staff    63B Mar 16 12:04 lerna.json
-rw-r--r--  1 user  staff    91B Mar 16 12:04 package.json
drwxr-xr-x  2 user  staff    64B Mar 16 12:04 packages

lerna.json

{
  "packages": [
    "packages/*"
  ],
  "version": "0.0.0"
}

Create package

lerna create my-package

lerna create my-module

Bootstrap

lerna bootstap // will create links :)

Exec

lerna exec -- ls // --scope or --ignore --

Clean

lerna clean // delete node_modules

Publish

lerna publish // for ci use --yes // npm publish and git tag

Independent versioning

{

  "packages": [

    "packages/*"

  ],

    "version": "independent",

}

Show me the code

🚀

Links

https://blog.npmjs.org/post/186494959890/monorepos-and-npm

https://medium.com/@chris_14660/learnin-lerna-for-monorepos-in-node-js-5b577bdbf380