STAS Protocol Consideration
We have decided to integrate the STAS protocol on DXS. This post explores our analysis
We’re looking for viral growth at DXS. We’ve got two launches in the pipeline that will lay the foundation for this growth:
- 1.
- 1.This will allow traders to profit-seek in their currency of choice, avoiding BSV price fluctuations
- 2.This will grow our insurance pool and session liquidity, allowing for larger position sizes
- 2.
- 1.This will provide referral compensation for traders who successfully invite new traders onto DXS
- 2.This will reward traders for their loyalty
- 3.This will Incentivise trading volume into the future
Both our stablecoin and our loyalty token require fungibility. STAS provides this.
We consider a token to be permissionless if it can be spent without reliance upon an oracle / signature authority.
The only requirement for a STAS token output to be spent is that the spender constructs a transaction adhering to the STAS template, signs with the appropriate private keys and a miner validates the transaction.
With STAS, there are no permission levels beyond the miner layer. The miners are the only authority.
- 1.Redundancy
- 1.If your oracle goes down, your tokens go down.
- 2.Cost
- 1.If you don’t need an oracle, you don’t pay for an oracle.
- 3.Trust
- 1.If you don’t need an oracle, you don’t trust an oracle.
- 4.Legality
- 1.Companies like Centi look to avoid the legal implications of being a ‘payment processor’ vs being a ‘cash handler’. Read this if you want to understand the perspective.
You need 1, 2 and 3 (and likely 4) if you want to make protocolization feasible.
DXS connects to a liquidity provisioning and trade settlement engine called the Open Liquidity Protocol Foundation (OLP Foundation).
We are looking to protocolize the OLP. Protocolization in this sense would mean the automation of existing business logic with permissionless tokens and smart contracts. Protocolisation would also mean that the OLP becomes a public resource and trading platform liquidity provisioning and trade settlement becomes plug-and-play.
Bitcoin turned settlement (untrusted interaction) into a protocol. Bitcoin eliminated the requirement for simple interactions between parties to be brokered. If you remove the broker, you drive the cost of settlement towards zero.
Leaning on bitcoin’s teachings - if you can automate (protocolize) business processes (especially those involving settlement) then you certainly should.
STAS protocol keeps the door open for these future plans.
The template that defines how STAS transactions are to be built is public. Beyond that, there are STAS transactions on the public BSV blockchain. Anyone can look at the locking / unlocking scripts as well as amounts.
The SDK created by Taal that builds STAS transactions is open to the public. Here is the public use license.
It’s also possible to roll your own SDK that complies with the STAS protocol as outlined in the STAS whitepaper.
Taal purchased the STAS protocol’s IP. Taal will likely charge licensing fees for issuances of STAS tokens in the future, while usage of circulating (already issued) tokens will be free for the public.
New templates can be created that conform to the STAS protocol while adding more features. Currently the suite of templates is relatively limited. All STAS templates are interoperable, e.g. atomically swappable.
There are not yet any markets for STAS token exchange.
STAS protocol requires the most granular unit of any circulating issued token to be represented by a satoshi. Actualization gives us some benefits (ease of integration, lightweight etc) along with drawbacks. For example:
- If you want to issue $1,000,000 worth of USD tokens and support granularity down to one cent, you need 100,000,000 satoshis (1 BSV).
- 1 BSV at a BSV/USD rate of $85 is $85.
- $85 to issue $1,000,000? Not bad, but not ideal.
A standard STAS transaction looks like:
- 148 byte P2PKH input (to cover mining fee)
- 1,400 byte STAS input
- 34 byte P2PKH output (change)
- 1,400 STAS output
Here’s a transaction on mainnet with one STAS input and one STAS output (1:1 STAS transaction). This particular transaction weighs in at 3,486 bytes (improvements have since been made to the STAS script and the same transaction would now be approximately 3,000 bytes).
At $85 BSV/USD, the transaction fee for a standard (1:1) STAS transaction would therefore be:
- 3,000 bytes * 0.05 sat/byte * 85 BSV price / 10^8
- = $0.00013 / transaction
We will ignore issuance and redemption STAS templates in this post (both are much smaller transactions than regular transfers).
What if you have $10.24 worth of STAS USD tokens in your wallet? What if the UTXOs that represent this $10.24 are 1,024 * $0.01 outputs? What if you want to make a $10.24 payment to a friend?
Standard STAS transactions only support up to 3 inputs (one of which is the miner fee payment input). You can only reduce your set by a factor of 0.5 for each transaction.
How do you make your $10.24 payment?:
You make your $10.24 payment by merging outputs via 1,024 transactions, costing $0.1911 in miner fees.
What about adding more STAS outputs / inputs?
This can be done, but each STAS script within the transaction will not remain 1,400 bytes in size, as they are for a 1:1 STAS transaction. Adding one additional STAS output to a transaction increases each STAS script by 85 bytes. Adding two additional STAS outputs to a transaction increases each STAS script by 170 bytes (and so on).
We are not completely sure of the effect of adding additional STAS inputs. We have heard that this may cause too much bloat of the STAS script to be economical and that it would be better to merge via many separate transactions (as in the table above).
The above example in the table is comparable to having $10.24 in your wallet in pennies, which usually you don’t have. Merging 1,024 outputs will not occur regularly in a consumer wallet making this an extreme example.
This is where STAS really shines from DXS’s perspective.
DXS’s back end logic is concerned with tracking the movement of satoshis. STAS integrates with our existing business logic very well. After all, STAS transactions are simply the movement of satoshis.
This is massive for us at DXS as STAS integration does not require a significant rewrite of existing processes.
Let us start by saying that there is no practical fungible token protocol on BSV that is purely miner validated.
All fungible token protocols on BSV must either use an oracle / smart contract agent as an authority OR maintain / subscribe to infrastructure that ensures the chain of token spends for any given token protocol is unbroken all the way back to the issuance transaction.
To safely integrate STAS you must either run or subscribe to a service that maintains the UTXO subset / shard for the token universe you are interested in. Here are your options:
- 1.Run a BSV node that indexes every STAS transaction for the token in question. From this, derive a UTXO subset for the token in question. Any future STAS transaction for this particular token must be spent from this UTXO set (else it is fraudulent).
- 1.DXS is currently implementing this.
- 2.Subscribe to an API service that does (1) for you. Taal currently is running such a service.
- 1.DXS will likely subscribe to this service for redundancy.
Importantly, STAS token state is self-evident (number of satoshis in an output) and only requires maintaining a UTXO subset. In this sense, scaling STAS is no more difficult than scaling BSV.
Additionally this means that STAS inherits the benefits of prunability that BSV enjoys meaning that the protocol is immune to unspendable OP_RETURN transaction pruning by miners.
STAS has excellent miner support, Taal owns the IP and has built a UTXO shard indexing API as well as the STAS SDK. We cannot expect Taal to be the dominant BSV miner in perpetuity but the present situation is positive for STAS.
Taal may also choose to favor STAS transactions in the future with lower miner fee pricing.
The following BSV companies are integrating STAS: