Initial Drawings and Musings

So, the first post. I'm going to use the blog here to document progress on the module and design decisions. The goal is to allow others to provide input and to make this module building exercise an open learning situation for people who are interested. The first step is to lay out the initial set of requirements. For the first iteration, my goal is to implement the bank accounts, objects and facility to store the purchasing/trading of contract groups, and the "happy path" through the purchase/sale of a contract group as a whole. "Happy path" means no validation just yet. I've also mentioned (here and in //TODO comments in the code) some things I know I will need to do but that I don't want to worry about now.

Attached is a diagram of some of the initial thoughts - a sort of object/relational map and also a tiny workflow. If you like pictures, maybe that will help more than my descriptions.

This module (really, set of modules) needs a few things before it can be considered workable. I would like to implement the most basic "happy case" version of the module first and then expand from there. So, it is a continuous double auction based on the Iowa Electronic Markets rules.

Bank Accounts

In order to have some concept of accounts on a site the most obvious choice to me is the userpoints module. This handles most of the requirements for the accounts of a prediction market. There currently is no "interest" module to add interest to an account but building one should be a fairly trivial re-write-in-reverse of the expiration module.

Contract Groups and Contracts and Trades

A contract group represents all possibilities to trade (i.e. "sun coming out tomorrow: yes, no; expires at 00:00 midnight the day after tomorrow GMT") and then the contracts are the individual pieces inside the group ("yes", "no"). Trading begins by people buying the entire group and paying 100 points for the whole group and then selling the one that they don't like. I chose to represent all of these objects as nodes using the cck nodereference module to associate contracts to their contract groups and to associate trades to either one.

Accounting for Contracts Owned by a User

In addition to just increasing/decreasing the points of a user to track their bank accounts we also need to track how many of each contract a user owns. Ideally we will also track the purchase price for these so that we can give them profit/loss statements. I had several thoughts for this:

• Userpoints categories - use userpoints for both money and the contracts that people own by using different "categories" for points.
  Pros:
  • userpoints is intended for accounting purposes

  Cons:

  • Categories are limited in terms of metadata so it would be hard to enforce "closing" a contract
  • Categories may cause general site slowness since they are tied so closely to taxonomies
• One contract, one node - keep a unique ID for each contract that is being traded on the system and assign ownership
  Pros:
  • Accounts for everything. Fraud would be harder than just changing a value in a record - someone would have to insert new nodes.

  Cons:

  • Performance/scalability. Large orders would be a nightmare.
• Custom cck node 1 node per contract type that a person owns and an int field for the number of contracts they own
  Pros:
  • Relatively fast, if revisions are saved it could work reasonably well for accounting
  • put the txn ID from userpoints into the log field to provide solid accounting

  Cons:

  • even nodes are slower than just straight table access
• Totally custom stripped down userpoints
  Pros:
  • really fast

  Cons:

  • lots of work, bugs

What I'm Ignoring for Now (reports, alerts, ajax, XUL)

One of the big components of this system will be reports. People like reports and they need to be easy to link/embed outside of the site. People will also want alerts - "send me an email if X happens" - and they'll want to be able to get them via rss, sms, im, etc. The site will need AJAX and/or XUL interface to be responsive enough to feel right.