SCF #12
PoI Submission
Soroban Pre-Order Contract

Develops a novel Soroban contract that helps to fairly manage "first come, first served" sales processes.

Budget request:

Project Stage




Based in

Team size


Active since

Products & Services

Are you selling a product or service that will take some time to produce or procure? Would you like to get paid through a blockchain, but don't want the hassle of processing refunds manually? Then this Soroban pre-order contract (SPOC) may be for you.

SPOC is in an early stage of development. It is ready to welcome external contributors but not yet ready for end-users. The initial contract development is expected to take several months, after which it will enter an experimental phase for some time to come. After all, Soroban itself isn't production-ready yet.


The idea for SPOC originated with a need that Stellarcarbon expects to have in the future. Stellarcarbon buys carbon credits from carefully selected project developers, which can involve a lot of back and forth communication and can lead to relatively long procurement processes. When discussing the volume of credits to be purchased from a particular project, it would be very helpful to know how much demand there is for these credits.

Similar considerations apply to other tokenized real-world assets. For instance, someone making boutique hand-knitted sweaters—perhaps with a matching NFT—would like to make these to order. Others who tokenize real estate may want to know which kinds of properties and areas are most desirable for their audience of investors.


SPOC aims to provide a fair solution for both buyers and sellers. It asks the buyer to commit to their order of a product or service by providing an up-front payment for it. This gives the seller a specified amount of time to produce or procure the pre-ordered product. The Soroban contract itself serves as an escrow for payments and ensures that all specified terms are followed by both the buyer and the seller. The payment is either unlocked for the seller upon successful delivery, or is refundable to (and by) the buyer when the order expires, and also if the seller needs to cancel orders because their fulfillment isn't possible anymore.

No items found.
Previous Project(s)
No items found.
Progress so far
To get there, we request a budget of  
Additional information


In its most basic form, a pre-order contract is an escrow between a buyer and a seller, to facilitate redemption/delivery of a product or service at a later date. This pre-order contract introduces several safeguards that are meant to protect both the buyer and the seller:

  1. the seller can set up the contract for a single product or range of products
  2. the buyer can independently verify with which parameters the contract has been initialized
  3. the buyer's payment is locked in the contract for a specified amount of time
  4. the buyer's signature is required to redeem the purchase
  5. after the time lock expires, the buyer can refund their own payment
  6. the fulfillment queue is "first come, first served"
  7. an order that is not refunded after the time lock expires maintains its position in the queue
  8. the contract must allow for a perpetual sale, but may implement a maximum queue size
  9. the seller can cancel and refund all orders for a given product type

These requirements are somewhat opinionated and are not a "neutral" representation of a pre-order process. I do, however, believe that these requirements are compatible with existing legal frameworks in many jurisdictions. The configurable time lock in particular can be used to make it easier for the buyer to get a refund, or to let the seller ask for a stronger commitment before the buyer places an order.

Engineering Challenges

There is very little existing work to base SPOC on. Although the pre-order use case in various shapes and forms is common in traditional e-commerce, it seems to have little precedent in smart contracts.

Specifically for implementation in Soroban, I expect the most significant challenge to be the development of an efficient fulfillment queue. The current example contracts for Soroban, e.g. those submitted to Sorabanathon, operate with relatively simple and mostly flat data structures. Implementing a queue for use in Soroban is not straightforward because CONTRACT_DATA values are (de)serialized in their entirety when accessed. For this contract, they will need to be keyed "by buyer" for most functions. To enable the "first come, first served" mechanism efficiently, orders will likely also need to be represented in an index for each product type. This leads to the interesting challenge of keeping two on-chain data structures perfectly synchronized.

Prior Art

I'm not aware of any existing Soroban contract that can be adapted to a pre-order sales process. The closest match is the crowdfund contract in the Soroban Example dApp. A crowdfund is a very particular type of pre-order that has a target budget to reach, and a single deadline at which the offer expires. SPOC—in contrast—implements a queue-based sales process without a monetary target and with an individual time lock for each order that is placed.

There is a smart contract implemented in Solidity by OtoCo, a service that provides legal wrappers for DAOs. They have a launchpool contract that is meant to raise capital, and which models a pre-order token sale as a queue.


This project welcomes contributions under the GPLv3 license. The strong copyleft license should not get in the way of any commercial applications because of the modularity and transparency inherent in Soroban contracts. It is meant to ensure that the Stellar community can benefit from all improvements and adaptations.

A modified version of the SDF Code of Conduct will apply to all spaces managed by the maintainers of this project.

Pitch deck
No items found.
First Deliverable

My first deliverable is an partial version of the pre-order contract that fulfills at least 5 out of the 9 listed requirements. I will need to complete enough of the contract functionality to allow testing it on Futurenet, and to let other developers experiment with it to facilitate a discussion about its use cases. The first deliverable will not include a test suite and will not tackle the challenge of implementing an efficient queue in Soroban. I do not expect to spend all of the requested budget myself: I would like to work with other contributors and will compensate work done towards these deliverables.

Reviewer instructions

A reviewer can check whether the first deliverable has been completed by reading the contract source code or by interactively testing contract function calls, preferably both. They would have to verify that at least 5 of the 9 requirements are fulfilled by the contract implementation. Since the contract will not yet be ready for end-users, the reviewer would need some Soroban development proficiency (e.g. comparable to that needed to complete Stellar Quest series 5).



Alex Olieman (convergence#6459)

SPOC project manager & maintainer

I'm a generalist with a background in Industrial Design Engineering, a Bachelor of Science in Future Planet Studies, and a Master of Science in Information Studies. Active members of the Stellar community may know me from my involvement in Public Node, the Community Fund, Stellar Quest, and as a co-founder of Stellarcarbon. I've been developing software for over 15 years now, and I've served as the project manager and lead engineer of several large projects during the past decade.

LinkedIn: alexolieman

Google Scholar: Alex Olieman

GitHub: aolieman

Keybase: @alioli

Much of my software engineering experience has involved switching between user-facing applications, and low-level optimization. In my work on high-throughput big data applications I have spent countless hours optimizing database queries, and have on occasion had to come up with novel data structures to transform research prototypes into scalable production systems. My background in information retrieval has taught me to have a pragmatic outlook toward solutions, and to keep engineering purism to a minimum when it is not contributing to the desired outcome. Although I'm relatively new to Rust, I'm comfortable working with strictly typed languages. I'm keen to apply my experience to the exciting new frontier called Soroban.