Switch to ArdorForum

James, here is the structure of a contract that would fit the purpose.
For simplicity sake, I use the concept of Contract for difference (CFD) as defined for instance here http://en.wikipedia.org/wiki/Contract_for_difference

The contract could be formalized in this way:

CFD (amount, oracle, long/short, expiration, margin_start, margin_minimum)

The meaning of the parameters is the following:

• amount is the number of units that the seller want to trade
• oracle    is the data source that provides the information about the price of the asset that is traded 
• long/short defines if the contract issuer opens a long or short position
• expiration sets the date when the contract expires; if zero, no expiration is set and the parties can resolve the contract at any time by paying the due difference
• margin_start is the amount of units of value that will be locked until contract expiration
• margin_minimum is the minimum amount of units of value required to keep the contract in place; if passed, then the defaulting party undergoes a liquidation of its position and the proceeds are transferred to the other party according to the value published by the oracle

This is the way I would use to cover some of the actions required to create a fiat currency within the crypto domain.

• Alice wants to transform 10 BCT in Euro, without selling them; she understands that the contract that will be proposed to her will be in the same currency she already has (e.g. BCT) and that when she decides to get back her money this money will be again in BTC. However, the exchange rate vs. Euro, her local currency is now stable;
• the issuer, bob_ggg, receives the 10 BTC and immediately issues the tokes to Alice and creates a contract for difference based on the value of the asset pair as published by coindesk.com
• the contract issued is as follows: CFD (10 (e.g. the number of units of value), http://www.coindesk.com/price/ (the address of the oracle; a better choice is to have the value of the unit written in the block chain) , short (here the issuer of the contract says that it wants to create a short position in BCT), 0 (no expiration is specified), 0.3 ( the margin required to the parties to start the contract), 0.1 (the minimum margin required to keep the contract in place; liquidation of the loosing position would be activated by transferring the assets of the loosing position to the winning party)

An essential assumption is that the assets involved in the contract are in some way locked. If this were not possible, I do not know how to handle the counterparty risk without a third, trusted party.
Is this doable? Is it doable without introducing the complexity of smart contracts?

The building blocks I have (or will have soon) are:
NXTsubatomic: crypto <-> crypto trustless exchange
NXTatomic: any NXT tx <-> any other NXT tx
NXT <-> BTC atomic exchange is something I am very close to solving

Peer verified data can create a trusted dataset into the blockchain, I already have some early prototypes for this, but currently it is cost prohibitive at 1NXT per AM. I would like to publish new data every minute.

Enforcing the contract is where I see the difficulty. I can lockup any crypto asset for specific periods of time, but if the final distribution is based on the dataset in the blockchain, then unless the dataset itself somehow directly controlled the disbursement of funds, the party that is losing money can just bail out and avoid the loss.

I have an idea. It will only work for short term instruments and there wont be a 100% guarantee of completion,but both parties will be able to monitor each other in realtime and so as soon as one of them defaults, the other can terminate the deal. The loss of reputation might be enough to prevent most defaults. It will be implemented via software running 24/7, so loss of internet becomes an issue.

Thank you for your post,the more details I have, the better chance of a creative solution.

James