Warehouse Receipts

INITIAL UNDERSTANDING

The current system is account-based, meaning that the instruments always refer to assets that are in some account. (That is, even if you are operating cash-free, with no accounts, there is still a server account somewhere containing the backing funds for your cash. This is a security mechanism.)

So if I have a cheque for 10 clams, it's drawn against a clam account, and if the clams aren't there, the cheque will bounce.

Similarly, the cash tokens are also drawn against an account. When you withdraw cash, the server takes it from your clam account, and adds it to the server's clam account for backing cash, and then issues you the appropriate amount of cash. Later on, when someone deposits the cash note, assuming it's a valid note, the server then pulls 10 clams back out of its server backing account, and puts them into the depositor's account. (This is similar to how it works when you exchange in/out of a basket currency.)

Having the server "double" the cash in a backing account is a way of protecting in case of security breach in the token code. After all, even if you have a bad token that slips through, the server still can't give you any more clams than are stored in the clam account. The server can never have more notes out than it has backing assets to cover them. The account would just go empty, which, if the note was still good, would reveal that the token system had been compromised.

As we can see, cheques and cash are very similar, in that they are both merely a mechanism; an instrument to be redeemed that is actually sitting in an account somewhere. Both cheques and cash have ACCOUNT BACKING. The only difference is, the cheques are traceable and they use transaction numbers for invalidating instruments, whereas the cash is untraceable, and it uses a spent token database along with expiring mint series for invalidating instruments.

NOW WE TURN OUR ATTENTION TO WAREHOUSE RECEIPTS...

What if the backing for the [cheques/cash] was not account based, but rather, was warehouse based?

What if the OT server actually stored a warehouse of notes, each with a serial number and each signed by its issuer (a separate entity.)

Let's further assume that those notes are all identical, or that they are all in identical groups (1 clam denomination, 5 clam denomination, 10 clams, 20 clams, 50 clams, etc.) This means, again, that each individual group contains notes that are all identical, other than serial number, and are all signed by the issuer.

Now, can't the existing cash token mechanism be used for trading these notes, untraceably? If I want to withdraw 10 serial-numbered bars of gold into untraceable cash form, couldn't I just set aside 10 of the serial numbers in the warehouse, and then issue the appropriate cash tokens? Then whenever the cash tokens are redeemed again, OT just takes the same number of serial numbers out of circulation and puts them back into the "warehouse." The tokens don't have to directly match up to the serial numbers (which would destroy the untraceability, anyway) as long as the same amount is set aside to back the notes in circulation, I don't really care what serial numbers I get back when I deposit the cash again.

In fact, it forces one to ask: Why not use the existing account-based system, since it's functionally identical? Because perhaps there are cases where the existence of explicitly numbered and signed notes from the issuer (versus an account balance) provides additional proof that they have actually issued notes which have then passed beyond their control. Notice the Federal Reserve is never held responsible for fraudulent transactions using their money, though E-Gold is... Why? This is the exact distinction.

CLEAR TITLE FOR UNIQUE PIECES OF PROPERTY

Now we can imagine an instrument where EACH serial numbered item in the warehouse actually refers to a DIFFERENT CONTRACT ID EACH TIME! This is useful for attaching clear and transferrable title to unique pieces of property. Of course, you cannot perform a normal withdrawal from such a warehouse, like you would with account-based assets. But you CAN use it for registering, and transferring, clear title of property!

Imagine if I have a car, and I want to put it in the "warehouse". First I draw up a contract describing the car, containing its VIN number, and various other identifying characteristics. Now (as the car's owner) I upload the contract to the server in order to "register" the existence of this new property. Of course, I am already the owner of the car in reality. Registering it this way, in a commonly trusted registry, just gives me more proof and leverage regarding this fact. My public key is included in the original contract, and I have also signed it with that key. (So only I may upload it...)

The server doesn't have to issue a new currency based on that contract (like it normally would when a new contract is uploaded...) Instead, the server just stores the contract on a registry. It hashes the contract (producing the ID for the car) and lists that contract as one of my "assets" (since I am the one who uploaded it.) No, I cannot use that ID to open an asset account, since it's not a currency contract, but rather, a property contract. But I CAN "store" it on the server as my asset, and transfer it to someone else, or sell it, or put it into escrow, ETC! It becomes title of property.

How will this all work?

For example, when I first upload the car's contract, a transaction number is issued and a coupon is given to me, referencing the car's contract ID as well as the transaction number, which is signed out to me. (Let's say, transaction number 5.)

Next I sell the car to my friend. He puts 1000 clams into escrow, where I also put the car. Once BOTH of us sign off on the escrow instrument, the server gives the clams to me and the car to my friend. The server is able to verify both instruments, so both parties know they are valid.

As you can see, escrow MUST be built into the server for people to even be able to safely negotiate unique pieces of property! Unlike account-based forms of property, which have access to markets, there is no way to safely guarantee that you'll get the money in exchange for your car... unless you have escrow! That is what makes it possible for people to verify that both instruments are valid, and to verify that the exchange will be two ways. (Outside of markets, this restriction is also true for account-based instruments. Without escrow, each transfer is one-way and you have no guarantee that the corresponding payment will be made in return. Escrow enables safe two-way transfers.)

When the car is given to my friend, the server burns my old coupon, which was transaction #5 in reference to my car's ID, and then it generates for my friend a NEW coupon, say with transaction number 9, ALSO in reference to the same car ID that my original coupon referenced. (Now my friend has the newest, and the only valid, coupon for that car! He is now the owner.)

NOW: if I try to redeem the old car coupon, the OT server says, "Sorry, 5 is an old transaction number, and it's no longer any good. That's a bad coupon." But if my friend tries to redeem the coupon (say, sell it to someone else) the server knows that HIS coupon IS valid, since the transaction number on it is good, so the server performs the transfer as requested.

IN THIS WAY, INDIVIDUAL PIECES OF PROPERTY can be registered to their initial owners, and then transferred securely to other people, providing clean title!

And what is that coupon really, but a form of voucher? On OT, a voucher is like a cashier's cheque... it's a cheque guaranteed by the server. The coupon has an asset type ID, just like a cheque (the contract ID)... it has a transaction number, just like a cheque... it is functionally identical to a cheque! (Or, a voucher, since it's guaranteed by the server instead of by a user account.) The only difference is that the instrument transfers a unique piece of property, instead of a specific AMOUNT of an asset type. (So it has no amount.)

Therefore, since the cheque instrument can clearly be adapted for transfers of property title, couldn't the cash instrument be similarly used for unique items, just as the cheque is?

That is, instead of putting a transaction number on the note, which is traceable, put a BLINDED TOKEN ID on the note, which is untraceable... The note can still be signed, and still be considered valid, even though the server has no way of knowing who the bearer is!

Of course, if the server gives me an "untraceable" note for a certain car, and then you deposit it, the server still clearly knows that I transferred it to you! (Even though the server didn't know the actual token ID, it can still clearly see both ends of that transfer. This is because the car itself is unique and can only belong to one person at a time. It I withdrew it, and you deposited it... the untraceable token ID by itself, does us no good...)

BUT! If ALL "cash titles" were additionally transferred using a "title-only interface" (similar to a "cash only interface" that appears in the OT diagrams) where all actual "title exchanges" were performed BY THE SAME ACCOUNT EVERY TIME, then all of those property transfers become untraceable! Just like any other OT cash, you can see the Nym who withdraws, and the Nym who deposits, but you can't see who all had it in between!