In-Wallet Exchange & Marketplace |
|
Most cryptocurrencies rely upon external exchange platforms (example: ShapeShift) in order to trade versus other cryptocurrencies, or against national fiat currencies. Because our technology is money agnostic, and therefore can make circulating digital value out of anything, we are able to achieve this capability internally. We have developed an anonymous p2p exchange API with escrow backing, and deployed it on a separate tab inside our existing wallet client. At present there is a single “SilentVault Exchange” operating (SVX1), so the drop-down list in the wallet offers but a single choice. In the future independent operators will be able to operate their own exchanges on this list. They will compete with each other on the basis of price (escrow fees) and voucher currencies supported. In this way the user community wins twice: first, by obtaining the best service for the lowest price; and second, by providing decentralization via the business model.
By agreement with cryptocurrency Issuers within our wallet system, an SVX can also sell (or repurchase) vouchers directly for other cryptocurrencies.
For example the existing SVX1 sells SBC vouchers for BTC, SLC vouchers for LTC, and OTO vouchers for either BTC or LTC. This capability to do automated voucher minting for suitably confirmed payments on one of several blockchains is an integral part of the SVX API. Future SVX franchises could in theory be dedicated to acting as a portal for conducting an ICO, even for a blockchain that (like Ascension) does not yet exist. The only implicit requirement would be that the vouchers so created would be redeemable for an equivalent quantity of coins on the blockchain once it is launched (as OTO vouchers are redeemable for Ascension's Lyra coins).
The SVX API can of course be extended in the future. In particular, once the Ascension blockchain has been initialized it will become possible to add support for “atomic swaps” between the Ascension blockchain and other blockchains. An atomic swap is a mechanism by which coins are spent on one blockchain, but cannot be spent by the recipient until a corresponding spend of coins has been made on the other blockchain (or a timeout occurs, reversing the spend). Basically, Alice spends coins to Bob on blockchain A, but Bob cannot move those coins until he makes a corresponding spend of coins on blockchain B to Alice. The main problem with this mechanism is that it isn't at all private; the spends on both blockchains are publicly associated. (For that matter, all exchanges performed via ShapeShift are published as well.) It is conceivable that protocol changes could be made to Bitcoin and other blockchain currencies, which would alleviate this concern. For example, MASTs (Merkleized Abstract Syntax Trees) could be deployed to make atomic swaps have an acceptable level of privacy protection. But in the near term it seems clear that p2p exchanges will continue to play a major role, even if fully decentralized exchanges become a reality. Our SVX technology is p2p today and will evolve toward full decentralization in the future. (We consider decentralized exchange a “killer app” in itself.)
We have also developed a Marketplace API. The SilentVault Marketplace (SVM) API defines messaging protocol mechanisms for basic functions such as connecting to a Marketplace app, logging into it securely (via wallet ID + a PIN), and transferring value (in supported voucher types) between the wallet and an account in the Marketplace DApp. Each SVM DApp may extend this base set of message definitions to access its unique functionality.
Client support is provided by a special plugin developed by the SVM DApp operator, who also creates the plugin for the server side. Source code for client plugins must be published; source publication is optional for the server plugin.
We have written and beta tested a coin-flipping game using a modified Martingale wagering algorithm. This SVM DApp is called “ABC” (for Aleatoric Binary Challenge), and is presently deployed on our test network, with live deployment expected in the next few months. This is a complex but amusing betting game based around the concept of betting insurance, in which if you win you win bitcoin, but if you “lose” you win OTO. Significantly, OTO is created to “make whole” those who go bust under the Martingale strategy. ABC is thus an example not only of the sophistication that is possible using our in-wallet API, but also of the concept that expansion of the monetary base ought to occur from the bottom up (individual users), rather than from the top down (governments, banks). Naturally, there are built-in guardrails to ensure that monetary growth from this source will never become excessive.
We do not anticipate that the Ascension Foundation should or would develop the majority of future SVM applications. On the contrary, the intention is for third-party vendors to purchase SVM franchises and develop their own applications: stores, other games, possibly trading and investment markets, various services, virtually any business proposition that can be represented in an electronic mall. As our user base grows, the value of an entry in our wallet Marketplace drop-down list will increase. Also note that more than just our own currencies such as OTO/Lyra are in play within the SVM.
For example, SBC/BTC and SLC/LTC are already supported. OTO/Lyra is pegged to the current retail market price within SVM DApps. Our job is to provide the mall and maybe an anchor store or two, and then let other entrepreneurs do the rest. (Ideally, our “anchor stores” would themselves be spun off to independent owners in the future.) Nevertheless we do plan to develop in house a few more SVM DApps.
These will include:
HOME
By agreement with cryptocurrency Issuers within our wallet system, an SVX can also sell (or repurchase) vouchers directly for other cryptocurrencies.
For example the existing SVX1 sells SBC vouchers for BTC, SLC vouchers for LTC, and OTO vouchers for either BTC or LTC. This capability to do automated voucher minting for suitably confirmed payments on one of several blockchains is an integral part of the SVX API. Future SVX franchises could in theory be dedicated to acting as a portal for conducting an ICO, even for a blockchain that (like Ascension) does not yet exist. The only implicit requirement would be that the vouchers so created would be redeemable for an equivalent quantity of coins on the blockchain once it is launched (as OTO vouchers are redeemable for Ascension's Lyra coins).
The SVX API can of course be extended in the future. In particular, once the Ascension blockchain has been initialized it will become possible to add support for “atomic swaps” between the Ascension blockchain and other blockchains. An atomic swap is a mechanism by which coins are spent on one blockchain, but cannot be spent by the recipient until a corresponding spend of coins has been made on the other blockchain (or a timeout occurs, reversing the spend). Basically, Alice spends coins to Bob on blockchain A, but Bob cannot move those coins until he makes a corresponding spend of coins on blockchain B to Alice. The main problem with this mechanism is that it isn't at all private; the spends on both blockchains are publicly associated. (For that matter, all exchanges performed via ShapeShift are published as well.) It is conceivable that protocol changes could be made to Bitcoin and other blockchain currencies, which would alleviate this concern. For example, MASTs (Merkleized Abstract Syntax Trees) could be deployed to make atomic swaps have an acceptable level of privacy protection. But in the near term it seems clear that p2p exchanges will continue to play a major role, even if fully decentralized exchanges become a reality. Our SVX technology is p2p today and will evolve toward full decentralization in the future. (We consider decentralized exchange a “killer app” in itself.)
We have also developed a Marketplace API. The SilentVault Marketplace (SVM) API defines messaging protocol mechanisms for basic functions such as connecting to a Marketplace app, logging into it securely (via wallet ID + a PIN), and transferring value (in supported voucher types) between the wallet and an account in the Marketplace DApp. Each SVM DApp may extend this base set of message definitions to access its unique functionality.
Client support is provided by a special plugin developed by the SVM DApp operator, who also creates the plugin for the server side. Source code for client plugins must be published; source publication is optional for the server plugin.
We have written and beta tested a coin-flipping game using a modified Martingale wagering algorithm. This SVM DApp is called “ABC” (for Aleatoric Binary Challenge), and is presently deployed on our test network, with live deployment expected in the next few months. This is a complex but amusing betting game based around the concept of betting insurance, in which if you win you win bitcoin, but if you “lose” you win OTO. Significantly, OTO is created to “make whole” those who go bust under the Martingale strategy. ABC is thus an example not only of the sophistication that is possible using our in-wallet API, but also of the concept that expansion of the monetary base ought to occur from the bottom up (individual users), rather than from the top down (governments, banks). Naturally, there are built-in guardrails to ensure that monetary growth from this source will never become excessive.
We do not anticipate that the Ascension Foundation should or would develop the majority of future SVM applications. On the contrary, the intention is for third-party vendors to purchase SVM franchises and develop their own applications: stores, other games, possibly trading and investment markets, various services, virtually any business proposition that can be represented in an electronic mall. As our user base grows, the value of an entry in our wallet Marketplace drop-down list will increase. Also note that more than just our own currencies such as OTO/Lyra are in play within the SVM.
For example, SBC/BTC and SLC/LTC are already supported. OTO/Lyra is pegged to the current retail market price within SVM DApps. Our job is to provide the mall and maybe an anchor store or two, and then let other entrepreneurs do the rest. (Ideally, our “anchor stores” would themselves be spun off to independent owners in the future.) Nevertheless we do plan to develop in house a few more SVM DApps.
These will include:
- Q13, a simplified ABC variant also using the InsurBucks insurance currency concept. (A simulator for this application already exists.)
- SportsTrader, a p2p sports betting app, featuring the SportsBucks currency.
- A Binary Options trading app, featuring the TradeBucks internal currency.
- A CFD (contract for difference) trading app, again utilizing TradeBucks for insurance.
- Other similar iGaming or trading concepts may be realized, depending upon the success of these.
HOME
