The Ascension Foundation's technologies are second generation cryptocurrencies that use a highly secure hybrid of blockchain and off-blockchain fintech to provide a feature-rich environment for payments, atomic swaps, p2p exchanges, and private in-wallet marketplaces. The Ascension Foundation is able to combine blockchain technology with the technology layer provided by Voucher-Safe and SilentVault.Designing for the FutureOur wallet and payment clearing network, which is built using Voucher-Safe technology, sits on top of the Ascension blockchain (also other blockchains), and provides transaction settlement that is fully scalable, equally untraceable as physical cash, and practically instantaneous. Note that this technology already exists , and accomplishes essentially everything that is hoped for from Lightning networks, or Lumino, and more. While functionality is distributed between servers with distinct functions, software updates are always controllable.
This higher level wallet payment network is “money agnostic,” meaning that it allows any kind of currency or asset to circulate invisibly in the form of digital cash, such as cryptocurrencies, precious metals, even stored fiat currencies. Each digital voucher currency is emitted by an independent Issuer, which is free to follow its own individual reserve and monetary policy, and is entirely separate from the payment clearing engine.
Our user client architecture is lightweight, provides access to private keys only on the user's own device, and can access only the wallet's own transactions. Transaction receipts are seen only by payer and payee, and can be permanently deleted. Because the protocol travels over XMPP, it provides innate connection encryption and a superior resistance to protocol-based detection and interdiction, along with end-to-end encryption and easy access to intra-community messaging (since wallet clients are also chat clients).
Our SilentVault Exchange (SVX) and SilentVault Marketplace (SVM) architectures and APIs (built using SilentVault technology) provide p2p asset exchange with escrow (in the future possibly including atomic swaps between blockchains), and independent Marketplace applications accessible from right inside the wallet. These Exchanges and Marketplaces are meant to be individually owned and operated, much like franchises or stores in an electronic mall, leading to a robust economic ecosystem, decentralized by means of its business model. In this way as the total ecosystem grows, it becomes more decentralized rather than less.
Our Ascension blockchain will be permissioned. Validators (miners) will be franchised out to multiple parties under contract in various parts of the world, thus providing adequate censorship-resistance under a PoW system, plus eliminating all possibility of the dreaded “51% attack.” Validators will also be connected together across a special-purpose VPN for improved security. Timely installation of software updates by validators will be made a contractual requirement. User blockchain clients will be limited to client-only functions: reading blocks or submitting coin transactions for validation. However our expectation is that most wallet transactions will continue to take place at the voucher level, even after the Ascension blockchain launches. The voucher level is completely permission-less. Publication of smart contracts (assuming these are supported) will require validator-level permissions, with pre-approval by Ascension. This provides a revenue source for Ascension.
The Ascension Foundation will be able to administer monetary engineering for its own blockchain, and thus also for all of its special-purpose sub-currencies backed by its Lyra blockchain coins. The existing OTO (“overcome the odds”) voucher cryptocurrency, introduced in late 2016, is 100% backed by Lyra coins, and will remain exchangeable at 1:1 with those coins even after the genesis block is initialized. Other currencies used in our Marketplace DApps (such as InsurBucks, SportsBucks, TradeBucks, or Quantz) may have a fractional backing versus Lyra. Additional Lyra on the blockchain can be minted in any given block. The Foundation can also repurchase Lyra coins and transfer them to a sequestered address block it controls, where surplus Lyra can be held. (Note however that on a blockchain, coins never go out of circulation once minted.) This will allow the Foundation to adjust available monetary supply as required to avoid any inherent inflationary or deflationary bias. The idea is to balance supply and demand for the currency, as indicated by longterm coin price trends versus a basket of external assets. It should be noted that currency growth occurring in our DApps is conducted in a manner intended to squeeze out risk from betting and trading applications. By building out both the ecosystem demand for coins and the coin supply at the same time, the goal is to create a stable, private money that allows growth with low volatility – something the world has not seen since the years of the classical gold standard prior to WWI.
The governing board of the Ascension Foundation will also act as a steering committee to make decisions on direction and vision as the system grows. It should be noted that our charter members have been involved in the alternative payments industry since the days of digital gold currencies, a decade or more before Bitcoin was proposed.
To provide funds for future development, and the implementation of its monetary engineering goals, the Ascension Foundation will raise money principally in two ways:
1. Through the sale of its existing OTO voucher currency (representing claims upon an equal number of future blockchain Lyra coins), during a presale, followed by a series of rounds offering progressively more coins at progressively smaller advance discounts. This sale will be uncapped and is thus not truly an ICO, but is rather a release of coins to be circulated in the ecosystem being developed. OTO will not be marketed to the public directly, but only by means of referred introductions through an affiliate marketing program (not multilevel).
2. By charging fees for licenses and franchises to independent businesses. This includes selling rights to operate DApps inside the in-wallet Marketplace (or on the blockchain itself), SVX franchises, rights to operate independent voucher currency Issuers, voucher network gateway servers, and possibly even licensing of the complete server and/or blockchain software itself. These application and licensing fees will be payable only in OTO (or equivalent Lyra coins) . The Foundation will also offer consulting and software development services to its business partners, likewise payable in OTO/Lyra.
By design, OTO presale vouchers are a privately issued virtual currency and not a commodity or security. We will delve into this in detail below, but for now observe that there is no investment in a common enterprise. While speculative profit is certainly possible, earnings of commissions by sales affiliates are naturally proportional to their own efforts; while future profits of independent businesses who join the ecosystem (e.g. to operate Marketplace stores) are necessarily dependent upon their own custom software development, successful marketing, and profitable execution on their own individual business plans. Token sales do serve the purpose of recruiting a base of customers holding the currency, representing a pool of potential future demand. (This same phenomenon has been observed with Ethereum vis-a-vis ICOs.) However the future value of our coins will depend as much upon the success of individual competing businesses serving that pool of demand, as it does upon the efforts of the Ascension Foundation itself. It should also be noted that other cryptocurrencies besides our own (e.g. bitcoin, litecoin) are already circulated within our wallet system, and that our “secondary market” to date is entirely internal.
Our architecture confines government monitoring, regulation, and licensing narrowly to the level of the currency Issuers and separate wholesale fiat exchanges, which is where it belongs. Each Issuer will comply with the applicable rules for virtual currencies in the jurisdiction where it is established. This protects the ecosystem at its interfaces with the legacy banking system.
Best of Both WorldsMining on the Ascension blockchain can be used to mint coins and validate transactions, including smart contracts. Because a permissioned blockchain will be utilized, the mining function will be contracted out to sufficient geographically dispersed pools to provide adequate decentralization. (User clients will be able to run full nodes that do not mine.) This eliminates problems with hard or soft forks, uptake of software updates, and the dreaded 51% attack. All mining pools will operate under a binding business contract with the Ascension Foundation.
Blockchain cryptocurrencies are often called digital cash, but this is a misnomer as they do not exhibit the characteristics of physical cash, specifically fungibility and anonymity. But cryptocurrency circulating in voucher form (not just Lyra but also BTC, LTC, etc.) is in fact true digital cash, which works analogously to physical cash. Just like a billfold, a wallet can contain many different voucher types side by side. Wallets cost nothing to create, and absolutely no identifying information attaches to them, not even an email address.
Because the voucher network is already deployed, purchasers of OTO vouchers can take possession of their OTO immediately, and circulate them to others, before the Ascension blockchain is even initialized with its “genesis” block. (This is an ongoing project with a white paper, not a project consisting of a white paper.)
The voucher network can scale as required simply through the addition of more hardware, and possibly also via future software changes to optimize clustering. In this characteristic it is similar to other systems with centralized clearing, such as PayPal or Visa.
“DApps,” or distributed applications, can be deployed right inside the wallet client by implementing to the SVM API, eliminating the need for websites which can be shut down, or domain names which can be seized, or external “app stores” where certain kinds of apps (e.g. crypto wallets) may not be welcomed. All client code has published source, including plug-ins to support the client side DApps. The Ascension Foundation may also permit certain DApps to create additional OTO supply (on the server side), and add it to the total in circulation according to stipulated rules.
Most cryptocurrency wallet clients have no chat capabilities, or at best a crude one bolted on as an afterthought. The wallet clients used for OTO originated as open source instant messaging clients, to which special-purpose plug-ins have been added in order to support wallet operations. This means that OTO users can not only spend to one another, they can also chat with one another, either one-on-one or in chat rooms. Secure chat is supported using OTR (Off The Record). Drag and drop file transfer, bookmarks and contact lists, and a host of other standard instant messaging features are also supported. (Even p2p voice chat can be supported, but isn't configured yet.) Our user community is meant to grow as a community, and our tools are designed from inception to facilitate this growth.
Our network was not designed as a lab experiment, but rather from a business perspective, informed by the history of the digital gold industry in the 2000s, and earlier ledger systems such as Loom and Truledger. The fact that there are economic incentives for all of the entities, which have logically separate functions, allows for competition and decentralization via the business model, while still preventing the “tragedy of the commons” issues that have plagued Bitcoin. This avoids single points of failure or censorship, while allowing the Ascension Foundation to steer future technical development and monetary strategy for its own currency(-ies). Naturally, other currency Issuers on the platform can of course do likewise.
In-Wallet Exchange & MarketplaceMost 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 (Merkelized 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 plug-in developed by the SVM DApp operator, who also creates the plug-in for the server side. Source code for client plug-ins must be published; source publication is optional for the server plug-in.
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.
Ascension BlockchainThe Ascension blockchain will be forked from the latest open source version of a first generation blockchain. The most likely candidates for this, in descending order are: Ethereum Classic (ETC), Ethereum (ETH), Bitcoin (BTC). ETC retains a PoW mining mechanism, and will not be transitioning to PoS through the adoption of Casper. Bitcoin does not support Turing-complete smart contracts, but basic contract types are available through Ivy. However it does support recording non-transaction data in the public ledger (as exploited by Factom, among others.)
There are also projects meant to bring smart contracts capabilities into Bitcoin, such as RootStock. Given that we are ambivalent about the wisdom of supporting Turing-complete executable code on a blockchain to begin with, we may elect not to support smart contracts. At the very least they will be will be very tightly controlled (as described below), if they are supported at all. Even the adoption of SegWit presents a minor problem in that it makes it impossible to validate a blockchain transaction after the fact without reference to separately stored extension blocks. This is plainly sub-optimal unless block space limitation is a problem, as it was for BTC (but will not be for us).
In any event, whichever starting point is ultimately selected, we will then customize the functioning of that blockchain's software to implement the following operational parameters:
1. The validation (mining) of blocks will only be accepted from network nodes which meet these criteria:
a. are in possession of a signing key whose corresponding public key is on a list of authorized validators; and
b. submit their block from an IP address on a private VPN.
2. All mining nodes will also offer public-facing IP addresses for connection by non-validator client nodes, discoverable via the usual DNS seeds mechanisms. Messages between validating nodes will always travel over the VPN, in order to improve security, and evade national firewalls and potential packet censorship. (A VPN failure fallback to public IPs is allowed.)
3. Mining pools (hereinafter just “miners”) will be under a legally binding contract with the Ascension Foundation (AF). Per the terms of this contract, they will provide to the network a specified minimum amount of hashing power, with a reasonable uptime guarantee. They will adopt and install software upgrades on a schedule stipulated by the AF. Miners will be established on all continents except Antarctica, in sufficient numbers to provide adequate redundancy and censorship resistance. VPN access will be provided to them by the AF.
4. Miners receive block transaction fees for the blocks they mine, but will not receive block rewards when they mine a block. Instead, each miner will be paid a fixed sum of Lyra (the coins used on the Ascension blockchain) each day they are online, calculated as a prorata share of the AF daily mining budget, based on the percentage of total network hashing power being provided by that miner. The AF will recalculate its mining budget periodically, based on such factors as changes in total hashing power, number of miners under contract, and the price history of Lyra versus a basket of other currencies.
5. Miners will agree not to mine any other cryptocurrency, including merged mining, using the same dedicated hardware they are providing to the AF network. They may mine other currencies as they like using entirely separate hardware. This proviso should eliminate the problem described here.
6. Minting of new Lyra shall be conducted by the AF exclusively. This shall be done by means of a 'mint directive' message broadcast to miners, specifying the number of new coins to be created in an upcoming block (by default, the next block). This message must originate within the VPN and is a multi-signature transaction which must be signed by a majority of minting keys, established for this specific purpose, which are controlled by the AF board. This number of coins effectively becomes the “block reward” for the indicated block, with the distinction that the new coins will be paid to an address also belonging to the AF, instead of to the winning miner. (As noted above, miners do earn and retain the fees for transactions in a block.)
7. When the Ascension genesis block is created, the number of coins specified in the very first 'mint directive' will specify, at minimum, an amount of coins equal to the total quantity of OTO vouchers then in circulation, plus the required backing for any other voucher currencies backed wholly or fractionally by Lyra. Thereafter the quantity of Lyra minted over time will reflect increases in circulating OTO and related (Lyra-backed) currencies, together with the implementation of the monetary goals of the AF board. It is likely that most blocks will lack a minting directive associated with them, thus the number of new coins per block will often be zero.
8. Block size will initially be set at 1MB, with blocks occurring on average every 60 seconds. Given the available hash rate across all miners, the difficulty will be manipulated as required in order to maintain the desired block rate. Difficulty can be auto-adjusting, or explicitly set by AF. Block size can only be changed by means of a scheduled software update, to take effect as of a specific block number.
9. Blockchain wallet clients operated by users (defined as any node without validator permission) will connect to public-facing IP addresses of miners, and of one another. All TCP/IP connections will be secured via TLS using self-signed certificates. (The point here being to transmit data over encrypted connections rather than to authenticate anonymous parties.) TLS will also be supported for RPC/JSON connections. User clients will be able to download all past blocks, and submit transactions to the network, denominated in Lyra, with fees also offered in Lyra, in the usual manner. A suitable threshold for minimum spends and/or fees may be specified in the software, in order to prevent nuisance dusting attacks. While users will not be required to install every software update released by the AF, wherever the changes in a new release require it, the Satoshi number of releases below a certain level will no longer be accepted when connecting to other nodes which have upgraded. Users with too-old versions will be notified that they need to update their software.
10. Smart contracts (defined as any code posted to the blockchain meant for execution by other clients), can only be submitted into a block using a signing key duly authorized permissions.
11. In order to implement the permissions system outlined above, a versioned permissions block will be posted on the blockchain, and periodically updated. Each version of this JSON block will specify the list of public keys whose corresponding private keys are associated with particular permissions. For example, the keys belonging to the members of the mining pool, the keys permitted to publish smart contracts, the keys belonging to the AF for use in official mint directives, etc. Each permission block will specify the block number at which it becomes effective. Like mint directives, permission block updates must be signed by a majority of master keys belonging to the AF (whose fingerprints in this case are also hard-coded in the software). This mechanism allows for miners to enter or exit the system, for example.
12. The OTO voucher Issuer (OTO.Money) manages ordinary client wallets holding at all times sufficient Lyra to back fully (100%) all OTO vouchers currently in circulation. When OTO is sold to the public, OTO.Money will purchase enough Lyra from the AF to cover any shortfall. The AF will satisfy the purchase either by transferring existing Lyra from wallets it controls to OTO.Money's wallets, or at its option create the new Lyra first via a mint directive, and then spend it to OTO.Money. Whenever a voucher wallet user redeems an OTO voucher for Lyra, OTO.Money will destroy (decirculate) the surrendered voucher and spend an equal amount of Lyra from its blockchain wallet to that of the redeeming user. Any additional voucher Issuers, now or in the future, who back their currency with Lyra, will operate in a similar manner. The AF will require periodic audits of Issuer reserves. Thus this is shown on the chart as a legal contractual relationship.
13. A voucher Issuer such as OTO.Money may utilize an SVX as a sales portal to privately receive BTC, LTC, or other cryptocurrencies as payment for vouchers sold. They may also designate independent sales agents, such as CryptoWealth.com, to help them conduct their business. Regardless, the relationship at the blockchain level will remain between the Issuer and AF. The AF will monitor market conditions in order to make periodic adjustments to hash rate, mining budget, difficulty, block size, and the Lyra growth rate. The goal is stable liquidity. A payment system needs stable liquidity, and that stability cannot be reached if you aim to be a payment network before you are an established asset. Operating the Ascension blockchain and surrounding ecosystem according to these rules and guidelines should facilitate the fulfillment of our mission statement: “To promote the growth of robust, borderless, wealth-generating, free market ecosystems.”
LYRALyra is a peer-to-peer digital currency enabling the Ascension ecosystem to grow organically through a unique and innovative bottom-up monetary issuance model.Application Insurance Capabilities Lyra provides access to Ascension utility applications with insurance capabilities to protect the holder's principle. The insurance coverage, when exercised, issues newly minted Lyra, creating a demand-based distribution of wealth.
Growth Immediately upon purchase, holders can deploy their Lyra through CryptoWealth managed account services. Future development will allow Lyra holders to self-manage their accounts by using the Ascension applications directly.
Off-Blockchain Voucher SystemThrough SilentVault and its proprietary Voucher-Safe technology, Lyra is easily stored, traded, and spent via our advanced, secure, scalable payment system.
Merchant & BusinessAscension's SilentVault Platform facilitates the secure sending and receiving of Lyra, as well as allowing direct communication with customers through the platform's built-in P2P encrypted messaging system.
Early Lyra Purchase Benefits:-Seed Generation Event discounted prices with bonuses
-Access to managed account applications for Lyra enrichment
Visit
http://ascension.foundation for more information
Visit
https://cryptowealth.com to pre-register for Lyra Seed Round
Visit
http://www.travelcashinc.com to see our technology deployed
