Project Venus — DeFi on Stellar using Turing Signing Servers
Introduction
In May of 2020, Tyler van der Hoeven wrote a proposal for an experimental Stellar ecosystem smart contract engine called TSS (Turing Signing Servers). At Script3, we had been looking into building DeFi (Decentralized Finance) protocols on Stellar for a while, so we immediately got involved with the project. Once TSS became more of a reality, we partnered with SDF and JST Capital to create Project Venus, a DeFi FX short-term forwards protocol, as a proof of concept for TSS-based DeFi protocols.
TSS Overview
TSS is a network of servers (called turrets) that store smart contracts and will build and sign transactions according to uploaded smart contract specifications at a user’s request. Users can upload smart contracts to any turret, and the turret will create a keypair that it will use to sign transactions generated by this smart contract then return the public key of that keypair to the user.
Combining this network with Stellar’s multi-sig capabilities enables trustless DeFi protocols on Stellar. The developer uploads the DeFi protocol’s smart contracts to multiple trusted turrets and adds the associated public keys as signers on the protocol accounts. Next, the developer modifies the protocol account’s signer weights and thresholds to require most turrets to sign a transaction before it is valid. Then users can run the smart contract by running it across all turrets and aggregating the returned signatures until they have a sufficiently signed transaction.
TSS thus enables trust-free DeFi protocols on Stellar without requiring an on-chain virtual machine. As a result, the smart contract engine adds no inordinate congestion to the network and retains the efficiency offered by Stellar.
Initial Goals for Project Venus
Project Venus was launched with two primary objectives in mind. First and most importantly, TSS needed to be vetted as secure and functional. Secondly, adding short-term forward contract capabilities to Stellar’s network could solve a long-term pain point for Stellar-based financial institutions.
The TSS system is a radical departure from the smart contract engines typical in the DeFi ecosystem. Traditionally, engines follow the Ethereum Virtual Machine (EVM) model by having an on-chain virtual machine run smart contracts. This empowers the engine with ‘live’ access to the ledger state. Being on-chain also forces the contracts to obey the ledger state as the ledger is the only input the contracts have access to. The downside of this model is that running smart contracts on-chain is expensive in resources, time, and money.
TSS attempts to eschew on-chain smart contract execution by running smart contracts on turrets. However, the off-chain nature of TSS smart contracts means they lose live ledger-state enforcement and ledger data access, which are vital for DeFi protocols. TSS enforces the ledger-state by still requiring transactions to be submitted to the ledger; if a transaction does not comply with the current ledger state, it is rejected. Stellar Horizon APIs provide access to ledger data so turrets can get near real-time information from the ledger. In theory, these are sufficient for TSS to host DeFi protocols, but further validation is needed to ensure protocols will function in this environment.
Short-term forwards are a desirable utility in the Stellar ecosystem due to the capital efficiency they enable by allowing entities to lock in a price and delay settlement to a later time. As an added benefit, forwards introduce credit, which most financial systems are built on, to the Stellar ecosystem. Stellar-based remittance companies will be able to immediately take advantage of this service to improve their capital efficiency. Typically, companies that offer payments services separate their need for price discovery from their settlement of transactions. They want to ‘lock in’ their price for a trade with a client before receiving the funds from the client to settle the remittance.
Historically, it has been difficult for Stellar’s remittance entities to provide quotes for clients because price discovery and settlement happen simultaneously on the Stellar DEX. Providing remittance companies the ability to enter smart forward contracts (SFCs) allows these entities to provide quotes to customers, locking in their price and profit, while providing them time to settle the trade-up until the time of the expiry of the SFC. Using SFC’s allows remittance companies to leverage the power of smart contracts and blockchain technology without changing their existing business workflow.
Merging these goals was natural as a decentralized short-term forwards protocol on TSS provides a perfect scenario to validate TSS in the wild.
Implementing and Testing with TSS
Building a short-term forwards protocol on TSS came with a unique set of challenges. Relying on Stellar Horizon APIs to serve ledger data into smart contracts meant that we couldn’t be certain that the data provided by Horizon would be consistent or correct across all turrets running the smart contract. We handled this by coding our smart contracts to allow unexpected things to happen but not allow unacceptable things to happen.
In practice, this design means that we’d force the generated transaction to fail if an unacceptable outcome occurred. For example, at the end of each settlement period, the Venus protocol re-balances the assets in its settlement pool by trading overweight assets for underweight assets on the DEX. We use pathPayment operations to accomplish this and set an acceptable slippage threshold so that if DEX prices artificially drop between transaction creation and transaction submission, the smart contract must be re-run, allowing prices to normalize.
The signer limitation on Stellar also caused some difficulties when building smart contracts. Stellar has a limit of 20 signers per account since each turret running smart contracts for an account must be a signer on said account. This signer limit also limits the number of smart contracts we can use in a protocol and the number of turrets we can upload the smart contract to. To work around these limitations, we ended up consolidating some of our smart contracts into one large contract that performs multiple protocol operations. In the future, I’d like to see this issue fixed by further exploring the musig (https://github.com/future-tense/stellar-musig) system and allowing it to work with M-of-N signers rather than M-of-M.
Despite some growing pains, an immense advantage TSS provides is being able to build contracts with any web assembly compatible language. In the space of DeFi, a lot of pressure is applied to the user to comprehend the smart contract they are entering. They need to know what it does, if it’s secure, and what to expect before they can safely enter the contract. Digesting this with a young, limited language like Solidity is difficult for the average user. Being able to write smart contracts in Typescript/Javascript provides users a much easier-to-digest contract that they can then truly understand. Further, using mature programming languages comes with robust best practices and testing mechanics that help build readable, trustworthy contracts.
Testing protocols on TSS proved to be a smooth, familiar experience. Getting a turret test environment is as easy as deploying a turret out to the Stellar testnet. This is exciting because it means that you can run integration-level tests against a real turret! Contract developers can utilize this near-production test environment to ensure a seamless transition to the mainnet once their contract is ready. In addition, TSS takes advantage of common serverless tools like AWS Lambda that have been a key tool in developer’s toolbox recently. Monitoring, debugging, and getting insight into contract performance in a turret will feel like second nature to those familiar with serverless compute frameworks.
What is Next with TSS and DeFi on Stellar
DeFi and TSS can completely transform the Stellar ecosystem. Stellar’s focus on efficiency and supporting traditional finance create excellent synergies that could allow the DeFi ecosystem to truly integrate with traditional finance. There are a few logical next steps necessary to realize this potential. At Script3, we’re already pushing some of these changes forward ourselves, but we would love to see more ecosystem organizations get involved! If you’re part of an organization interested in helping build the TSS ecosystem, don’t hesitate to reach out!
First of all, the ecosystem needs to decide upon standardized best practices for turret providers. Turrets are the backbone of this smart contract engine. They need to be secure, reliable, fast, and cheap. These goals are achievable, and standardized best practices will help turret providers satisfy these requirements and make it easier for smart contract developers to recognize quality turrets.
Additionally, the ecosystem needs to create a standardized custom Horizon implementation that turrets are expected to provide. Proper ledger data access is essential for TSS smart contracts. Smart contracts must have guaranteed access to Horizon and the ability to filter out potential transaction spam so their smart contracts aren’t disrupted. If a turret could locally access a Horizon instance, it would greatly cut down on the risk of Horizon ever being inaccessible by smart contracts. A custom implementation would also allow smart contracts to make more specific, secure ledger data queries.
Finally, we’d like to see some of the projects anchoring regulated financial assets on Stellar work to support smart contract protocols. Stellar’s blockchain is arguably the best-equipped to handle traditional financial assets such as stocks, bonds, and mutual funds. Encouraging these asset anchors to work with DeFi projects to add regulated assets to smart contract protocols would make a Stellar DeFi ecosystem the most useful one in the space and greatly expand upon Stellar’s goal of sponsoring global economic accessibility.
Project Venus — DeFi on Stellar using Turing Signing Servers was originally published in Stellar Community on Medium, where people are continuing the conversation by highlighting and responding to this story.