🌐Token Protocol
Fiorin wallet uses the STAS protocol on BSV to wrap ERC20 tokens from Ethereum
What is STAS?
Is STAS permissionless?
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.
Why does ‘permissionless’ matter?
Redundancy
If your oracle goes down, your tokens go down.
Cost
If you don’t need an oracle, you don’t pay for an oracle.
Trust
If you don’t need an oracle, you don’t trust an oracle.
Legality
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.
What does ‘protocolization’ mean?
Fiorin is built by the team at DXS.
DXS connects to a liquidity provisioning and trade settlement engine called the Open Liquidity Protocol (OLP).
DXS 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.
Open source
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.
Licensing or restrictions
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.
Audited
STAS protocol has been audited by Trail of Bits.
Upgradeable tokens and smart contracts
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.
Smart contracts that interact with STAS tokens could support extensibility.
Secondary markets
There are not yet any markets for STAS token exchange.
Actualization of satoshis
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.
Transaction fees
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).
Splitting and merging of UTXOs
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.
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.
Additional infrastructure burden
Let us start by saying that there is no practical fungible token protocol on BSV that is purely miner validated.
This is another way of saying that the back-to-genesis problem has not been solved.
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:
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).
Subscribe to an API service that does (1) for you. Taal currently is running such a service.
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.
Miner support
Taal may also choose to favor STAS transactions in the future with lower miner fee pricing.
Wallet support
Last updated
