Voucher-Safe, a Next Generation Digital Currency – Part II

Part I looks at the motivation behind Voucher-Safe, the evolution of digital currency and how Voucher-Safe transactions work.

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.