I had a thought about how we could take a step toward eliminating counterparty risk for assets.
Say we created a new class of asset called a “backed asset”.
A backed asset would be a token, like the standard assets we have today, but instead of being backed by property held outside of the system by an issuer (which can obviously be defaulted on) the asset is instead backed by XCP held in escrow by the system (kind of locked “within” the asset itself).
Each backed asset would be associated with a price feed (chosen by the issuer) that anyone willing to accept the asset must be willing to trust.
In order to issue an asset, say, a USD token, an issuer must lock-up XCP to the current market value of $1 USD, based on the price feed. They could then sell this asset into the market for roughly the equivalent XCP.
After a backed asset has been issued, and initialized with enough XCP value, it would function like a bet which aims to back the asset with the appropriate amount of XCP, based on the feed.
When issuing the asset, the issuer would set a time in the future up to which they’re willing to back the asset, and an amount of XCP up to which they’re willing to back the bet.
As XCP strengthens against the asset (based on the feed) the issuer wins XCP because it takes less XCP to back the asset.
As XCP weakens against the asset the issuer loses XCP (because it takes more XCP to back the asset). From the point of view of the person holding the USD token, their token is suddenly backed with more XCP, but is still worth one dollar.
When either the duration of the bet or the XCP amount of the wager is exceeded, the asset is destroyed, and the XCP within the asset and held in escrow with the issuer is shared between the issuer and the holder of the asset.
Optionally (as extra flags that could be set when creating the asset) the holder, issuer, or both, could be allowed to trigger the liquidation of the asset at any point up to the end of the bet.
EDIT: Unfortunately, the protocol doesn’t currently support this.
[quote author=CryptoFinanceUK link=topic=201.msg1617#msg1617 date=1395927915]
I had a thought about how we could take a step toward eliminating counterparty risk for assets.
Say we created a new class of asset called a “backed asset”.
A backed asset would be a token, like the standard assets we have today, but instead of being backed by property held outside of the system by an issuer (which can obviously be defaulted on) the asset is instead backed by XCP held in escrow by the system (kind of locked “within” the asset itself).
Each backed asset would be associated with a price feed (chosen by the issuer) that anyone willing to accept the asset must be willing to trust.
In order to issue an asset, say, a USD token, an issuer must lock-up XCP to the current market value of $1 USD, based on the price feed. They could then sell this asset into the market for roughly the equivalent XCP.
After a backed asset has been issued, and initialized with enough XCP value, it would function like a bet which aims to back the asset with the appropriate amount of XCP, based on the feed.
When issuing the asset, the issuer would set a time in the future up to which they’re willing to back the asset, and an amount of XCP up to which they’re willing to back the bet.
As XCP strengthens against the asset (based on the feed) the issuer wins XCP because it takes less XCP to back the asset.
As XCP weakens against the asset the issuer loses XCP (because it takes more XCP to back the asset). From the point of view of the person holding the USD token, their token is suddenly backed with more XCP, but is still worth one dollar.
When either the duration of the bet or the XCP amount of the wager is exceeded, the asset is destroyed, and the XCP within the asset and held in escrow with the issuer is shared between the issuer and the holder of the asset.
Optionally (as extra flags that could be set when creating the asset) the holder, issuer, or both, could be allowed to trigger the liquidation of the asset at any point up to the end of the bet.
EDIT: Unfortunately, the protocol doesn’t currently support this.
[/quote]
Yes. This also won’t work for physical assets.
Interesting post, we can have two types of assets. One of the types can be secured by such a mechanism.
Yeah, that would be the idea. But, after spending a couple of hours looking at the code for counterpartyd (and reading one of the dev’s remarks) this idea doesn’t seem to be a great fit for the current implementation. I’m looking at some other avenues at the moment.