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 instruction deterministic. Production funds belong behind approved payment, escrow, or custody partners 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 from customer funding balances. 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, and regulated partner rails — was the work.