[Webfunds-users] router server API / Protocol idea

Sat, 31 Mar 2001 09:12:15 -0800

There are some ideas I had before encountering Systemics that are similiar 
to theirs.  In fact, it was in my search for prior art related to my ideas that I 
found Systemics.  This is why I am so enthusiastic about the Systemics 
account server / exchange server - because I already had thought through 
the revolutionary potential of such a system, and was very happy to 
discover somebody was already implementing it.  I'd like to share my vision 
so you can see how similiar it is, and perhaps to think about how my idea 
of a router server might be implemented in the Systemics architecture.

Basically, my idea was to have account servers and exchange servers as 
separate off the shelf retail packages that would run on an ordinary server 
PC, and which would be modifiable for any financial instrument, currency, 
commodity, bonds, etc, with only a few user settings, no programming 
required.  So far, the same as Systemics.  I did not think through the idea 
of ricardian contracts at all as Systemics has done, and my idea of 
ensuring reliable instant clearing for exchange transactions was to have 
some kind of protocol between the exchange server and the account server 
where when a person entered an order on the exchange, the funds in the 
account server would be locked until the order was either executed or 
cancelled.  Systemics' solution to this problem is better than mine.  In my 
idea, any two account servers could be linked by an exchange server, or 
multiple exchange servers, without any involvement or even consent from 
the account server so long as they all obeyed the same protocol.  
(Systemics has already thought this through with the SOX protocol.)  So 
far, so good.

The next step in my thinking was to view account servers as nodes in a 
network, and exchange servers (trading exchanges) as links between 
nodes.  Because of the nature of trading exchanges, they provide 
maxiumum liquidity and convertibility between two instruments.  The more 
transaction volume on the exchange, the narrower the bid/ask spread, and 
the lower the cost of conversion between the two instruments.  Instant 
clearing will make this work even better.  So, an exchange server can be 
viewed simply as a link between two account servers.

An account server may be shares of stock, bonds, any commodity, 
currency, etc.  Also, there is no reason that shares of stock need to be in 
integer units.  Why not allow micropayments denominated in shares of 
stock?  Stock could be used as money this way.  Integer units of stock 
were necessary before computers to simplify dividend calculation, etc, but 
when a computer can automatically calculate dividends and credit 
accounts, then there is no reason an account couldn't have .00001 shares 
of stock, or spend the same.  What company wouldn't be pleased to have 
its stock circulating as money?  Liquidity is always an objective, and using 
stock as money would enhance liquidity.

By allowing micropayments of a wide variety of financial instruments, 
commodities, etc., this blurs the distinction between money and other 
financial instruments, and enhances liquidity throughout the system.  
Everything becomes indistinguishable from money and everything becomes 
usable as money.

So, in this network of account server nodes connected by exchange 
servers, the only thing that might distinguish a particular node as being 
"money" would be the number of other nodes that are connected to it via 
exchange servers, and the amount of transaction volume on the 
exchanges.  A dollar node, or an e-gold node, might be connected to 
thousands of other nodes (such as a node for every company's stock for 
instance).  A stock node might only be connected to a few nodes, such as 
a node for each currency which that stock is traded against.

This network of exchange has a robustness that exceeds the robustness 
of any particular currency or money.  Any form of money is just one node 
in a network where there are multiple paths to reach any node.  Therefore 
the failure of any particular money system is equivalent to the failure of a 
network node.  Just like the Internet, transactions will simply route around 
the failed node via a different path.

Now, this idea of a transaction network of connected nodes is getting 
closer and closer to being analogous to the Internet itself.  That's a clue: 
this network needs a router server.

The router server would be the final step in allowing anything to be used as 
money.  The router server would automatically route transactions from any 
node to any other node in the network, via the shortest path.  An Internet 
router keeps itself informed of the network topology and the cost, delay, or 
distance between other nodes in the network, and then it calculates the 
shortest route from this information.  In this transaction network, a router 
server could do something similiar.  It could keep itself informed of all 
account servers and all exchange servers, and the transaction fees 
charged by all account servers and exchange servers, and the current bid 
and ask prices posted on all exchange servers.  Then the router server 
could use this information to calculate the shortest path from any node to 
any other node.  The router server could then automatically execute the 
necessary transactions on exchange servers to move a specific amount of 
value from any source node to any destination node.

Here is an example of how this could work in practice to enable any node 
in the network to be used as money.  Suppose a man who lives in Ethiopia 
decides, for whatever reason, to keep all of his assets in the account 
server of a particular company's stock, call it XYZ company.  Maybe the 
man works for this company, or it is his favorite company, and he doesn't 
want to keep any of his assets in anything other than XYZ stock.  Fine, he 
can spend XYZ stock anywhere in the world, just like money, thanks to the 
router server.  He has a smart card and a contract with the router server.  
Say he is travelling in France, and he is shopping at a store, and for some 
reason this store only accepts payment in e-palladium, nothing else.  No 
problem, the man presents his smart card at the checkout counter and 
pays for his purchase in shares of XYZ.  The router server takes care of the 
rest.  The router server calculates the shortest network path to convert 
shares of XYZ into e-palladium, and the exact amount of shares of XYZ 
needed, and routes that transaction through a series of exchange servers 
and account servers to arrive at the e-palladium server used by the store in 
France.  The transaction could start first at the XYZ server, where the 
router server sells the correct amount of XYZ stock from the man's account 
on the XYZ stock / Ethiopian Birr exchange and puts it into a temporary 
account owned by the router on the Birr account server.  Then the router 
moves the Birr across a Birr / Dollar exchange server into a dollar 
denominated account server.  Then the router moves it across a dollar / e-
gold exchange server into an e-gold account.  Then the router moves it 
across an e-gold / palladium exchange server into an e-palladium account.  
Then it transfers the correct amount of e-palladium into the account of the 
store in France, the transaction clears, the clerk hands the man his smart 
card back, and the man walks out with the merchandise he has just 
purchased.

One problem with routing the transaction forward from the XYZ share server 
like this is the uncertainty in knowing exactly how many shares of XYZ to 
sell.  Although the router server can calculate a very good estimate, the 
bids and asks on some exchange servers may change by the time the 
transaction passes through them and the final amount of e-palladium at the 
end of the chain may be off a little bit from what was required.  The solution 
to this is to route the transaction backward as a debit, instead of forward 
as a credit.  The router server knows exactly how much e-palladium is 
needed (a debit amount of e-palladium), so it purchases the exact amount 
needed on the e-palladium / e-gold exchange.  Now the debit is on the e-
gold server, and again the router knows exactly how much e-gold is 
needed, so it purchases the exact amount of e-gold needed to clear the 
negative e-gold ballance on the e-gold / dollar server.  Then it clears the 
negative dollar balance by purchasing the exact amount of dollars needed 
on the dollar / Birr server.  Then it clears the negative Birr balance by 
selling the exact amount of shares of XYZ needed on the Birr / XYZ 
exchange.  Of course, most of these account servers will not allow 
negative balances.  That could be worked around by the smart card 
company itself keeping positive balances on major nodes and temporarily 
loaning from its own positive balances.

It is true that credit card companies already allow instant conversion 
between major currencies, and perhaps CashBox will allow something like 
this,but the solutions offered by these companies are limited to the 
markets that they themselves are willing to make.  Such plans only allow 
spends from such limited nodes as these companies decide to hard-wire 
support for.  The router idea on the other hand does not require any hard-
wiring of specific nodes, and allows spends from any node to any other 
node.  No matter how remote any node is, every node is an integrated part 
of the money system.  As soon as somebody licenses another account 
server and issues their own financial instrument, and that instrument is 
linked to the network by at least one exchange server, it is immediately 
welcomed into the worldwide network and recognized as another form of 
money, spendable anywhere.

At this early stage, the router server is not necessary, and routing between 
different account servers will be done by hand, using the trader wallet and 
the exchange server.  However, it would be really cool if the programmers 
working at Systemics would put whatever is needed into the SOX protocol 
that would be needed to support router servers.

~ Vincent