Understanding Stellar Smart Contracts

As the term “smart contract” has permeated into the collective consciousness, I’m seeing an increase in questions about the ability to execute them on Stellar. While there’s a guide to Stellar smart contracts in the documentation, and there have been a few blog posts exploring them, there still seems to be a fair amount of confusion about how Stellar smart contracts actually function, and about the extent to which they can be used.

Smart contracts aren’t new. In fact, smart contracts have existed in some capacity since the creation of the vending machine (and similar contraptions). The premise: we can leverage protocols, networks, and technology to embed contractual obligations, removing the need for large stacks of paper and legalese.

To avoid rehashing the hundreds of smart contract explanations out there, I’ll point you to one of Nick Szabo’s early writings from 1997 that outlines the idea: https://nakamotoinstitute.org/the-idea-of-smart-contracts/

In this post I won’t be teaching you how to write a Stellar smart contract, but instead will explain what they are and how they differ from Ethereum smart contracts.

Ethereum Smart Contracts

Most of the time, when people think of smart contracts, they think of Ethereum, which was literally designed with smart contracts in mind. There’s a lot that goes in to making Ethereum smart contracts function. The two most important things are smart contract programming languages like Solidity and the Ethereum Virtual Machine (EVM) built in to the Ethereum platform. Simply put, a virtual machine is meant to act like an actual computer. The EVM gives Ethereum developers an on chain environment to host and run their smart contract code. As a user, you interact with this code by sending a transaction (with some instructions attached) to the smart contract application and in return the smart contract does something.

The important thing to know and remember is that Ethereum smart contracts are written, then deployed and executed on chain* where they will live forever. In other words, the chain itself encapsulates the contract and the logic for executing/interacting with it. This is also the case for most other smart contract platforms.

While this model provides a ton of functionality, it also provides more edge conditions and complexity than may be necessary for some use cases. Things like simple escrow contracts or multi-sig accounts can have bugs that are unaccounted for due to the nuances of the EVM or misunderstandings of the security mechanisms in your code. This problem can expand further if you’re trying to interface with other smart contracts that may also have their own errors.

An example smart contract could be an auction for a non-fungible token (NFT). The contract could be written such that each participant gets 1 bid that must be worth ≥ $50 and at most 20 people can submit bids. At the end, the highest bid is chosen to receive the NFT and all others get their money back. This contract would be deployed to Ethereum and essentially all the user has to do is submit a transaction that is equivalent to their bid. The smart contract would handle the rest by rejecting low bids, storing bid amounts with addresses, deciding a winner, distributing the NFT, etc.

*Avoiding nuance here for simplicity. If you want to dive deeper read this.

Stellar Smart Contracts

Stellar, on the other hand, does not have a smart contract language or built in virtual machine to execute code and is instead optimized for sending, storing, and trading value.

Instead, Stellar Smart Contracts (aka SSCs) combine transactions with various constraints to achieve an end result. Referencing the Stellar.org SSCs guide, the following are examples of constraints that can be combined to create SSCs:

• Multisignature — Multisig requires multiple parties to sign transactions on an account. You can also assign signature weights and thresholds.
• Batching / Atomicity — Batching is the concept of including multiple operations in a single transaction. Atomicity is the guarantee that given a series of operations, if one operation fails they all fail.
• Sequence — Sequences are represented on Stellar via sequence numbers. Sequence numbers can be used to manipulate transactions and guarantee that certain transactions do not succeed if an alternative is submitted.
• Time bounds — Time bounds are limitations on the time period that a transaction is valid and can be used to represent time in a Stellar smart contract.

This short list of constraints means SSCs are limited in scope when compared to Ethereum smart contracts, but you can still come up with some creative use cases such as escrow contracts, joint entity crowdfunding, lightning channels, and more. You can also write them in the programming language of your choice — limiting the amount of errors and potential attacks.

Another key difference between SSCs and Ethereum smart contracts is that the conditions and logic of the smart contract are created separately from Stellar then submitted to the network as a transaction when the end conditions are met. As a participant in a Stellar smart contract you are not directly interacting with code on chain, but instead agreeing to the conditions of a transaction.

For example, say Alice wants to commission Bob for a piece of art. They come to an agreement that if Bob can finish the art piece in 30 days, Alice will pay him $100, but if it takes longer Alice only has to pay $70. Alice could then use a combination of an escrow account, multi-sig, and/or time-bounds to construct a transaction for both end conditions. Control of the escrow account could then be given to a trusted third party. Once the piece of art is finished, the transaction corresponding to the end condition (was it finished in 30 days or not) is submitted to the network by the trusted party. Bob receives his funds and Alice is only charged for the proper end condition.

Find out more

The full extent of the potential use cases for Stellar smart contracts has not been completely explored but there have been efforts to lay the groundwork for new ideas. If you’re interested in diving deeper into these efforts or Stellar smart contracts in general, I suggest the following readings:

• Distributed Trustless Workers with Stellar
• I Just Wrote a Stellar Smart Contract
• I Just Wrote a Stellar Smart Contract Pt. 2: Let’s Dig a Little Deeper
• Stellar Smart Contracts

If you have any further questions about SSC’s or Stellar in general head over to our public Keybase team!