Soroban’s Technical Design Decisions & Learnings from Ethereum

Both Ethereum and Stellar have a native token: ETH (ether) for Ethereum and XLM (lumen) for Stellar. These native tokens are used to pay the transaction fees and other utilities (such as reserve requirements on Stellar or computational services on Ethereum) on their respective networks. Ether and lumens can also be used similarly to other assets, including for trading on exchanges, and more.

ETH, however, does not have the same functionality as other network tokens and does not conform to Ethereum’s most widely accepted and used fungible token standard, ERC-20. To use ETH in a smart contract, you must first convert it to WETH (wrapped ETH) by, you guessed it, wrapping it. Wrapping a token requires interacting with a WETH smart contract, which adds an extra transaction and associated gas fee (Ethereum’s transaction fees average, at the time of writing, at $1.273 per transaction).

Stellar’s XLM, on the other hand, interacts with smart contracts no differently than any other asset on the network. Once a Stellar Asset Contract (SAC) is deployed for any Stellar asset (including XLM), that asset is immediately usable by all Soroban smart contracts with no additional steps or transactions. Treating XLM like any other asset optimizes its utility while also minimizing user fees.

I don’t know about you, but I like to be notified when things are happening. If I come home from work and my mother-in-law is sitting in my living room with no warning, I’d probably be a little upset that she didn’t text me. I mean, I love my mother-in-law, but I’d also like to know when she’s coming over.

On Ethereum, events are not emitted when the ETH native token is transferred. ERC-20 tokens, being smart contracts themselves, emit a transfer event when traded. However, because ETH is not an ERC-20 token and does not follow the token standards, it can just show up in a wallet or account without any notification. Developers must implement separate services to receive ETH transfer notifications, which adds another layer of complexity.

With Soroban, XLM’s Stellar Asset Contract emits the same events as other token contracts. Devs don't have to put in extra work to track native transfers, a feature that streamlines the developer experience, allows for cleaner, simpler code, and optimizes XLM’s utility on Soroban.

Re-entrancy exploits can happen when a smart contract makes a call (such as a withdrawal) to an external contract and then updates its internal state (such as debiting the withdrawal value from the account). The attack occurs when the external contract makes a recursive call back into the calling contract before the first function call is finished, and the calling contract hasn’t updated its internal state. The external contract can then perform withdrawals repeatedly, draining the vulnerable contract’s funds.

Check out a more detailed explanation of re-entrancy attacks and a list of well-known hacks here.

Contract re-entry is allowed in Solidity smart contracts and therefore provides space for one of the most iconic types of attack on Ethereum — one of the most famous hacks was The DAO hack, which led to a loss of $60M. Developers must implement extra security measures when designing their smart contracts to protect against these vulnerabilities.

What’s a surefire way to prevent re-entrancy attacks? Don’t allow contract re-entry — which is what Soroban does!

A checksum is a way to ensure the security of an address by verifying the address’s characters have not been altered or miscommunicated. Checksumming uses the case of each letter to serve as an error-checking mechanism — if the address is altered, it is recognized as invalid. Non-checksummed addresses lack this security measure, and if you make a mistake inputting an address, you could send funds to the wrong destination.

When Ethereum launched, its addresses did not have a checksum. In 2016, a proposal (ERC-55: Mixed-case checksum address encoding) was implemented, which provided a backward-compatible solution that added and checked for uppercase letters in addresses. Although this standard exists, you can still write Ethereum addresses in two ways: a non-checksummed address with all lowercase letters or a checksummed address that includes capital letters. This classic footgun makes it easier for developers to make mistakes that could cost users.

Alternatively, all standard Stellar (and now Soroban) string representations of keys have checksum included. Stellar’s public keys are in a format called Strkey, which is a form of base32 encoding that includes a built-in CRC16 checksum, which improves security and interoperability.

With the ERC-20 token standard, there are two separate transactions necessary to make a trade: `approve` and `transferFrom`. The `approve` function does not transfer tokens but sets an allowance specifying how many tokens the approved address is allowed to spend on behalf of the token owner. The `transferFrom` function then transfers the tokens. This design can pose some challenges, such as security risks (allowances persist until changed or spent — a user may inadvertently leave it open even when no longer needed) and gas costs (every `approve` transaction requires an additional gas fee, so having two transactions for a token transfer significantly increases costs).

Soroban’s authorization framework is built to allow token transfers in a single transaction without the need for separate approvals. This design helps to make everything more transparent — the allowance and transfer are bundled together in one transaction, making it easier to understand with less room for footguns.

It may seem like I’m ragging on Ethereum here. That’s not my intention. Ethereum is the most popular smart contract platform for a reason — it has a vibrant ecosystem of dApps and a large developer community.

What I’m saying is that Ethereum was the first of its kind, and we have the luxury of learning from its experiences to improve Soroban’s design. Many of the Ethereum grievances mentioned above have solutions, they just require extra effort or costs from the smart contract developer or end-user to implement.

Soroban is being built to provide a batteries-included and developer-friendly experience, and these learnings are just some ways of making that a reality. Of course, you can never guarantee security, but the aim is to provide the framework and tools for developers to more easily create safer products. Soroban’s launch on Mainnet is slated for later this year. Be sure to keep up with Soroban-related announcements in our Stellar Developer Discord and experiment on the platform today.