Key takeaways
- Stellar combines native operations with Soroban contracts written in Rust.
- Payment ramps connect network transfers to money outside the network.
- The asset, its issuer and redemption terms must be identified separately.
What is Stellar?
Stellar provides infrastructure for value transfers and asset issuance, with native network functions and Soroban contracts for additional logic. An application may use a payment operation or require programmable rules, depending on what must happen to the asset.
That distinction helps avoid unnecessary complexity. A simple transfer and a product with conditional authorization have different scopes. The design must also identify the asset issuer and the relationship between digital balances and any obligation to deliver value outside the network, rather than treating all issued assets as equivalent.
How it works
Stellar confirms operations through its consensus protocol. Transactions can use native functions or invoke Soroban contracts. Contract code is developed with tools that compile to the network’s WebAssembly environment.
SEP standards describe interfaces used by ecosystem services, including ramps connecting digital assets to other payment systems. Applications must track both the on-chain transaction and the external deposit or withdrawal state. These processes can fail or be delayed independently, so each needs its own reconciliation and clear completion criteria in the backend.
Stellar distinguishes native ledger operations from Soroban contract execution. Trustlines represent relationships with issued assets, while contracts and persistent data have their own resource and storage lifecycle. Designs combining them should clarify where each balance resides and what authorisation each action requires.
What Stellar offers
Stellar can suit payments, fund distribution and issued-asset applications when services cover the complete user journey. Soroban extends that scope when a product needs rules beyond native operations.
At Metlabs, evaluation establishes who receives the money, which asset moves and how redemption works. We then choose payment integration, a custom contract or a combination. The decision includes key control, error handling and traceability sufficient for an operations team to resolve incidents, including cases where an external service and the network report different stages.
For payments connected to an on-ramp or off-ramp provider, the on-chain transfer is one stage of the journey. Banking status, provider checks and recipient delivery follow external processes. Retained references should reconcile both sides and support refunds. Soroban integrations also account for data lifetime and restoration where needed, because state availability is part of application maintenance.
Limitations and selection criteria
A confirmed Stellar transfer does not prove that a bank payment has completed or guarantee an issuer’s obligations. Ramps and external services have their own processes, terms and availability. Products should make those dependencies clear.
Soroban adds programmability alongside testing, maintenance and contract storage management. XRPL may be an alternative for native operations, while an EVM network may fit Solidity dependencies. Comparison should cover the complete movement of funds rather than network fees alone, including how users acquire and redeem the asset.
