Products
There are different kinds of options, but the basic form goes something like: "on a preset date, trader A agrees that trader B may optionally (at trader B's discretion) buy X shares of XYZ for D dollars, from trader A."
Right away we see this will have some sharp edges in an online game:
-
It requires obtaining a decision from trader B on the specified date, while trader B may in real life be sleeping, be at work, be in the hospital, not care about the game anymore, etc.
-
If trader A doesn't have X shares of XYZ at the exercise time, the software will have to handle that in a way that's fair to both players, and doesn't require getting them out of bed.
Luckily, real life comes to the rescue. First, stocks, being traded on exchanges, are fairly liquid, and have a market value that can be easily looked up. So if, on the exercise date, trader B has the option of buying X shares of XYZ for D dollars, we already know what trader B wants to do: if X shares of XYZ is worth more than D dollars, she'll buy it; otherwise she won't. It's reasonable to imagine that trader B would much rather have the software make this obvious decision for her than have to remember to be online at the right time to make a trivial decision in a game.
The second problem is moot for a different reason: in real life, not only are stocks liquid, but options are liquid: they are set according to standard terms and traded on exchanges. Thus, in real life, options are rarely exercised; rather on the exercise date trader A simply buys back the option, which he can reliably do since there are thousands of other traders buying the same option. Likewise trader B simply sells it back. The option never gets used and the actual value of exercising it is reflected only in the change in its price.
Alas, in an online game where membership may be sporadic, derivatives cannot be liquid, so buying the option back from the exchange isn't feasible. However, stocks are liquid, so it's safe to assume that, if trader B can't buy the promised X shares of XYZ, she'll be content with the corresponding value of those shares in dollars.
The proposed representation of a derivative consists of:
-
An exercise date,
-
A condition on which the derivative will be exercised,
-
A list of securities to be traded.
So for example, an option to buy 100 shares of GE on 9/18 for $350 would be represented as:
-
9/18
-
GE > $3.5
-
[100 * GE, -350]
The - in -350 indicates that the money is moving from the buyer to the seller.
Representation of dates is clear, but the representation of the condition and the securities is not. It is described in the next section.
A security consists of two pieces of information:
-
The "flavor" (if a stock, the stock ticker symbol)
-
An amount, with a sign.
Stocks, derivatives and dollars would be possible flavors. If the sign is +, the security is to be moved from the seller to the buyer (in the option example, trader A is the seller and trader B is the buyer). If it's -, it is to be moved from the buyer to the seller.
Not all securities can be compared. This is simply because in a world where derivatives are not standardized and not traded on exchanges, it is impossible for software to know the value of a derivative, or to say if one derivative is more valuable than another.
Therefore, the only comparable securities are:
-
Dollars
-
Stocks
Securities are compared according to their dollar value at the present time. The dollar value of a stock is the last traded price of that stock.
When trading on an exchange, you normally think of a derivative as looking like
or
It would not be technically infeasible (or even harder) to use this representation in an online game, but it could lead to serious problems. In real life, because the exchange takes one half of the trade, it needs to put effort into enforcing a standard of behavior for the traders: importantly, the exchange puts limits on leverage and sets margin requirements. It's hard for software to do a good job of this -- it would likely lead to a high number of defaults.
In the game, a better representation is
importantly, neither trader A nor trader B owns the derivative; rather they each own one endpoint of it. An analogy would be a socket always having two endpoints (although sockets aren't normally traded).
Only the buyer endpoint of a derivative can be traded. This is necessary to prevent people absorbing their debt into dummy accounts or companies (see later) which will then default. There is no reason that the buyer endpoint must have positive value -- so it map be vulnerable to the same tricks, but that is a problem that occurs in real life as well, and is a natural aspect to the strategy of the game.
What happens when, on the exercise date, trader B goes to buy security XYZ from trader A, and trader A doesn't have security XYZ? The answer depends on the type of security.
If XYZ is dollars, we can assume trader A is now in default and will need to declare bankruptcy, which is a whole topic in itself.
If XYZ is a stock, as mentioned earlier, it is a simple matter to convert XYZ to dollars, and then the rules for dollars apply.
The trickiest case is when XYZ is a derivative. First, remember that you don't trade derivatives, you trade endpoints, so what trader B is actually purchasing from trader A is one endpoint of derivative XYZ. The key point is that a derivative is just a contract: if trader A doesn't have the correct endpoint of XYZ, an XYZ derivative can be created at that time, giving trader B his promised endpoint, and letting trader A keep the other.
For trader B this is obviously acceptable -- she get what she was promised, but what about for trader A? In fact, this should be entirely acceptable for trader A as well, because derivative endpoints cancel each other out. This means that receiving the seller endpoint of XYZ is no different than giving away the buyer endpoint -- so again, the difference should be moot for trader A.
A problem will occur if derivative XYZ is past the exercise date, since this would involve editing the past. In real life, this would be impossible; in the game, it would be possible, but highly undesirable. However, assuming you can't directly trade XYZ after it has expired, the only time this would be an issue is when derivative XYZ is included as part of the contract of derivative ABC, and the exercise date of XYZ comes first. Since this can be detected at the time the user tries to create ABC, the error case can simply be presented to the user as not allowed, and the problem will never arise.
"Companies" are used to control the priority of securities, e.g. by tranching. A company has its own portfolio, which may contain any of the same securities that a user's portfolio holds. A company, however does not initiate trades -- it exists only to be a container.
"Companies" in this model are a subset of companies in the real world, namely those used only for bookkeeping purposes -- to hold a set of assets and liabilities. It's not unreasonable that companies with decision-making power could exist in an online simulation, but this is its own issue.
A single user creates a company by giving it some of their own assets. They can give the company any assets that they can trade -- so the company cannot take on the seller endpoint of a derivative.
It is, however, desirable to allow companies to allow liabilities -- they just shouldn't be allowed to take on a user's liabilities because this would provide a way for the user to hide liabilities inside a company. Therefore, when a user creates a company, they can buy securities from the company at that time only. Since at that point the user holds all shares for the company, they cannot hide any of their own liabilities in this way.
When a company is created, it is divided into a fixed number of shares, chosen by the user. The user also chooses a preset liquidation date for the company.
On the liquidation date, a company is liquidated. The process for liquidating companies is the same as for liquidating users who are in default, and is described later.
Once the company is liquidated, the cash is divided equally among all equity shares. The shares are then removed from all balance sheets.
Shares are assets that can be traded. The can be bought and sold. They can not be specified in derivatives.
The reason for this latter restriction is simply that if, on the date a derivative is exercised, if the shares in question are not actually available to be traded, there does not seem to exist a solution that is fair to both parties, and convenient enough to fit in an online game. In derivatives we solved the problem by creating new derivatives "out of thin air", but it would be far stranger to a user to suddenly have a new company show up on their balance sheets -- and far harder to get right in an implementation. The extra flexibility simply isn't worth the confusion this is likely to cause to the user.
When a user goes bankrupt (cannot pay all her debts) or a company is liquidated at its scheduled date, or when a company is unable to pay all of its liabilities, a portfolio will be liquidated, hoping to obtain as much cash as possible.
Cash is already cash. Stocks are liquid assets and will be immediately sold back on the exchange for cash. The remaining assets are derivatives and equity shares.
Sadly, or fortunately, depending on your point of view, in economics the value of products is determined by what the market participants are willing to pay for them, so the software cannot put a value of derivatives and equity. The software will put these at auction for a period, say 1 day, and any that are not sold will vanish.