Why we picked Stellar Soroban

EVM was the obvious choice. We didn't pick it.

This is a short note on what actually mattered when picking the chain for FairFoundry — the on-chain settlement layer beneath fairb.com. Some of the reasons are about Soroban; some are about not-EVM. Both matter.

The constraint

Manufacturing payments are denominated in fiat — USD, EUR, KRW, JPY. Customers run treasury operations on standard banking rails. They are not buying a token; they are buying a verified service. The on-chain part of the system has one job: make the audit trail tamper-evident and the settlement deterministic. The on-chain part is not where the money lives day-to-day — that's a regulated US escrow account on standard banking rails.

Once you frame the system that way, the chain is more like a notary plus a state machine than a financial system. The bar for picking it shifts.

What pushed us toward Soroban

Native fiat-asset semantics

Soroban's token interface treats Stellar Asset Contracts and the native XLM identically. We model the payment asset once:

AssetKind::{ NativeXlm, StellarAsset(BytesN<32>) }
PaymentAsset { kind, address, decimals }

The contract works the same whether the payment asset is XLM, a fiat-pegged Stellar token, or a customer-issued asset. On EVM we'd be writing wrappers around ERC-20 and a separate native-ETH path; here we wrote one path and it covers everything we need.

Deterministic, no-yield by design

Settlement infrastructure should not double as a yield product. We don't want validators paid in our customers' escrow. Soroban transaction fees are paid by the caller in XLM, settled instantly, and don't accrue elsewhere. This sounds boring; it's exactly what a B2B settlement layer needs.

Smaller, more predictable failure modes

EVM has fifteen years of solidity-shaped exploits. A lot of them are reachable from patterns we'd be writing — price-oracle manipulation, reentrancy on token transfers, signature replay, malicious approve/transferFrom. Soroban contracts are written in Rust on a much smaller surface area. Reentrancy is structurally hard; require_auth replaces the EIP-712 signing dance; storage is keyed and explicit. We still have a bug surface, but it's smaller and more legible.

First-class soulbound primitives

The SVT token is non-transferable on purpose — quality credentials should follow the factory, not be sellable. Soroban's contract model doesn't fight this; we just don't expose transfer. On EVM the equivalent is overriding ERC-721/ERC-1155 hooks and hoping nobody finds the path you missed.

Cross-border settlement is the use case

Stellar's payment-network heritage is the right pedigree for this. Anchors, regulated-on-ramp tokens, near-real-time clearing — these aren't theoretical for us; they're the path our customers' banks already know how to talk to. EVM L2s clear quickly to other EVM addresses. Stellar clears quickly to bank accounts in non-USD jurisdictions. Different problem.

What we gave up

Honest list:

Smaller developer community. Stack Overflow has fewer answers. Rolling your own when Solidity has a vetted OpenZeppelin contract is more work. We wrote our soulbound token instead of inheriting one.

Fewer audited libraries. Pre-Soroban, nothing existed. The ecosystem is closer to "few months ago someone shipped this" than "every pattern has three production-grade implementations." We accepted that we'd write more from scratch and would lean on Soroban's smaller surface area to keep our scratch-written code reviewable.

Wallet UX. Most procurement-and-AP folks have never opened MetaMask, never mind a Stellar wallet. The product papers over this entirely — customers interact with fiat banking rails; the chain is the back office — but it's worth naming.

What we'd revisit

If a customer wants their settlement audit trail on a chain their lawyers already know, we'll consider an EVM mirror. The contract logic is small enough that a port is feasible. Right now no one is asking, so we're staying focused.

The choice isn't tribal. The chain is the back-of-house. Picking the back-of-house that fits the actual constraint — fiat-denominated B2B settlement, single trusted oracle, soulbound credentials, regulated escrow — was the work.