Soroban Support Matrix

This page is the documentation for feature support status on the Soroban target.

This support matrix documents the Soroban features Solang currently intends to support. It should be read as a statement of documented target behavior, not as a claim of exhaustive coverage. Stronger completeness claims would require broader automated validation, such as fuzzing and differential testing, and that work is still in progress.

The Soroban target as a whole is still pre-alpha and experimental.

Related documentation:

Page	Purpose
Soroban Examples Coverage	Upstream stellar/soroban-examples coverage and the corresponding Solang Solidity examples.
Soroban Solidity Language Compatibility	Solidity-facing differences and Soroban-specific language behavior.
Solang and Soroban Rust SDK Differences	Storage layout, host-value representation, and differences from common Rust SDK patterns.

Language Features

Feature area	Status	Details and examples
Contract model	Supported	Constructors with arguments, public functions, and public getters. External functions return at most one value; Solidity’s multiple-return-value tuples are not supported as external return types. Examples: token.sol, timelock.sol, and storage_types.sol.
Core types and collections	Supported	Primitive types, uint256 and int256, string, bytes, bytesN, mappings and nested mappings, and memory/storage arrays, including fixed-size T[N] arrays, nested arrays, and arrays of structs (S[]). Examples: token.sol, timelock.sol, liquidity_pool.sol, atomic_swap, and liquidity_pool.
Events and logs	Supported	Solidity event declarations and emit statements are supported. Indexed fields map to Soroban event topics and non-indexed fields map to event data. print() and runtime error logging are also available. Example: error.sol.
Structs	Partial support	Structs work as ABI function parameters and return values, and can be read from and written to contract storage. Fields of any scalar or reference type are supported, including string, bytes, bytesN, nested structs, and integers up to 256-bit. Struct fields may also be dynamic arrays such as bytes[], and arrays of structs (S[]) work as function parameters and return values. Example using a struct with a dynamic-array field: groth16_verifier.sol. Structs are not yet supported as public state-variable accessor return values or as event declaration parameters.
Enums and other complex user-defined types	Partial support	Enumerations are supported. Examples: custom_types.sol and other_custom_types.sol. Coverage of deeper composite values is still limited and some combinations may not compile.
Yul and inline assembly	Unsupported	Not supported on the Soroban target.
Hash and cryptographic builtins	Supported	sha256 and keccak256 hashing, the BLS12-381 builtins bls12_381_g1_add, bls12_381_g1_mul, and bls12_381_pairing_check, and XDR serialization via to_xdr. Examples: groth16_verifier.sol (BLS12-381 Groth16 proof verification) and merkle_distribution.sol (sha256 and to_xdr Merkle proofs).

The exact Solidity support boundary can only be characterized with broader fuzzing and related validation, and that work is still in progress.

If you run into a missing Solidity feature on Soroban, please open an issue.

Soroban Features

Feature area	Status	Details and examples
Authorization	Supported	address.requireAuth(), address.requireAuthForArgs(...) (scopes the authorization to an explicit argument list, mapping to the host’s require_auth_for_args), and auth.authAsCurrContract(...). Examples: auth.sol, token.sol, timelock.sol, mint_lock.sol, and deep_auth.
Cross-contract calls	Supported	address.call(...) and the documented ABI encode/decode flows around it. Examples: deep_auth and cross_contract.spec.js.
Storage classes and TTL	Supported	Storage classes persistent, temporary, and instance, plus extendTtl(...) and extendInstanceTtl(...). Examples: storage_types.sol and ttl_storage.sol.
Soroban utilities	Supported	block.timestamp and block.number (the current ledger sequence number). Examples: timelock.sol (block.timestamp) and mint_lock.sol (block.number).
Deploying and upgrading contracts	Partial support	Programmatic deployment via the deployContract(bytes32 wasm_hash, bytes32 salt, ...args) builtin, which deploys an already-uploaded Wasm blob (by hash) on behalf of the current contract and runs its constructor, mapping to the host function create_contract_with_constructor. Example: deployer. Live contract upgrades are supported through the updateCurrentContractWasm(bytes32 new_wasm_hash) builtin, which replaces the running contract’s Wasm with an already-uploaded blob (host function update_current_contract_wasm). Example: upgradeable_contract.sol. Solidity’s new Contract() syntax (deploying a compile-time-known contract) is not yet supported.
Native value transfer and payable-style flows	Unsupported	This is not part of the documented Solang support surface on Soroban.
selfdestruct	Unsupported	Not supported on the Soroban target.

Where a feature has target-specific behavior rather than being simply supported or unsupported, that behavior is documented in the compatibility pages linked above.