1. Content
  2. Index
  3. Search
  4. RSS/Subscribe

The Contingency Market

A general purpose trading system enabling financial exchanges contingent upon public events, e.g. the collective purchase of a music recording contingent upon the event of its public release.

It is to form the engine behind the Digital Art Auction and QuidMusic sites.

The Contingency Market is exposed as a web service, currently in development here: www.contingencymarket.com

A demonstration site, 1p2U, that uses the contingency market is also currently in development.

Introducing Microcontracts · 11 August 2014 by Crosbie Fitch

Whilst modern civilisation is familiar with the local, offline marketplace in which people meet face to face, it is not familiar with the global, online marketplace in which people communicate via screen and keyboard – at least not from the perspective of mankind’s long history of commerce.

There remain big problems online, concerning the difficulties people face in terms of establishing each other’s identity/reputation, and how they exchange money (or ephemeral substitute), and how they exchange materials and products between each other. Laws instituting monopolies and otherwise restraining trade are a minor problem in comparison.

Some problems offline, aren’t actually problems online – we just think they are, because we try to replicate online the mechanisms we have become used to using offline.

For example, one doesn’t even need money as such (silver or gold say), because one can make exchanges without it (a loaf of bread for a cauliflower). However, people are still rather familiar with money (or the idea if not the practice). It is because it was once more convenient to make exchanges via an intermediary commodity that we developed facilities for exchanging via that commodity, i.e. silver, silver coins, dollar coins, dollar notes, dollar amounts, and finally, just amounts, e.g. BitCoin. Ultimately, you should realise that you don’t even need the intermediary quantity at all. You simply have a market of things to be exchanged (and some things are silver).

The problems of trading online can all be solved one day, but we can get a long way toward that if we solve one particular problem first.

I think this problem probably gives rise to this idea of a monied like button.

It is the problem of a paucity of mechanisms available for exchanging public works, i.e. products necessarily publicly accessible, such as drinking fountains or literature.

One can make it private, and sell it publicly, or one can sell it privately, and make it public.

In other words, exchange happens when things cross the boundary of a private domain. Money leaves someone’s pocket, or a product leaves someone’s workshop. You cannot sell something you have already given away, nor that which you will not part with. You cannot buy that which you already have, nor that which another will not part with.

In the case of public works, the recipient is effectively the public. Once one has sold a public work to those who bought it, one cannot sell it to anyone else, because everyone else already has it (or has easy access to it).

There are two approaches to the sale of public works. The first is to privatise what should be public in order to sell it back to interested members of the public. The second is to invite interested members of the public to fund the release of a private work to the public.

One can erect iron railings around a park and its fountains and charge admittance. One can invite a nearby community to fund the building of the park via subscription.

One can enact a privilege that abridges the people’s liberty to make copies in order to charge them for copies of a literary work. The author can also invite their readership to fund the writing of a sequel via subscription (or crowdfunding).

The exchange is between those interested in receiving a fountain or sequel, and those interested in supplying it. The product is consequently received by all those who funded it, but importantly, it is not necessarily denied to those who didn’t fund it.

Online, because it is not a place, but a communications medium, there are no effective fences, and no effective reproduction monopolies. So, all we have is the mechanism of subscription. There is no means of enclosure in a communications medium.

One can keep information private, or one can make it public. Of course, some try to do both, by relying upon friction and copyright to charge for copies (music) or access (paywall) even as they deliver their product to the public.

Ultimately, as attempts to enclose ‘virtual space’ or speech fail, and people recognise such attempts are doomed to failure, we revert to natural reliance upon the physical boundary of one’s private domain (office).

So, we have arrived at the private producer, those many interested in receiving their product, and the public as ultimate beneficiary.

There are four obvious ways of looking at this transition of product from private to public and remuneration in exchange:

  1. The producer gives away their products, in hope of receiving donations as a consequence (possibly also commissions).
  2. Those interested in the producer’s products donate in the hope this will reward, support and incentivise production.
  3. The producer completes a product, and advertises/offers it for sale to those who may be interested (possibly subject to private preview).
  4. Those interested in a producer’s product offer to purchase it in exchange for its production and delivery to them (possibly subject to private preview).

In all these cases, the product is considered a public work, and delivery of the product is considered publication.

A gift or donation is unconditional, i.e. is it made without any formal agreement of exchange.

A sale or purchase is conditional, i.e. money is paid on condition work is delivered and/or work is delivered on condition money is paid.

Notwithstanding the potential for altruism, there are tacit exchanges and explicit exchanges, i.e. patronage and subscription.

The facilities for tacit exchange or patronage, that is, donation for publication, are well catered for, and not particularly fraught with difficulty. I am not too concerned with them, e.g. see snowdrift.coop for a project intending to develop a rather sophisticated donation facility.

The 3rd case in which a producer has already completed a product can be considered a special case of the 4th, that has a production delay of zero.

So, we are left with subscribed production. The producer and their subscribers (interested would-be receivers) are interested in exchanging a product for money (whether respective of consequential public benefit or not).

So in this exchange we can easily identify four things, the two parties making the exchange, and the two items each party has to exchange:

  • Producer – The producer of a public work (an individual or team thereof)
  • Product – The public work (a complete work, or a part, or an improvement thereof)
  • Subscribers – Persons interested in the production of the product
  • Commission – The total amount offered to be paid by the subscribers in exchange

We can also identify other things that may be involved:

  • Production – the producer’s process of producing a product
  • Subscription – the subscribers’ process of commissioning a producer/product
  • Price – the amount the producer would readily accept in exchange
  • Pledge – the amount offered by a subscriber
  • Subscription fee – the amount paid by each subscriber (if only one or more amounts are available), which does not exceed the amount pledged.
  • Public – the ultimate beneficiaries
  • Auditor – the persons involved in any preview of product or sponsorship on behalf of producer/sponsor.

Having examined the elements of the bargain between producer and subscribers, the next thing is to look to how we facilitate this online.

We are not dealing with a town hall of 200 people, a debate and a show of hands concerning a subscription for the building of a bridge (or repairs thereof).

An online subscription facility must cater for potentially vast set of geographically and politically disparate people, whose only commonality is a shared interest in the producer and/or their products. There is no practical opportunity to facilitate internal debate between them, or haggling on their behalf with the producer.

Each potential subscriber must also be considered to have a minuscule budget in terms of time and money. The subscription decision cost must therefore be negligible, and the expenditure must be disposable (‘fire & forget’ as it were). That is not to say that facilities cannot cater for those with more time and money than most.

We are also not primarily concerned with how to optimise the facility for rapid popular take-up, but how it must operate in the long term, and on a large scale.

Let us imagine a button that a producer can place on their website (effectively and incidentally identifying the producer) that invites the interested members of their audience (would-be subscribers) to pledge $1 in exchange for the production and publication of their next product.

A pledge is just a promise, the expression of an intention to pay money in exchange for something. It doesn’t need any commitment, beyond the initial, one-time registration at the subscription facility’s website. The subscriber’s micro-contract is “I offer $ in exchange for delivery, so if I don’t pay, I don’t receive delivery”. Thus each subscriber can make good their pledges at their convenience (and in accord with their enthusiasm to receive delivery of what they have subscribed to).

Now we can deconstruct monied like. The would-be subscriber is someone who is interested in the producer and their work, therefore they ‘like’ the producer and their work. The would-be subscriber is so interested that they can easily decide to offer a small amount of money in exchange for delivery of more of what they are interested in, more of what they like. Hence, their ‘like’ is a monied one – a ‘monied like’.

It is important to note that the ‘monied’ part is not a donation, nor, more critically, is it the relinquishing of monies. Thus making pledges does not consume the subscriber’s funds. Nor even does delivery. It is receipt that does so, and receipt is in the control of the subscriber. So pledges or ‘likes’ are effectively consequence-free, but they are nevertheless monied.

Conversely, the producer should always be fully informed as to the constituency of their current subscriber base, i.e. in terms of their subscribers’ status.

Examples of subscriber status

  • New = not yet provided any funds
  • Producer = have received funds as a producer
  • Good = have provided funds at some time
  • Unfunded = have no funds
  • Part-funded = have insufficient funds for this subscription
  • Funded = have sufficient funds for this subscription at certain fee levels (within amount pledged).
  • Fully-funded = have sufficient funds for this subscription at all fee levels (within amount pledged).

It is important to note that a subscriber can have a single dollar funding their account, and appear as a Good, Funded subscriber to a million producers (for dollar subscriptions). That therefore magnifies the power of a subscriber’s funds immensely, whereas donation consumes them and renders them insignificant drops in the ocean.

Setup for The Contingency Market - part 1 · 17 April 2012 by Crosbie Fitch

This is the first of many short articles going through the step by step process of setting up the development and runtime environment of The Contingency Market. The GPL source code to the latter will be provided in the respective article.

The first step in setting up the development environment for the Contingency Market is to set up the computer and operating system to run it on. I recommend a PC running Windows 2000 and IIS 5.0 onwards. I will use Windows 2003 Server & IIS 6.0.

Connect it to the Internet and ensure that it has the latest updates.

The Contingency Market is an ASP.NET web service (SOAP) written in C# so ensure the PC is set up with IIS. I will use IIS 6.0 (supplied with XP64 or 2003 Server).

It is of course preferable to have two PCs, one for the development environment and one to run the IIS web server plus web services. However, to keep the description of the set up process simpler I will use a single PC.

drew Roberts said 4346 days ago :

Honestly Crosbie, this is a fail. Or should I say a fail.net

Crosbie Fitch said 4346 days ago :

Don’t worry Drew, I’ll find the odd mo to carry on.

Contingency Market API · 29 November 2010 by Crosbie Fitch

In case anyone’s curious I thought I’d post a link to previous unpublished documentation for the internal API of the Contingency Market:

http://www.contingencymarket.com/help

Contrast it with the external API documented here.

AgentID Event Parameter Type · 18 October 2010 by Crosbie Fitch

I have just defined a new Event Parameter type – AgentID.

  • TID: This has type ID 11.
  • TName: The type name is ‘AgentID’
  • ValueTypeID: The value type ID is 4 (Guid/Globally unique identifier)
  • HasSpecial: No special values
  • Observer: Manual observation
  • TDescription: The ID of a Contingency Market Agent

It will be used to observe whether and when a particular agent is subscribing to a blog (URL_RSS).

Busker Label, I've Been Expecting You · 5 October 2010 by Crosbie Fitch

I read on Indie Music Tech today about BuskerLabel: crowd funding platform for artists to distribute their music for free.

BuskerLabel is very similar to my site QuidMusic of 2004. I’d started it’s development earlier still, expecting to call it MusicPatrons.com. That, in turn, was based on The Digital Art Auction (which I thought up in 2000), but I figured that sponsoring the production and publication of a music track at a fixed price of a pound was a simpler proposition (T’DAA! was far too complicated/advanced – something for a decade hence).

As it turned out, the QuidMusic prototype both convinced me this model was the future and in particular, made me realise that I wasn’t necessarily going to pick the best value proposition to start with. QuidMusic would still only now just be beginning to gain credibility, primarily because it is only now that enough people are sufficiently disillusioned with copyright and the traditional record label deal that both artist and audience are open to a new, more direct and libertarian deal. Kevin Kelly’s 1,000 True Fans article of 2008 has helped too, along with Fundable.com and now KickStarter.com.

I knew that if I continued with QuidMusic I’d eventually end up as just another ‘also-ran’ with umpteen varieties of the same model sharing the market. I figured that I should therefore focus on my strength, building a back-end that would support all manner of similar sites.

And this is where I am today, still plodding along, working on that back-end, The Contingency Market and a simple demonstrator, 1p2U, just as the hare is catching its breath before the final straight…

RSS feeds now ingested by Contingency Market · 21 October 2009 by Crosbie Fitch

I had previously assumed that Contingency Market clients would digest and archive RSS feeds themselves given an underlying assumption that the CM would be RSS agnostic. Thus the CM client (such as 1p2U) would take it upon themselves to register all the appropriate RSS events.

However, being pragmatic about it, the CM is ideally placed to take upon the burden of monitoring RSS feeds itself, leaving clients with only a need to register the feed as an event (an automatically observed one). That way the client can then interrogate the CM for information concerning the history of that feed, e.g. all items published.

I’ve now completed the modifications to the CM.

What I’ve now got to do is remove 1p2U’s rather iffy code that digests the RSS feed and replace it with code that retrieves equivalent information concerning the RSS feed from the CM instead.

Once I’ve done that, there should no longer be gaps in articles, nor cases where subscribers are listed more than once for the same feed.

A couple of days perhaps? :-}

Hacking Some Significant Changes · 16 October 2009 by Crosbie Fitch

I’ve been changing the representation of 1p2U subscriptions in terms of Contingency Market events, and still have some way to go. So 1p2U’s detailing of subscribers and articles published is not particularly accurate at the moment (very frustrating).

I’m amused to be hoist by my own petard, as in attempting to hack a direct database change (of URL events to URL_RSS events) I came across a security mechanism I’d long ago introduced to thwart such hacks. Once a contingency has been defined, it’s impossible to change it (because of the use of secure hashes). So, I’m going to have to support both the old contingencies and the new ones until the old ones have been replicated, and can eventually be discarded.

Scott Carpenter said 5296 days ago :

Just let me know when I can write my promotional post. :-)

Crosbie Fitch said 5296 days ago :

I was going to e-mail you Scott. I don’t think I’m going to get 1p2U ready for a new influx today. :-(

I’ve just had a surprise 4 day holiday that’s thrown my time-scales out a bit.

Unfortunately things are going to remain a little haywire until I can switch over to a far more robust system. And then I can get on with improving usability and features.

Scott Carpenter said 5296 days ago :

No problem — I’m looking forward to trying it out more, but understand things take time. In the meantime I’m working on content that people might want to pay for.

Crosbie Fitch said 5296 days ago :

Yup, it takes time, as does other work I have to do in parallel – I had to solve someone’s business critical network failure on Weds & Thursday. I’m banking on 1p2U becoming ever more business critical for us, so I look forward to your work, as you no doubt look forward to mine. :)

Caching Up · 17 September 2009 by Crosbie Fitch

I have been intending for the Contingency Market API to operate efficiently remotely as well as locally, hence its current, rather sluggish setup my end to replicate such a use.

However, in wishing to progress a little more quickly with 1p2U, I think I’ll leave the implementation of an object cache for the CM API until a little later (given I doubt there are any API users apart from myself at the mo).

Incidentally, the CM back-end database has been designed from the outset to be bidirectionally replicatable. So that provides an alternative to achieving a similar result via the API keyhole.

As far as my immediate next steps are concerned I’m going to try out an alternative API cache, then ameliorate my deliberate server-side bottleneck, and finally migrate data processing from the page retrieval process to a background one. Page caching is another option, but I’m leaving that until last.

So, 1p2U will not change visually/functionally for a few days, despite a long list of things needing to be done.

Cache fixed · 10 September 2009 by Crosbie Fitch

I’ve fixed the Contingency Market cache to cope with larger API call results.

I’m now going to do a tadette of profiling on 1p2U to see whether time is taken in database access or SOAP communication.

It would also no doubt help if 1p2U was a little less greedy in the amount of data it requested, but at least it gives me an opportunity to profile where the time is taken when dealing with large amounts of data.

Cache disabled · 9 September 2009 by Crosbie Fitch

The CM PHP API cache crashed yesterday evening, so I have disabled it until I’ve fixed the bug (the call result to be cached was too large).

 

Information

Recent Articles

Recent Comments

Projects

1p2U

Contingency Market

QuidMusic

Digital Art Auction

Free Culture Logo

Links

Progeny

Digital Constitution

1p2U

Digital Art Auction

QuidMusic

Contingency Market

Peers

ChipIn

Copycan

Digributor

EmanciPay

Flattr

Freinutz

Fundable

Kachingle

Kickstarter

LiberateIP

microPledge

PayyAttention

PledgeBank

RepliCounts

Strayform

Takoha

The Ransom Model

VODO

1p Subscribe