The basic code for implementing a token system in Serpent looks as follows: from = msg.sender to = msg.data[0] value = msg.data[1] if contract.storage[from] >= value: contract.storage[from] = contract.storage[from] ­ value contract.storage[to] = contract.storage[to] + value This is essentially a literal implementation of the "banking system" state transition function described further above in this document. A few extra lines of code need to be added to provide for the initial step of distributing the currency units in the first place and a few other edge cases, and ideally a function would be added to let other contracts query for the balance of an address. But that's all there is to it. Theoretically, Ethereum-based token systems acting as sub-currencies can potentially include another important feature that on-chain Bitcoin-based meta-currencies lack: the ability to pay transaction fees directly in that currency. The way this would be implemented is that the contract would maintain an ether balance with which it would refund ether used to pay fees to the sender, and it would refill this balance by collecting the internal currency units that it takes in fees and reselling them in a constant running auction. Users would thus need to "activate" their accounts with ether, but once the ether is there it would be reusable because the contract would refund it each time. Financial derivatives and Stable-Value Currencies Financial derivatives are the most common application of a "smart contract", and one of the simplest to implement in code. The main challenge in implementing financial contracts is that the majority of them require reference to an external price ticker; for example, a very desirable application is a smart contract that hedges against the volatility of ether (or another cryptocurrency) with respect to the US dollar, but doing this requires the contract to know what the value of ETH/USD is. The simplest way to do this is through a "data feed" contract maintained by a specific party (eg. NASDAQ) designed so that that party has the ability to update the contract as needed, and providing an interface that allows other contracts to send a message to that contract and get back a response that provides the price. Given that critical ingredient, the hedging contract would look as follows: 1. Wait for party A to input 1000 ether. 2. Wait for party B to input 1000 ether. 3. Record the USD value of 1000 ether, calculated by querying the data feed contract, in storage, say this is $x. 4. After 30 days, allow A or B to "ping" the contract in order to send $x worth of ether (calculated by querying the data feed contract again to get the new price) to A and the rest to B. Page 20 ethereum.org