Part II  examines the Voucher-Safe economy, trust, security and software.

This final part looks at Voucher-Safe’s interaction with Bitcoin, Issuers and OnionPay.

Bitcoin

The idea behind voucher-safe is that money can be anything that people value and want to exchange.  Money can be national fiat currencies, silver or gold and increasingly, Bitcoin. Bitcoins can be exchanged via the Voucher-Safe system with the creation of Bitcoin backed Vouchers.

One of the benefits that Bitcoin backed Vouchers have is increased anonymity.  Voucher-Safe’s principal developer Kevin doesn’t see Bitcoin as anonymous.  “You actually see people offering to sell bitcoins that are free of taint now. Because taint means there are certain payment hashes that have been used for criminal activity or looted bitcoins … And because everything is recorded on this massive block chain, it’s like a chain of titles… And so if you end up with a house or car that has been owned by a criminal it casts a taint on your property. And that’s a horrible problem for the Bitcoin block chain.”

Kevin sees a solution to the block chains problems in Vouchers. “If you bailed bitcoins into a Voucher-Safe Issuer that issued Vouchers against bitcoins, they could circulate in the wild without having any foot print in the block chain whatsoever, except in what was created when the bitcoins actually moved in or out of the Issuer. I really think that would be a huge improvement and would solve one of Bitcoin’s biggest problems.“

Kevin sees further benefits adding, “Circulating bitcoins in voucher form would also eliminate problems with clearing times and transaction dependencies, which arise from the fact that bitcoins actually exist in blocks of 20 whole coins. This means that when some of the coins in a block are involved in uncleared transactions, it prevents any other coins in the same block from clearing until the earlier transactions are closed. Bitcoins carry the full transaction history of every coin. Vouchers are always destroyed and replaced any time they are used in a transaction, so they can carry no history.”

A Voucher Issuer for Bitcoin is being discussed.

Issuers

At the heart of Voucher-Safe are the Issuers who put the currency into the system.

One of the first Voucher-Safe Issuers will be PXGold. The business is run by the creators of Pecunix and they hope that Pecunix’s good reputation is also applied to the new business. However, PXGold is a separate entity and will have no direct connection to Pecunix.

As an Issuer PXGold will issue gold backed Vouchers and maintain 100% backing for all their Vouchers.  However, they will not make the location of their gold vaults public. The reasons behind this move is explained in part II.

When demand becomes sufficient to justify it, PXGold plans to do a run of PXGold Medallions, which customers will be able to take delivery of in exchange for their PXGold Vouchers. The business will work with Vouchi.com, the current Voucher-Safe publisher.

There is currently one active Voucher-Safe Issuer, voucher-issuer.com. The site issues Vouchers backed by USD and EUD. The decision to have the first Issuer back their Vouchers with national fiat currencies is explained by Sidd. “People need to come to terms with the fact that these Vouchers can be used as a payment system to pay each other and used as real money. Not just as vouchers to claim back whatever is backing that system. “

“When I’ve spoken to people, often the reaction is that we’ve created this voucher system where the vouchers are for gold. And they say ‘that’s great, so if I want to give my aunty some gold I can give her a voucher.’ And I say yes but you can also buy her a pair of shoes with that Voucher by paying for it with a Voucher. And you could be paid in Vouchers. And that seems to be a difficult problem for some people. And that’s why we are considering an issue with USD and Euro’s, so that they can see that well one Voucher is equivalent to one Euro, that makes sense to me. “

Plans are also in the works for two more Issuers, one for silver and another for Bitcoin.

Issuers and KYC

Any Voucher-Safe Issuer who intends to interface with the fiat banking system will need to be KYC compliant and require ID from their customers. Not doing so would be a violation of AML laws and would risk a shutdown of the business.  However, there are options for obtaining Vouchers anonymously. An obvious choice would be to receive one in trade with an existing Voucher Issuer customer. There is also the possibility of an Issuer which does not interface with the banking system and is not subject to KYC rules.

It is possible to have an Issuer which only trades its assets in exchange for other types of Vouchers or anonymous digital cash.  For example, suppose an Issuer existed for a metal-backed Voucher currency which only bought or sold the metal using Bitcoin. That Issuer could likely get away with not requiring ID from its customers.

OnionPay

OnionPay (The name is a “humorous tip of the hat” to Tor) is add on software for the Voucher-Safe system.  It is essentially a Voucher-Safe based PayPal alternative for e-commerce websites. OnionPay is intended to provide a more traditional merchant checkout experience for websites that accept Voucher-Safe.

The Voucher-Safe payment process involves a few steps; the sender has to send and then the receiver has to pick up. “Well how is that going to work if the receiver, the payee, is actually a website?” OnionPay solves this problem.

As Kevin explains, “the way it works is that it borrows a concept from public key cryptography where you have a public key that you give to everybody and you have a private key. Only here you have a public Voucher-Safe and a private Voucher-Safe.”

To use OnionPay, an e-commerce website would set up what amounts to a merchant account with OnionPay. The service creates a public safe to which both OnionPay and the merchant have joint access. This provides the merchant with a payment gateway that allows customers to check out. The customer can make a Voucher payment that goes to the public safe. OnionPay then logs into the public Voucher-Safe, picks up the payment, confirms that it is the correct amount and then takes the customer to the success page back on the merchant’s website.

After sending a message notifying the merchant of the payment, OnionPay sweeps the money from the public safe to the merchant’s private safe. “This keeps the merchant from actually having to trust OnionPay with any of their money unlike PayPal where it sits there in your account until you withdraw to a debit card or take an ACH payment.”

Auto Exchanger

A planned additional feature of the Voucher-Safe system is an auto exchanger or escrow system.  As Kevin explains, “We used to have this kind of functionality with something called Open to Exchange. And this was back in the day when people wanted to exchange between e-gold and Pecunix, etc. It was mostly exchangers who used it when they had too much of one and not enough of another. But in theory, this is something that can be done by anyone. I think there is room for a lot of synergy there in terms of people using different kinds of Vouchers and being able to exchange with each other.”

“So one of the easy things that we would be able to do is to create an auto exchanger that would act as the escrow system, it would probably be an Onion Pay merchant, that would let people exchange all these different things as anonymous digital cash without ever having to go through an exchange. So for example, you have a Bitcoin Voucher and you want a Dollar Voucher, you just post that on this site for someone who wants the reverse of that trade. Then each of them pays their Voucher to the middle man and he reverses it.”

While the Voucher-Safe system is designed to allow anything to be money, the system offers one of the best options for those who want to transact in gold, silver, etc. Voucher-Safe is about as de-centralized as you can get while still being able to transact with real assets. The system is a versatile, more decentralized, Anti-Money Laundering compliant way to anonymously exchange value. It is a smarter, more resilient generation of digital currency.

In this part we examine the Voucher-Safe economy, trust, security and software.

The Voucher-Safe Economy

“One of the things that occurred to us as being necessary in order to have a robust economy, is that the people who are operating the servers need to get paid for doing that.”

All of the players in the Voucher-Safe economy, the Publisher, DHT (Distributed Hash Table) server, OFS gateway, SDS (permanent database) server, etc. are in the business of earning tokens. As Kevin explains it, “you can think of tokens kind of like micro Vouchers, which are backed by Vouchers which are in a special Voucher safe.”

Tokens are created by the Publisher, from backing Vouchers, and are sold to Voucher-Safe users. “What is silently going on here in the middle of all these payments, pickups, storing receipts and so on, is that all these charge some number of tokens. For example, it costs a token to store a receipt, and it also costs tokens to make payments or to pick them up.”

Once the players in this system, for example the OFS gateway, accumulate a certain amount of tokens they can redeem them for Vouchers. The OFS gateway operators would initiate an exchange with the Voucher Publisher and say ‘ok, I’d like to cash in my tokens.’ Those tokens are then taken out of circulation and the Publishers Voucher safe, where the users who have been buying the tokens have been placing Vouchers, is debited to create a new Voucher. This new Voucher is then paid to a special safe which is owned by the operator of the OFS server.

This method encourages the OFS gateway, and other server operators, to be very careful about which Issuers and Publishers they do business with. Kevin explains that this is an intentional incentive. “Basically what this boils down to is that the publisher and all of the other servers are getting paid in the same issuer’s currency. You wouldn’t want to accept any Issuer that you didn’t have confidence in because this is how you are making your money as well.”

It is also important to note that “the number of tokens is fixed by the publisher but the value of a token is fixed by the Issuer.” For example, an Issuer may set the of value of a token at .005 grams of gold, about 2 ½ cents.

“And that means that although it gets divvied up in different ways, the total cost of a payment is about 47 & ½ cents. About 2/3 of that is paid by the payer and the other by the receiver. 50 cents or less to make a payment and that’s regardless of the amount of the payment. As the same amount of work has to be done and the same operations have to take place whether your payment is for 5 clams or 5 million clams.”

How does a user obtain, exchange and ‘redeem’ Vouchers?

There are many ways to obtain Vouchers, an obvious method is to purchase some from a Voucher Issuer.

Voucher-Safe was designed to be an AML compliant, and yet anonymous, digital cash system. The Issuers are charged with maintaining AML compliance.  To purchase a Voucher from an Issuer a user would (dependent upon the policies of the Issuer) likely have to provide ID in accordance with Know-Your-Customer rules. Similarly, if a user wanted to redeem their Vouchers, they would likely have to have an account with the Issuer and provide ID and bank account information.
While most Issuers will likely require ID as they will have to interface with the fiat banking system, Voucher-Safe’s creators do envision Issuers that may not require ID. “It is conceivable that one could have an Issuer which only traded its asset base in exchange for other types of vouchers or anonymous digital cash.  For example, suppose an Issuer existed for a metal-backed voucher currency which only bought or sold the metal using Bitcoin. That Issuer could likely get away with not requiring ID from its customers.”

“But the idea here is that many users wouldn’t need to be ID’d, just as many people can have physical cash in their wallets and purses without needing a bank account. One could imagine ‘Voucher-cashing’ services just like there are check-cashing services.  Also decentralized exchanging operations, along these lines:”

Purchasing a Voucher from an exchange would be like purchasing Bitcoins on an exchange, and it would come with many of the same issues. Kevin notes that “the exchanger issue is a problem for any digital currency. There’s just no way to fix it that I can see other than going to this decentralized model … about dealing in cash and dealing with other people who use the currency. … And it gets around single points of failure such as large exchangers that are doing millions of dollars a day in through put. And I think that kind of thing is ultimately where we are going not just with Bitcoin but with Voucher-Safe and pretty much everything else.”

Plans for the voucher-Safe system include an ‘auto exchanger’ or escrow service.  This service would allow people to exchange between different Voucher-Safe currencies or Vouchers from different Issuers “as anonymous digital cash without ever having to go through an exchanger.”

Another interesting feature of Vouchers that is important to note, is that they expire.

“We didn’t want this to be a money storage facility. We want this to be a transactional system. … The idea is that it is very, very important to make sure that you don’t end up with value that is permanently in limbo. If Vouchers are somehow lost, you can’t just leave that value out there forever. You have to have some way to take it out of circulation.”

What happens to the backing of an expired Voucher will be determined by the Issuers policy. But there are safe guards in place to prevent Vouchers expiring. “Whenever you’re doing a voucher transaction, your client will automatically use the oldest vouchers possible first.”

It is also possible to simply log into your Voucher-Safe every few months and revalidate any expiring Vouchers. This will however cost you a few tokens.

Trust

When dealing with the digital exchange of physical assets, trust is an unavoidable factor. Users of Voucher-Safe, or any currency with a physical backing, have to trust the Issuer.

Voucher-Safe is designed to be as decentralized and require as little trust as possible. But there is no escaping it, you must trust the Issuer.

Issuers will be discussed in detail in Part III, but one of the first Voucher-Safe Issuers will be PXGold.

Reputation is a huge factor in Issuer trust. Sidd, the creator of PXGold and monetary architect of the Voucher-Safe system, is also a co-founder of Pecunix, a well-respected gold custodian. “Pecunix has a good reputation. But at the same time the bottom line is when you bring me the Voucher, can I give you the gold? So far, we’ve been going for 12 years and there’s never been a problem.“

An important difference between Pecunix and PXGold is that PXGold will not make the location of it’s gold vaults public. While this may cause some trust concerns, it is done to protect customers gold from confiscation. “PXGold is based on an entirely different premise.”

Sidd explains the reasoning behind this decision. “With Pecunix, we held audits, we said ‘this is how much gold we’ve got, this is where we keep it, these are the checks and balances, this is how much gold is in the account, etc.’ But we have now got evidence of the danger of that because of what happened with e-gold. Because all of e-gold’s information was out in the open, the government came along and confiscated the gold. They literally took that gold even though it didn’t belong to e-gold, it belonged to the customers.”

“So, when it comes to PXGold, that information won’t be made public. There will be people who know and people who can verify, but it won’t be public.”

Trust in the Issuer is necessary, but very little trust in the Publisher, and other Voucher-Safe players, is needed.

Kevin explains that it “would be very hard for the Publisher to run off with much of anything. The Publisher has zero ability to do anything with Vouchers outside of those presented by a user for a specific transaction.  It cannot determine anyone’s ‘balance.’  It cannot tamper with the values of vouchers, despite being the party who signs them, because Vouchers with incorrect amounts would be rejected at the Issuer.”

“The same can be said about the DHT and SDS operators.  Yes they maintain ‘databases’ but all the records are encrypted using keys to which the server operators have no access.  The worst thing they could do would be malicious deletion, which profits them in no way.  And there are mirrors and backups in place to allow for this possibility.”

Security

PXGold’s security systems are impressive and are an improvement upon Pecunix’s well-known security. “Everything in Pecunix is encrypted, a lot of it is double encrypted. The entire database is encrypted. If our server got stolen by the authorities they wouldn’t be able to make a dent in it.”

Sidd is very seriouse about the security of PXGold “What we’ve done with PXGold, is that every single account is encrypted to its own key and the key for that account is actually that persons login details.” If authorities were looking for information on an individual from PXGold’s database, “they would actually have to come to us with the persons account details before we would even be able to find them in the database otherwise they’re not even searchable.“

“Nobody builds systems like that; I think I’m the only one. I’m a bit pedantic about that.”

Software

The software that makes up the Voucher-Safe system will be published. “Voucher-Safe has published source clients (3 of them). This is not quite the same thing as ‘open source’ because open source technically means that anyone can check in changes.  For obvious security reasons, we wouldn’t want that.  However by publishing the client source, we invite others to create competing client versions white labelled for particular Issuers or even ground up rewrites.  It would be great if someone made one for Android phones, for example.”

“The network source code (for the server side) is not published at this time.  However, every line of code which runs on a user’s computer has source code available, either from us or from the authors of the particular library component.”

The decision to delay the publishing of this code was done for several reasons. Sidd believes it is important to ‘vet’ Issuers and Publishers for the first few years to prevent any shady server operators from destroying trust in the system.  “As it stands now, we will run the only Publisher (vouchi.com) and we will vet every Issuer to make sure that that Issuer is trust worthy. And that way we can, to a certain extent, protect our investment in the software.”

Kevin adds that “ultimately the software for the VP/OFS/SDS/DHT/PKS should be published also, or at least licensed and franchised out to others who will make wise and profitable use of it.”

“In the end it’s about enabling free market money, which is not the purview of a single Publisher, Issuer, or network, any more than it should be the purview of a central bank.”

The final part of the Voucher-Safe special will discuss Voucher-Safe’s interaction with Bitcoin, Issuers and Onion Pay, a Voucher-Safe merchant checkout.

But as DGC’s were starting to take off and be recognized for their many benefits, the rug was pulled out from under the industry with the prosecution of e-gold. The old DGC business model is centralized and vulnerable to seizure, censorship and prohibitive regulation.

The Voucher-Safe system allows for a more decentralized, Anti-Money Laundering compliant way to anonymously exchange value. It’s DGC 2.0, a more flexible and resilient system where anything can be money. “The idea behind voucher-safe is that it isn’t about making just one thing money. Money  can be gold, it can be existing national fiat currencies, it can be bitcoins, it can be silver, it can be anything of value that people want to exchange.”

I recently had some very in-depth discussions with Sidd, Voucher-Safe’s founder (also co-founder of Pecuinx) and Kevin, the principal developer. Voucher-Safe is software and a network that allows for the anonymous and very affordable exchange of the encrypted representation of value. DGC readers will be familiar with Voucher-Safe from the 2011 Industry Overview Issue.

Sidd and Kevin began designing the system when they ‘saw the writing on the wall’ soon after the demise of e-gold.  As Kevin put it, they began discussing how it would be possible to “operate one of these businesses without getting an ankle bracelet like Doug Jackson’s.”

The problem with the old DGC model is that they are account based and centralized.  Kevin recalls “seeing footage of Doug Jackson testifying before congress and actually boasting about how he was able, because it was all in one database, to track every little flake of gold from the first time it was put in the system to every account it had ever been in and so on.“ With an account based system the operator has a record of all transactions and can be held liable for their clients’ illicit transactions. E-gold’s ability to track all transaction through the system was used against them. Having records of all transactions is “absolutely a sucker’s game, particularly if you’re talking about an alternative currency that’s not going to be in good standing to start with simply because it is alternative. You have to separate the payment system from the store of value”

The Voucher-Safe system is designed to do exactly that. The Issuer, who hold the assets, is separated from the rest of the system and has no knowledge of the transactions taking place with the ‘cash’ that it has issued.

The system is modelled after gold backed “claim checks” or receipts. A good analogy would be a gold backed paper currency where you have gold sitting in a vault somewhere and the “claim checks” on this gold then circulate as cash. In this situation, those looking after the gold in the vault have no idea whose wallet that claim check is sitting in. Their only concern is the safe keeping of and accounting for the assets that back those claim checks.  “And that situation has been recreated technologically with Voucher-Safe where the vouchers are a circulating bill and you have digital wallets where different kinds of vouchers representing different assets can circulate.”

It is a complicated process to replicate this situation in the digital world. To understand how Voucher-Safe works you need to understand who the players are. There are three primary players in this system, the Issuer, the Publisher and of course, the users.

The Issuers are the entities holding, maintaining and accounting for the assets that back a particular issue of vouchers. The Issuer is AML compliant. Anyone wishing to purchase assets from the Issuer will need to provide identification and information in accordance with Know-Your-Customer rules. The Issuer is responsible for maintaining those assets and assuring that the amount of vouchers issued is always less than or equal to the assets that they hold. However, the issuer has no knowledge of what their customers may or may not do with those vouchers once they have been issued to them.

The Publisher works with one or more Issuers, facilitating transactions and is an essential part in the payment system. Publishers join the Voucher-Safe network to earn tokens which are in essence mini-vouchers. (This arrangement will be discussed in the next part of the series.)

The users are anyone who is using the Voucher-Safe software to exchange value with other users.

The Publishers and the exchange process are the heart of the Voucher-Safe network. To achieve the goals for the system, it was necessary to find a way for transactions to take place without centralized receipt signing, accounts or transaction records, all while maintaining anonymity. Not an easy task.

Because this process is so important to the functioning of the system, I’ll list the steps in the process. But, for those who don’t want to get bogged down in the technical details, here is an analogy that will hopefully be helpful in understanding the process.

Issuer A is a respected bullion vault and you would like to own an ounce of gold stored in their vaults. You go to Publisher A, who works with Issuer A, you give them $1,700 and you receive a receipt for one ounce of gold. (You can think of the Issuer and Publisher as a private Mint and Treasury.)

You owe Joe some money for some services he has provided and the two of you decide to settle your bill by passing the receipt for one ounce of gold stored in Issuers A’s vault on to Joe.

Joe gives you a lock for which only he has the key.

You then take this lock to Publisher A’s office and ask them to please place your receipt for one ounce of gold in a safety deposit box and give them Joe’s lock to put on the box.

Joe then stops by Publisher A’s office and notices his lock on one of the boxes.

Joe is able to open the box with his key and retrieves the receipt.

You and Joe then give each other receipts for the transaction.

Note: Neither one of you have an ‘account’ with the Publisher. The Publisher never asks you for ID and has no idea who you are. The only thing Issuer A knows is that you purchased one ounce of gold stored in their vault and that they issued you a receipt for the gold. They have no idea that you exchanged this receipt with Joe

In the digital world, this process is much faster, but involves a few more steps.

It is very important to note that the single most important feature of the Voucher-Safe system is the limited information that each player in the process has. This is particularly true of the Issuer who has no knowledge of anything besides vouchers. It knows which vouchers are on the circulation list and it knows about voucher serial numbers and nothing else. It is a “need to know” system.

This limiting of information is done through encryption, so that each player only has access to the information they need, and through anonymous communication via the OFS Gateway. You can think of the OFS as a proxy that hides IP addresses. All user login and payment-related communications happen via the OFS and, of course, the OFS cannot read the contents of any of the messages traveling through its system.

Below is a step by step of the transaction process in the Voucher-Safe system.

• The Payer logs in and all the vouchers in his safe are decrypted
• When the Payer initiates the transaction the client software automatically selects a voucher for payment, starting with the oldest first
• To send a payment, the Payer will need to have the Voucher-Safe ID of the Payee. (This  looks like an email address, but is similar to a Bitcoin payment address)
• The Payer enters the Payee Voucher-Safe ID of the safe that they want payment to go to
• The software creates a message that includes the voucher(s) to be transferred and Payee safe ID and any payment details (a memo field, or baggage fields)
• If there are any payment details associated with the payment, (information in the message that is only for the Payee) then these are encrypted using the Payee’s public key.
• The whole payment message is encrypted with the Publisher’s  public key and signed with the Payer’s private key
• The message is securely transmitted to the Publisher via the OFS
• The Publisher decrypts the payment message and checks the signature from the Payer
• The Publisher looks up the Payee’s safe ID and retrieves his public key
• The Publisher verifies its own signature on the vouchers to be certain that they are unaltered and valid
• The Publisher sends a message detailing the amounts, serial number, and amounts required (if splitting or combining vouchers) to the Issuer via an encrypted communication.
• The Issuer checks that the vouchers are still on the active circulation list (this prevents double spending)
• If there are no problems, the Issuer assigns new serial numbers for the output amounts and sends this information to the Publisher
• The Publisher acknowledges the Issuer and makes the new signed vouchers using the new serial number, while the Issuer retires the old serial numbers and adds the new serial number and amount to its active circulation list
• The Publisher includes the new voucher and the original payment details in a new message which it signs and encrypts to the payee
• Publisher places the encrypted voucher & message on the DHT (Distributed Hash Table) which acts like a safe deposit box in the cloud
• The Publisher places the change voucher (should there be one) back in the Payer’s safe and returns a successful status reply to the Payer
• The message is stored on the DHT with a unique encrypted address that the Payee can find
• When the Payee logs in to his Voucher-Safe (or clicks “refresh”)the software automatically checks the Distributed Hash Table and finds the encrypted message
• The Payment message is collected and decrypted
• Payee now has the voucher, but he needs it to be stored permanently in his safe by having it revalidated and replaced with a new voucher of identical value
• The Payee creates a message that includes the voucher and the Payer’s ID
• The Payee then signs this message  with its private key
• The whole message is encrypted with the  Publisher’s public key
• The message is securely transmitted to the Publisher via the OFS
• Once again the Publisher facilitates the issuance of a new voucher and destruction of the one sent by the Payee.
• The Publisher signs this voucher with its private key and then encrypts it with the Payee’s public key
• The Publisher stores the new encrypted voucher in the Payee’s safe and sends a successful status reply
• After the successful pickup by the Payee, the transaction becomes irrevocable
• If the Payee fails to pick up the payment within the time set by the Payer, then the Payer becomes able to pick up the payment voucher himself (i.e. retrieve it)
• The Payee’s Voucher-Safe software generates a receipt for the Payer, signs the receipt with its private key and places the receipt on the Distributed Hash Table for the Payer to find
• If there were any private payment details, those are included in the receipt data signed by the Payee, along with any optional return memo text

Even this is simply an overview of the process. There is quite a lot happening under the hood, but thankfully the Voucher-Safe software makes the user experience much simpler. You can watch demo videos, or try it out for yourself at Voucher-Safe.com.

For those who are interested in the technical specifics of the Voucher-Safe system, they can be found by creating an account at Voucher-Safe.org. The client source code and API documentation for all components can be downloaded from the site as well.

Voucher-Safe is a secure cloud based system.  Unlike Bitcoin, “there is nothing actually on your phone or on your computer. If your phone should get lost or stolen or arrested by authorities, there is nothing for them to find.” All of the information in the system is encrypted, sometimes twice. “What that means is that no one, including the voucher Publisher, can see what value somebody has. They might see that there are so many rows in the table at this hash for that particular safe, but there is no way to know what those rows represent, or whether they are simply payment receipts.”

Voucher-Safe’s carefully thought out design and payment system make it vastly more flexible and resilient than previous digital currency business models. “We’ve been through generation one of digital currencies now and it’s time for generation two.“

The next parts of the Voucher-Safe special will cover Issuers and assets, the economic incentives of the system, trust in the system, the extensive security procedures, supporting apps and payment software and more.

Part II examines the Voucher-Safe economy, trust, security and software.

Part III looks at Voucher-Safe’s interaction with Bitcoin, Issuers and OnionPay.