Title Server issues certificate to certify that pseudonym P1 holds token T, which means P1 is entitled to certain rights, service or product.
When P1 transfers T token to P2, the title verifies the authenticity of the transfer document and issues the new certificate in favor of P2.

This will be the very basic essential element behind modern electronic markets and community currencies. Community (non-bank created) currencies are the key to heal the world, and survive the "financial crisis" and recession, which is not a natural phenomena (but planned, and man-made).

Technology allows the public all-time audit of issued tokens. When the technology becomes widely deployed, anyone sane will refuse tokens (company shares, bonds, or money) issued in the non-transparent method that encourages fraud.


Implementation:
Title Server should live on a tamper-free hosting hardware behind (or inside, eg USB "key" or PCI card) a webserver.
We recommend that no OS (or(especially webserver!) is running on the Title Server.
Title Server needs some (preferrably redundant) storage: flash or harddrive. Dedicated tamper-free database is also possible, but the storage primitive is so simple (retrieving an integer number from an array, and incrementing it) that it really should not be necessary.

We recommend implementing the title server inside the GRUB bootloader (or PXE bootloader). GRUB provides

• network packet handling (bootp, dhcp, tftp), UDP is suitable
• serial port access
  
• storage: block device access, even several filesystems (like ext2, minix, fat, htfs...)
  

http://www.gnu.org/software/grub/manual/html_node/General-usage-of-network-support.html


Pseudocode:
In this scenario, P1 transfers a single token to P2.
P1 provides

• proof document that P1 is entitled to token (signed by the title server earlier)
  
• and transfer document (signed by S1, secret pair of P1)

The title server

1. verifies the proof document
   
1. tokens exist: denomination, and serial number is inside the issued range. The title server might have this information cached, or it might require this (signed by the token issuer), or retrieve himself
2. proof document signature is correctly signed (signed by the title server earlier)
3. the token sequence number is same as stored in the title server: not old (transfer replay attack)
2. sequence number ++ (also stores the sequence number internally. This basically invalidates the old "P1 is entitled to token" proof document )
3. signs new proof document in favor of P2
   
4. stores the documents in redundant storage (not necessarily in the temper-proof storage)
   

Note that ONLY the sequence number must be stored in the local tamper-free storage in the title server, that is appr 4 bytes for each token. All other documents cannot be tampered anyway. so they might be stored on lower security webservers over the network, although redundance is required to prevent data-loss.

In this scenario P1 wants to transfer 5 units to P2, but he has tokens: 4+2

• P1 provides one proof document for each token
• at the end of the transaction P1 will be entitled a change of 1 (and P2 will be entitled 5 of course). The title server maintains a small pool of "change".
• one new proof document for each token that parts in the transaction
  

See Agora