2026-10-08

A USDT0 AMA

Last week I built a USDT0 demo and walked through how the LayerZero infrastructure works on Stellar (2026-10-01). Most of your questions about USDT0 arrived after that call, so this week I brought reinforcements. I collected around 30 questions from you and from a few ambassador chapters, shortlisted nine, and hoped to get through four. We got through six or seven.

My guest was Fabricius "Fifo" Zatti. If you've been in the ecosystem for more than six months, you probably know him already. He has been around Stellar for about six years. He started at Cheesecake Labs, where he was the top contributor to Stellar Plus, and now works at The Aha Company. He also wrote Colibri, the TypeScript toolkit for Stellar that includes contract build verification. He works with SDF on a program that brings experts from the ecosystem to help partners build on Stellar.

On USDT0, Fifo was one of the Stellar-side technical contacts for the LayerZero Labs and Everdawn Labs teams. He worked on the issuer setup sequence, six versus seven decimals, multisig tooling, build reproducibility and verification, DVN data needs, and partner readiness. To be clear: he is not from LayerZero or Everdawn, and he did not build the LayerZero protocol internals or set USDT0 policy. He said he might not have every answer, and he gave honest ones where his memory was fuzzy.

For scale, as of the call: about 5 million USDT0 circulating on Stellar, across roughly 25,000 accounts.

Before the Questions: Hack Meridian

Hack Meridian is our flagship hackathon before the Meridian conference. It runs on October 25–26 in Lisbon. If you have no visa restrictions, come show us what you're building, and make your repos public so we can judge them. No idea what to build? Ask Raven. Prizes go up to $30,000 in XLM.

There's more than one way to take part. That day was my third stream: an AMA as a road to Hack Meridian with Web Zero, a Spain-based developer community, and a presentation on Stellar tooling at a workshop organized by Her DAO. The next day there was an event in Berlin on building with AI. Our production partner is Guava Global, part creative studio, part production house, part cultural connector.

Fifo's Seat at the Table

My first question: this was not a one-seat operation, so what did his seat look like, and did any Stellar idea take longer than necessary to land?

Fifo tries to stay neutral and transparent about how things work and how choices affect the ecosystem. LayerZero is a huge protocol, and USDT0 already runs on many networks with its own standards. Soroban is a new space for them. So his job was to make sure the teams had all the information when they chose a path. For almost every project that comes to Stellar, he spends extra time on three things: how storage works, how authorization works, and the bridge between classic and Soroban. He doesn't see these as friction points. He sees them as places where you can use Stellar to your advantage. Much of his role was to question design choices: does this come from a requirement, or from tooling you're used to on other networks? If the latter, can we find a better way on Stellar?

The stressful part was build reproducibility. Everyone wanted USDT0 out quickly, but also well tested and bulletproof, and reproducibility was a hard requirement. The existing standard, SEP-55 (Contract Build Verification), works through attestations tied to the CI process in a repository. During the engagement the team saw they needed a different angle: reproduce the contract build itself. That's hard with Rust compiled to Wasm, where differences in the environment can change the output hash. A lot of people worked on it, and the result is the new SEP-58 (Contract Build Reproducibility for Verification). Fifo can't wait to see the ecosystem pick it up, probe it, and improve it.

Why a Classic Asset and Not a Pure Soroban Token?

This came from last week's stream. When USDT0 leaves Stellar, the seventh decimal is lost; when it arrives, the seventh decimal is empty. A pure Soroban token could carry six decimals, like USDT0 on EVM chains. So why did USDT0 land as a classic asset with a SAC?

Fifo called this the hottest question for any asset issuer coming to Stellar. He admits a bias: he comes from "the old testament of Stellar" and loves the classic side, while also saying Soroban filled real gaps. He thinks the USDT0 teams were pragmatic. A pure Soroban token could work. Good examples exist, such as SolvBTC and the Centrifuge assets. But the key question for builders is: how do you expect people to use this asset? His case for classic:

1. Reach. Classic assets have been around longer. Wallets, non-custodial apps and secondary markets support a new classic asset automatically, so the surface area is immense.
2. Nothing to build or audit. If the control flags meet your requirements, you deploy no extra contracts and need no separate audit. Classic assets get audited with the protocol, and every classic asset runs the same battle-tested implementation.
3. Both worlds. Through the SAC you reach DeFi and smart contracts. You also keep the classic side: the native DEX, liquidity pools and path payments, all cheap and scalable.

For USDT0 specifically, it checked every box. The control flags give the needed control, and the SAC manager adds the extra administration rules. Fifo called the SAC manager "something fancy they did there" and recommends studying it. The OFT then plugs into the classic asset to handle minting and burning. On decimals, he thinks the trade-off is small. Coming in, you get more resolution on Stellar. Going out, you round or leave some dust behind.

The Other Side of the Coin

I played devil's advocate and asked for the downsides. Fifo agreed readily:

• Classic is limited to what the protocol offers. You get the control flags, or you extend the admin with a contract, and that's it.
• No atomic global pause. With classic you pause through trustlines, one by one. You can bundle several in one transaction, but nothing guarantees you pause every holder at once. A Soroban token can do that.
• No per-transfer rules. Need compliance checks during each transfer? SEP-57, T-REX, does that for Soroban tokens. You can't add it to a classic asset; workarounds don't behave the same.
• Trustlines are part of the user flow. Where you already run KYC, the trustline fits in nicely. Where you want users to just hold the token, you have to build it into the workflow, sometimes through the trust function in smart contracts.

Classic assets are a good solution, but not a silver bullet. The unique part is that Stellar has both, and they work together. My summary: the two big advantages of a Soroban token are customizability and onboarding. With smart wallets, users can hold a Soroban token from day one without waiting for a trustline.

Why a Separate SAC Manager?

In LayerZero's standard OFT, one contract is both the token and the app. On Stellar, the USDT0 OFT mints through a separate SAC manager (the three-actor picture from last week: the asset, the SAC admin, and the OFT). Why not make the OFT the SAC admin directly?

You can. Fifo recalled this being a big topic, and he believes the reason was how the teams wanted to set up the multisig and governance, though he doesn't remember every detail. The general lesson is about how much responsibility you put in one contract. On Stellar you weigh storage and resources, because they scale differently. You also weigh upgradability: separate contracts let you upgrade one piece while others stay fixed. He doesn't think upgradability drove this case. The classic asset also mattered. You can't change how the SAC works; it's an interface you build on top of. So a small admin contract on top was necessary, and with the token logic already handled by classic, it wasn't a big lift.

His advice, which I want to repeat: don't copy other projects, even big ones. Evaluate the design for your own use case. Flexible, composable building blocks exist so you can adapt them to your reality. Many developers now treat USDT0 almost as its own standard for cross-chain apps, so it matters to know which parts are design choices, which are security choices, and which are required.

What Does "Waiting for Confirmations" Mean on Stellar?

Stellar closes a ledger and it's final, with no reorgs. So what does it mean when a LayerZero app waits for confirmations on Stellar, and how should an app pick that number?

In LayerZero, the full path from a source contract through the endpoint, the DVNs and the destination endpoint to the destination contract is a channel (a pathway). You configure each channel independently. Two key settings are finality, the number of block confirmations to wait for on the source, and verification, which DVNs must verify the message and how many.

Confirmations exist because some chains can reorg. Competing chains get validated, one wins, and transactions on the loser roll back. That's why Bitcoin and Ethereum transfers wait X blocks. If the destination step ran before the source was truly final and the source then reverted, you'd have a big problem. On Stellar the setting still exists, but a transaction is final after one ledger, about five seconds. Fifo's recommendation: configure Stellar channels with a low value. Add a couple more if you want a safety margin, but you don't need to. For the other chains on your channel, assess each one separately.

Why Does Leaving Stellar Take About Half an Hour?

A viewer said leaving Stellar takes about half an hour, while arriving from Polygon takes under two minutes. What are the delivery states?

It comes down to channel configuration. A message goes through three legs:

1. The source transaction. On Stellar that's about five seconds, plus however many confirmations the channel waits for. USDT0 has its own channel with its own configuration.
2. The DVNs. If the channel requires three DVNs, it takes as long as those DVNs need to pick up, verify and confirm the message on the destination.
3. Execution on the destination. The message runs on the destination chain, and that chain's confirmation time applies.

Open LayerZero Scan and find your message. It breaks down each step: time on the source, time waiting for DVNs, which DVNs took part, and the final leg. You can see where the time goes and whether it's just configuration.

I asked whether the number of signers inside a DVN slows delivery. LayerZero's own DVN, for example, is on Stellar mainnet and has multiple signers. Fifo's answer: it can, but likely not significantly; it depends on each DVN's implementation. If something is slow, look first at the on-chain configuration for that channel: the finality set for the sending and receiving networks is usually the biggest bottleneck. The DVN set also varies by channel: two of three, one of two, four of five. That affects processing time too. Neither of us remembered the signer counts on mainnet offhand; you can look them up from a message on LayerZero Scan. One more point from me: signer count also matters for security, so think about which DVNs you choose.

Closing

Thank you, Fifo, for answering six or seven of my questions. I have 20 more, and I'm saving them for Hack Meridian. If you want to watch me ask them live, come to Lisbon on October 25–26. See you next week at the Stellar Developers Meeting.