> ## Documentation Index
> Fetch the complete documentation index at: https://docs.layerzero.network/llms.txt
> Use this file to discover all available pages before exploring further.
# Getting Started with LayerZero on Stellar
> Key differences between EVM and Stellar for LayerZero developers. Understand the authorization model, storage tiers, TTL management, and other core concepts.
LayerZero's universal messaging protocol enables any blockchain that supports state propagation and events to participate in crosschain communication — including **Stellar**.
LayerZero provides **Stellar Soroban contracts** that can communicate with the equivalent [Solidity Contract Libraries](/v2/developers/evm/overview) deployed on EVM chains.
If you're new to LayerZero, we recommend reviewing [**"What is LayerZero?"**](/v2/concepts/getting-started/what-is-layerzero) before continuing.
## Differences from the Ethereum Virtual Machine
Stellar's [Soroban](https://soroban.stellar.org/) smart contract platform differs from the EVM in several fundamental ways. This section covers the key differences you'll encounter when building LayerZero applications on Stellar:
### Comparison Table
| Concept | EVM (Solidity) | Stellar (Soroban) |
| ------------------------ | --------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Language** | Solidity | Rust (compiled to WASM) |
| **Token standard** | ERC-20 | SEP-41 / Stellar Asset Contract (SAC) |
| **Address format** | 20 bytes | 35 bytes StrKey-encoded (1-byte version + 32-byte payload + 2-byte checksum), with contract (C-) and account (G-) [types](/v2/developers/stellar/technical-overview#address-types) |
| **Authorization** | `msg.sender` / `onlyOwner` | `require_auth()` / Soroban auth framework |
| **Contract composition** | Inheritance | Trait composition + proc macros |
| **Storage** | Mapping / slot-based | Typed enum with instance, persistent, and temporary storage |
| **Gas model** | Gas (EVM opcodes) | CPU instructions + memory + storage I/O |
| **Contract upgrades** | Proxy pattern | Native WASM hash replacement |
| **Fee payment** | `msg.value` (ETH sent with tx) | Explicit SEP-41 token transfer |
| **Deploy model** | Deploy bytecode | Upload WASM, constructor called on deploy |
| **Reentrancy** | Reentrancy possible, requires contract-level guards | Reentrancy prohibited natively |
### Authorization Model
In Solidity, you check `msg.sender` to verify who called a function. Soroban uses a fundamentally different approach -- the **Soroban Authorization Framework**:
```solidity wrap theme={null}
// EVM: check msg.sender
function transfer(address to, uint256 amount) external {
require(msg.sender == owner, "not authorized");
// ...
}
```
```rust wrap theme={null}
// Soroban: require explicit authorization
fn transfer(env: &Env, from: &Address, to: &Address, amount: i128) {
from.require_auth();
// ...
}
```
In Soroban, the caller explicitly authorizes the action. This works with both contract-to-contract calls and user wallets, and supports batched authorization across multiple calls in a single transaction.
### Trait Composition vs Inheritance
Solidity uses inheritance to build contract hierarchies (`contract MyOFT is OFT`). Soroban uses **trait composition with proc macros**:
```rust wrap theme={null}
// Soroban: #[lz_contract] provides contract, TTL, and auth; #[oapp] generates OApp trait implementations
#[lz_contract]
#[oapp]
pub struct MyOApp;
// You implement the receive logic
impl LzReceiveInternal for MyOApp {
fn __lz_receive(env: &Env, origin: &Origin, guid: &BytesN<32>, message: &Bytes, extra_data: &Bytes, executor: &Address, value: i128) {
// Your application logic
}
}
```
The `#[oapp]` macro generates implementations for `OAppCore`, `OAppReceiver`, `OAppSenderInternal`, and `OAppOptionsType3`. You can customize specific traits using `#[oapp(custom = [receiver])]`.
### Storage Model
Soroban has three storage tiers with different costs and lifetimes:
| Storage Type | Lifetime | Use Case |
| -------------- | -------------------------------------------------- | -------------------------------------------- |
| **Instance** | Tied to contract instance | Configuration, addresses, immutable settings |
| **Persistent** | Survives contract upgrades, requires TTL extension | Peer mappings, user data |
| **Temporary** | Short-lived, cheapest | Caches, intermediate state |
All Soroban storage entries have a **Time-To-Live (TTL)**. If a persistent entry's TTL expires, it becomes archived and must be restored before it can be read. LayerZero contracts automatically manage TTL extension for critical storage entries.
### Native Fee Payment
On EVM, LayerZero fees are paid via `msg.value`. On Stellar, fees are paid by explicitly transferring the native token (XLM) to the Endpoint before calling `send`:
```rust wrap theme={null}
// Soroban: explicit fee transfer (handled internally by OApp)
// 1. Transfer native fee to endpoint
native_token.transfer(fee_payer, endpoint_address, native_fee);
// 2. Call endpoint.send(...)
```
This is handled internally by the OApp base contract -- you don't need to manage fee transfers manually.
## Next Steps
* **[Technical Overview](/v2/developers/stellar/technical-overview)**: Deep dive into Soroban's architecture, protocol lifecycle, and how it affects LayerZero development.
* **[Build an OApp](/v2/developers/stellar/oapp/overview)**: Create your first Omnichain Application on Stellar.
* **[Build an OFT](/v2/developers/stellar/oft/overview)**: Deploy an Omnichain Fungible Token with SEP-41 integration.
* **[Troubleshooting](/v2/developers/stellar/troubleshooting/common-errors)**: Common errors and how to resolve them.