Solang | Writing Solidity Contracts For Stellar

Solidity developers now have a new doorway into the Stellar universe. The Solang compiler suite offers Solidity across the border into Soroban’s Wasm-powered smart-contract landscape.

This tutorial distills everything you need to know right now: what Solang supports, how it differs from traditional EVM Solidity, and how you can write, compile, and deploy your first Soroban contract using Solidity.

Let’s explore.

---

What Is Solang and Why Does It Matter?

Solang is a Solidity compiler built on LLVM that already targets Solana and Polkadot. Now it speaks Stellar too.

Think of it as a multilingual guide translating Solidity syntax into Wasm bytecode that the Soroban VM understands.

The headline idea is simple:
Solidity → LLVM IR → WebAssembly → Soroban VM

But the magic isn’t the pipeline. It’s the integration with the Soroban host environment. Soroban contracts are intentionally tiny, leaning on host functions for storage, hashing, logging, and inter-contract calls.

Solang’s job is to translate Solidity’s surface language into the correct host calls.

---

Getting Started with the Solang Playground

The fastest way to try Solang is the web IDE:

No tooling, no terminal smoke—just paste Solidity and press the big shiny button.

Let’s begin with the simplest example: an incremental counter.

---

Your First Solidity Contract on Stellar

Here’s the canonical incrementer included in the IDE:

pragma solidity 0;

contract incrementer {
  uint32 private value;

  constructor(uint32 initvalue) {
    value = initvalue;
  }

  function inc(uint32 by) public {
    value += by;
  }

  function get() public view returns (uint32) {
    return value;
  }
}

Steps:

1. Compile
   Click Compile. If it finishes without complaint, Solang has accepted your syntax.
2. Deploy
   Under Deploy, choose incrementer, enter a constructor value (e.g. 5), and deploy.
3. Invoke functions
   • Call get() → returns 5.
   • Call inc(3) → success.
   • Call get() again → now 8.

Congratulations: you’ve just deployed and interacted with a Solidity contract on Stellar.

---

Understanding How Solidity Behaves on Soroban

This is where things get interesting. Solang compiles familiar syntax, but the underlying semantics come from Soroban, not the EVM.

Here are the core differences you must understand:

---

Storage Is Explicitly Scoped (temporary, instance, persistent)

Soroban splits storage into three categories:

Type	Lifetime	Use Case
temporary	Single invocation	Scratch variables that vanish instantly
instance	Contract lifetime	Data tied to a contract instance
persistent	Durable	Ledger-backed long-term storage

Solang exposes these through special keywords:

uint64 public temporary tVar = 1;
uint64 public instance iVar = 1;
uint64 public persistent pVar = 2;

These map directly to different host function calls under the hood.

---

No msg.sender — Authorization Works Differently

In EVM Solidity:

require(msg.sender == admin);

In Soroban, the VM does not automatically inject the sender address. There’s no msg.sender at all.

Instead, the caller must explicitly authorize themselves:

sender.require_auth();

Any Soroban-native contract—whether written in Rust or Solidity—follows this model.

---

Arithmetic Behaves Safely

Underflows and overflows are checked. This often surfaces when porting older Solidity code that relied on wrapping semantics.

Example from the “errors.sol” demo:

count -= 1;

Calling it twice will cause the transaction to fail. Treat this as a friendly guardrail.

---

TTL (Time-To-Live) Matters

Soroban uses state archival, meaning inactive contract data ages out. Solidity has no built-in notion of state TTL, so Solang adds methods to extend storage lifetimes:

pCount.extendTtl(1000, 5000);

You can extend TTL on each storage type individually.

---

Porting Solidity Code

Soroban supports certain primitive types right now:

Supported types:

• uint and int sizes up to 256
• string
• address
• bool
• mappings
• vectors
• structs

It’s not going to be a case of copy and pasting code to create defi clones. To port EVM Solidity code to Stellar there are going to be some workarounds to suit the environment.

1. Replace unsupported types with Soroban-friendly equivalents.
2. Avoid low-level EVM operations (call, delegatecall, inline assembly, etc.)
3. Replace msg.sender logic with explicit auth.
4. Expect to adjust storage usage.

This is just a few of the ones that I’ve found so far, there are likely other nuances that need to be account for. As Solang matures, many of these issues will improve.

---