https://styx.network/ is a pseudonymous stablecoin project based on Simplicity that we’ve come across run by a user named Χάρων (the original Greek spelling of Charon).
It was originally posted as a self-contained site with covenant source code but without a corresponding source repository or build tools, making it impractical to “verify the covenant” because the parameter values used to instantiate it (param::) weren’t specified, notably the values of the trusted oracle keys that confirm the currency peg price data.
Now there is also a source repository with some more data and details
which would make it easier to try out interacting with this contract, and also a web-based explorer for the deployment of the protocol on Liquid Testnet.
I haven’t tried this out but I wanted to draw some more attention to it and encourage people to have a look. It looks like a fairly large amount of effort using SimplicityHL.
Χάρων, if you’re reading this, feel free to join the forum and talk about your project here!
Yeah, Χάρων is an individual developer who will maintain this Dapp project but various business applications are going to be developed by Standard Sats.
I was initially puzzled by the frozen contract and CMR because the contract incorporates details of the identity of trusted oracles. So it seemed that the oracles must already have been selected in order for the contract’s CMR to be frozen. That was the main missing detail in the existing contract presentation from my point of view. I haven’t checked back to see whether any more detail about oracle identities (and how to build or deploy the contract) has come out.
Hi, Charon here (public key at https://styx.network/charon.asc)The frozen version contains compile-time placeholders for parameters like oracle identities. SimplicityHL automatically inserts them when compiling the covenant. All parameters required can be found in the ceremony configuration that defines the instance of the protocol. So, ceremony config + covenant is constant across the instance of protocol. The freeze of the template is about detection of protocol drift, so self testing can detect that something went wrong.
-----BEGIN PGP SIGNATURE-----
One thing you might try is txmanifest (see txmanifest cookbook and txmanifest-wallet). Basically, you would write a certain JSON file that describes the details of how to interact with the contract, and then an ever-growing list of Simplicity-compatible wallets would, if their users trusted and imported that JSON file, become able to interact on-chain with instances of the contract.
This is being developed by @stringhandler, and getting Styx to work with it could also expose missing features or rough edges in txmanifest itself. It would be a benefit to our ecosystem to have that kind of feedback.
It doesn’t necessarily address the whole UI or discoverability question, but it might be a great step toward wallet compatibility. (The txmanifest-wallet project is not meant to be the only compatible wallet, but rather a reference implementation for experimentation purposes.)
Thanks fro suggestion.
Looked into it, it seems that TxManifest could work indeed. However, we are mostly interested in browser based wallets or zero-setup solutions that could be achieved with external signers or protocols like Account Abstraction.