Havven System
Havvens are transferable ERC20 tokens, and also give their holders the following privileges.
 An owner of havvens may participate in nomin confiscation votes, they may also have the right to issue nomins at the discretion of the foundation for this version of the contract.
 After a fee period terminates, the duration and fees collected for that period are computed, and the next period begins. Thus an account may only withdraw the fees owed to them for the previous period, and may only do so once per period. Any unclaimed fees roll over into the common pot for the next period.
Average Balance Calculations
The fee entitlement of a havven holder is proportional to their average issued nomin balance over the last fee period. This is computed by measuring the area under the graph of a user's issued nomin balance over time, and then when a new fee period begins, dividing through by the duration of the fee period.
We need only update values when the balances of an account is modified. This occurs when issuing or burning for issued nomin balances, and when transferring for havven balances. This is for efficiency, and adds an implicit friction to interacting with havvens. A havven holder pays for his own recomputation whenever he wants to change his position, which saves the foundation having to maintain a pot dedicated to resourcing this.
A hypothetical user's balance history over one fee period, pictorially:
s ____
 
 ___ p
__________ __ _ _
f t n
Here, the balance was s between times f and t, at which time a transfer occurred, updating the balance to p, until n, when the present transfer occurs.
When a new transfer occurs at time n, the balance being p, we must:
 Add the area p * (n  t) to the total area recorded so far
 Update the last transfer time to n
So if this graph represents the entire current fee period, the average havvens held so far is
((tf)*s + (nt)*p) / (nf)
.
The complementary computations must be performed for both sender and recipient.
Note that a transfer keeps global supply of havvens invariant. The sum of all balances is constant, and unmodified by any transfer. So the sum of all balances multiplied by the duration of a fee period is also constant, and this is equivalent to the sum of the area of every user's time/balance graph. Dividing through by that duration yields back the total havven supply. So, at the end of a fee period, we really do yield a user's average share in the havven supply over that period. A slight wrinkle is introduced if we consider the time r when the fee period rolls over. Then the previous fee period k1 is before r, and the current fee period k is afterwards. If the last transfer took place before r, but the latest transfer occurred afterwards:
k1  k
s ___
  
  ____ p
__________ __ _ _

f  t n
r
In this situation the area (rf)s contributes to fee period k1, while the area (tr)s contributes to fee period k. We will implicitly consider a zerovalue transfer to have occurred at time r. Their fee entitlement for the previous period will be finalised at the time of their first transfer during the current fee period, or when they query or withdraw their fee entitlement.
In the implementation, the duration of different fee periods may be slightly irregular, as the check that they have rolled over occurs only when statechanging havven operations are performed.
Issuance and Burning
In this version of the havven contract, nomins can only be issued by those that have been nominated by the havven foundation. Nomins are assumed to be valued at $1, as they are a stable unit of account. All nomins issued require a proportional value of havvens to be locked, where the proportion is governed by the current issuance ratio. This
means for every $1 of Havvens locked up, $(issuanceRatio) nomins can be issued. i.e. to issue 100 nomins, 100/issuanceRatio dollars of havvens need to be locked up. To determine the value of some amount of havvens(H), an oracle is used to push the price of havvens (P_H) in dollars to the contract. The value of H would then be: H * P_H
.
Any havvens that are locked up by this issuance process cannot be transferred. The amount that is locked floats based on the price of havvens. If the price of havvens moves up, less havvens are locked, so they can be issued against, or transferred freely. If the price of havvens moves down, more havvens are locked, even going above the initial wallet balance.