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.

Motivation

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.

Solution

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.

Requirements

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.

Contributions

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.

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.

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).