Gas Swing Contract

Gas Swing Contract

Gas Swing Contracts typically have the following features:

• There are usually 3 levels at which the Physical commodity is delivered (low/normal/high);
• The contract holder is usually constrained in the number of decisions they can make, and they will normally need to be made at certain times of the day for a physical delivery happening in the near future;

As these contracts are traded over-the-counter, there can be a high degree of variations to the above attributes. The Netrium Gas Swing contract acts as above.

contract =
    gasSwing
        (initialMarginFee <> exchangeFee 100)
        (Market gas thm nbp)
        (cpardLowVolume, cpardNormalVolume, cpardHighVolume)
        cpardGasPrice gbp cash
        2
        [ (datetime 2012 10 (d-1) 16 00, date 2012 10 d)  | d <- [2..4] ]

Since the Decision Tree's built by Netrium as a result of compiling a contract are immutable, the system creates the permutations needed for all options that are possible when running a contract. We can easily do this with highly complex contracts in Netrium due to Haskell's lazy evaluation - the parts of the tree being executed only exist at the time of inspection. As the contract is executed, the Netrium simulate process trims branches off the decision tree that represent decisions not taken, thereby reducing the complexity of the contract as it executes.

Due to the large size the syntax and decision trees are not embedded in this page. Direct links:

• Syntax Tree
• Decision Tree

When reading the diagrams, it is useful to understand the following:

Multi-Selection

The above diagram shows the two tiers of decisions required to make 3 possible selections. For example:

• To select Normal delivery level, the contract execution process sets the choice "selection[normal]" to true;
• To select Low delivery level, the contract execution process has to perform to selections: "selection[normal]" and "selection[low-high]" must be both false;
• To select High delivery level, the contract execution process has to perform to selections: "selection[normal]" must be false and "selection[low-high]" must be true;

Since these contracts are normally highly customised, it is normal for a custom user interface to be built to execute and manage them. In these cases, the user interface can easily be authored to hide this complexity.

Read

In order to limit the number of decisions that can be made by the contract, the contract has to hold some state. This is managed by read.