The Alberta Buck - Demurrage and the Jubilee Fund

The sender's residual continues to age from a fresh timestamp, the locked fees stay in the sender's account, and the recipient receives fresh BUCKs (no inherited fee debt). A spendable cap value <= balanceOf(from) prevents the sender from spending its locked dust.

function _nonCarryingTransfer(from, to, value):
    require(value <= balanceOf(from))
    _crystallize(from)
    _crystallize(to)
    _balances[from] -= value
    _balances[to]   += value
    // _demurrage[from] retains the pre-existing locked fees.
    // _demurrage[to]   is unchanged: recipient gets fresh BUCKs.

Both _timestamp[*] are set to now by crystallisation; the recipient's _demurrage[to] is unchanged so the new BUCKs land at age 0. The OZ super _update guards on raw, so the spendable check sits in front to prevent spending locked dust.

The sender's _timestamp and _demurrage are unchanged on outflow; the residual ages from the original basis. The recipient is crystallised first, then the carried fee value * BASE_RATE_PER_SEC * (now - _timestamp[from]) is added to _demurrage[to]. The recipient's spendable rises by the net amount value - carried_fee, exactly the age-adjusted value of the incoming BUCKs.

function _carryingTransfer(from, to, value):
    require(value <= _balances[from])
    age_basis_seconds = now - _timestamp[from]
    carried_fee       = value * BASE_RATE_PER_SEC * age_basis_seconds
    _crystallize(to)
    _balances[from] -= value
    _balances[to]   += value
    _demurrage[to]  += carried_fee
    // _timestamp[from] and _demurrage[from] are unchanged.

There is no spendable cap on the sender side: a Carrying contract may transfer up to its raw, with the carried fee obligation riding the BUCK to the recipient. The Carrying transfer is its own balance-mutating event for to, so the recipient is crystallised first; the carried fee is then added to the just-refreshed _demurrage[to].

A Carrying transfer requires the recipient's prior consent via the identity-bound approve (see "Approve and consent"). This prevents a Carrying account from dumping unwanted fee debt on an unconsenting counterparty.

For Non-Carrying accounts balanceOf + balanceOfFees = _balances holds at every block. For Carrying accounts the identity is broken on purpose: balanceOf = _balances and balanceOfFees = feeOwing are reported separately so that ERC-20 consumers see a stable balance even as the carried fee grows. Both transfer flavours preserve sum_a _balances[a] = totalSupply and the system fee debt sum_a feeOwing(a) = BASE_RATE * area_under_supply.

The Jubilee fund's raw balance grows ONLY when _accrueJubilee() runs, and _accrueJubilee() runs ONLY at the start of mint() or burn(). totalSupply grows by the same delta; the new BUCKs are backed by the locked fees that already exist in user accounts.

uint256 internal _jubileeLastUpdate;   // initialised to genesis

function _accrueJubilee():
    elapsed = now - _jubileeLastUpdate
    if elapsed == 0:
        return
    delta = totalSupply() * BASE_RATE_PER_SEC * elapsed
    _jubileeLastUpdate = now           // set BEFORE super._mint to block re-entry
    _crystallize(address(this))
    super._update(0, address(this), delta)   // direct, bypassing our _update override

The accrual mints fresh BUCKs to address(this) equal to the 2%/yr rate applied to the current total supply across the elapsed interval (the supply is piecewise constant between mint/burn events, so the integral is just totalSupply * elapsed). The new BUCKs themselves land at age 0; the crystallisation step folds Jubilee's prior age into its _demurrage[] before the mint.

A virtual balanceOf(jubilee) = BASE_RATE * area_under_supply view with no ERC-20 storage was considered and rejected. A BuckCredit.close must super._burn BUCKs from the Jubilee, which a virtual balance cannot satisfy without inventing a parallel supply concept. Real ERC-20 storage is operationally simpler, matches user intuition, and lets Carrying transfers from Jubilee push real raw to recipients.

Stock ERC-20 consumers do not expect the balance under their custody to spontaneously decay. Uniswap V2's UniswapV2Pair caches reserves on every event and reads IERC20(token).balanceOf(this) to detect deposits and withdrawals; skim() computes balance.sub(reserve) via SafeMath, mint() computes balance.sub(reserve) for new LP shares, and swap() checks balanceAdjusted * balanceAdjusted > reserve * reserve= for the K invariant. Every one of these breaks (silently or with a revert) when balanceOf drifts below reserve due to demurrage.

By making balanceOf(carrying) = _balances[carrying]:

• balance == reserve holds across arbitrary idle periods.
• skim() sees a zero diff and returns cleanly.
• mint() attributes the new LP shares to the actual inflow.
• swap()'s K check is satisfiable; the fair-price math remains calibrated to the same constant the LPs deposited against.

The fees aren't disappeared – they ride out with each Carrying transfer. When the pair pays a swap recipient, it calls _carryingTransfer: _balances[pair] drops by the gross value, _balances[recipient] rises by value, and _demurrage[recipient] absorbs value * BASE_RATE_PER_SEC * (now - _timestamp[pair]). The recipient's spendable rises by the net (value - carried_fee); the swap-out delivers age-adjusted BUCKs even though the gross transfer was un-aged.

The flag lives in IdentityRegistry and is set at registration time:

Carrying contracts are expected to be the typical case for service infrastructure (Notes pools, AMM pools, the Jubilee fund itself). Smart-contract wallets – multisigs, AA wallets representing one user's volition – opt out at binding time so they crystallise like the EOA they replace.

The flag is locked the first time any counterparty issues an identity-bound approve naming this address as the spender. Pre-approval changes are permitted (a freshly-deployed contract may flip its mind before going live); post-approval changes are not (recipients have already consented to a specific Carrying flavour, and the operator must not be able to retroactively change it).

// Buck.approve(spender, amount, E_spender, pi_CP):
//   ... existing CP-receipt machinery ...
//   identity.markApproved(spender)        // freezes the spender's flag

function markApproved(address spender):       // IdentityRegistry, external
    require(msg.sender == buck, "only Buck")
    if !carryingFrozen[spender]:
        carryingFrozen[spender] = true

function setIsCarrying(address target, bool value):  // IdentityRegistry, external
    require(msg.sender == binderOf[target],     "not binder")
    require(!carryingFrozen[target],            "carrying frozen by approval")
    isCarrying[target] = value

A re-bound (re-deployed) contract resets through the standard bindContract() flow; in-place flag changes after first approval are simply not supported.

A service contract holds BUCKs temporarily on behalf of others. The Notes pool holds face value until a note is spent; an AMM pool holds liquidity waiting to be paired; the Jubilee fund holds collected demurrage waiting to be deployed. None of these accounts are economic principals – they are conduits, and the demurrage they "owe" is owed in substance by the parties whose value they hold for.

Forced to crystallise on outflow like an ordinary EOA, a Carrying contract would either degrade the funds it manages (absorbing the fee from its own holdings) or push fresh un-aged BUCKs onto recipients (mis-pricing the value). Carrying preserves the age basis: BUCKs that have sat in the Notes pool for six months arrives at the redeemer with six months of carried fee, and the redeemer's balanceOf reflects it. The aged value is delivered to the eventual beneficiary; no party is short-changed.

The CP receipt is checked symmetrically for any transfer between the two identities, regardless of which one ends up as msg.sender. When the spender is a service contract (isCarrying = true) and pushes BUCKs to the recipient, the recipient's prior approve has already established the receipt; the contract's Carrying transfer proceeds through the same identity-bilateral check as any other identity-bound transfer.

When a recipient simply wants to enable an incoming Carrying transfer (e.g., to receive future deployments from the Jubilee fund) without granting any spend allowance, they call Buck.approve(carryingAccount, 0, E_carryingAccount, pi_CP). This creates the receipt fragment without granting allowance. amount=0 is exactly the semantic the user wants: identity binding plus consent-to-receive without spending authorisation.

The first approve naming carryingAccount as the spender freezes isCarrying[carryingAccount]. A wallet UI presenting an approve confirmation should surface the current isCarrying value so the user can see whether they're consenting to a Carrying-flavour relationship; once they approve, the operator can no longer change the flavour.

The existing identity-bound approve applies unchanged: a Non-Carrying sender approves a spender with a non-zero allowance and a CP receipt; transferFrom checks both the allowance and the receipt. Non-Carrying transfers carry no fee debt to the recipient, so no extra consent dimension is involved.

For a BuckCredit insured at face F with lifetime L, closed at elapsed e (with e <= L):

function close(BuckCreditId):
    F = creditFace(id)
    L = creditLifetime(id)
    e = now - creditMintTime(id)

    fromJubilee = F * min(e, L) / L
    fromAlice   = F - fromJubilee

    Buck._accrueJubilee()                 // bring Jubilee current
    Buck._crystallize(alice)
    Buck._crystallize(jubilee)

    require(_balances[alice]   >= fromAlice,   "alice underfunded")
    require(_balances[jubilee] >= fromJubilee, "jubilee underfunded")

    Buck.super._burn(alice,   fromAlice)
    Buck.super._burn(jubilee, fromJubilee)
    // BuckCredit then releases the asset to alice and self-destructs.

Alice mints BUCK$100 at t=0 (F=100, L=50yr, no premium for simplicity). No further events for 50 years. At t=50yr, BuckCredit calls close:

1) _accrueJubilee():
     delta = 100 * 2%/yr * 50yr = $100
     super._update(0, jubilee, $100):  _balances[jubilee] = $100
     totalSupply: $100 -> $200

2) _crystallize(alice):
     _demurrage[alice] = $100,  _timestamp[alice] = t50

3) Split:
     fromJubilee = $100 * 50/50 = $100
     fromAlice   = $100 - $100  = $0

4) Burns:
     super._burn(alice,   $0):    no change
     super._burn(jubilee, $100):  _balances[jubilee] = 0
     totalSupply: $200 -> $100

5) Asset returned to alice; BuckCredit self-destructs.

Alice's _balances remains $100, but =_demurrage[alice]= = $100, so balanceOf(alice) = $0. The original mint has been fully redeemed: alice paid the $100 of demurrage over 50 years (it accrued in _demurrage[alice] at lien-close time), and the Jubilee fund burned the matching $100 it had accumulated.

Same setup, close at t=25yr:

1) _accrueJubilee():
     delta = 100 * 2%/yr * 25yr = $50
     _balances[jubilee] = $50,  totalSupply: $100 -> $150
2) _crystallize(alice):
     _demurrage[alice] = $50,  _timestamp[alice] = t25
3) Split: fromJubilee = $50,  fromAlice = $50
4) Burns:
     super._burn(alice,   $50):  _balances[alice]   = $50
     super._burn(jubilee, $50):  _balances[jubilee] = 0
     totalSupply: $150 -> $50
5) Asset returned, BuckCredit destroyed.

After early closure alice retains $50 of raw with =_demurrage[alice]= = $50, giving balanceOf(alice) = $0 immediately. The implementation may choose to clear _demurrage[alice] as part of close (freeing the residual immediately) or to leave it (let it re-amortise over the remaining "credit-free" period); this is a BuckCredit policy choice, not a Buck demurrage primitive.

BASE_RATE * totalSupply * elapsed is exactly the amount the Jubilee can offer at lien close, and it equals exactly what the holder has accrued in locked fees over that same elapsed period. Both sides sum to F over L for a credit that ages its full lifetime. No account compounds interest on demurrage; the rate is applied to raw _balances linearly, and Jubilee's accumulation tracks the same linear integral across all outstanding BUCKs.

In practice the Jubilee deploys its idle holdings to revenue-generating subsidiaries (AMM pools, parametric insurance, etc.) which earn at least the owed self-demurrage and return profits to the pool, so the worked-example simplification of "Jubilee accrues self-demurrage like any other account" rarely matters in production.

mapping(address => uint256) internal _demurrage;
mapping(address => uint64)  internal _timestamp;
uint64                      internal _jubileeLastUpdate;

Per-account _balances[a] continues to be inherited from OZ ERC20. No prior cumulative-index mapping; the (_demurrage[a], _timestamp[a]) pair captures all per- account state, and Jubilee accrual reads totalSupply() and the elapsed time directly.

mapping(address => bool)    public isCarrying;
mapping(address => bool)    public carryingFrozen;
mapping(address => address) public binderOf;
address                     public buck;             // set once via setBuck()

isCarrying[a] is set at registration / binding time and read on every Buck._update to dispatch the transfer flavour, plus on every balanceOf / balanceOfFees view to select the reporting branch. carryingFrozen[a] locks isCarrying[a] once any counterparty has approved. binderOf[a] records the msg.sender of bindContract (zero for EOAs). buck is a one-time governance setter naming the authorised Buck contract – the only address permitted to call markApproved.

function feeOwing(address a)          external view returns (uint256);
function balanceOfFees(address a)     external view returns (uint256);
function balanceOf(address a)         public  view override returns (uint256);
function rawBalanceOf(address a)      external view returns (uint256);
function jubileeBalance()             external view returns (uint256);

There is no transferCarrying public function. The two transfer flavours are dispatched internally based on IdentityRegistry.isCarrying(msg.sender) (or from for transferFrom).

// One-time governance setter for the authorised Buck contract.
function setBuck(address _buck) external;

// register() leaves isCarrying[msg.sender] = false; binderOf is unset.
// bindContract() takes an explicit isCarrying_ flag and records msg.sender
// in binderOf[target].
function bindContract(
    address target,
    BN254.G1Point calldata pk,
    ElGamalCT calldata E,
    bool isPublicIdentity_,
    bool isCarrying_
) external;

// Pre-approval reconfiguration.  Reverts if carryingFrozen[target].
function setIsCarrying(address target, bool value) external;

// Called from Buck.approve() to freeze the spender's flag.
// Reverts unless msg.sender == buck.  Idempotent.
function markApproved(address spender) external;

Receipt fragments and identity binding (existing IdentityRegistry flow) are layered on top unchanged: the identity check for both flavours of transfer happens at the public function boundary, before the demurrage logic runs. Buck.approve calls identity.markApproved(spender) immediately after writing the CP receipt so the spender's isCarrying flag becomes immutable from that moment on.

After early closure (e < L) the holder's _demurrage[a] reflects the locked fees from before the close. The holder retains some raw, but balanceOf(a) reads as zero until those fees re-amortise. close may zero _demurrage[a] (freeing the residual immediately) or leave it; this is a BuckCredit policy choice, not a Buck demurrage primitive.

address(this) is not auto-bound at Buck deploy time – it cannot be, since target.code.length > 0 fails inside the constructor. Governance can call bindContract(buck, ..., isCarrying=true) post-deploy to register Jubilee as a Carrying account, after which balanceOf(jubilee) equals raw and Jubilee outflows ride the carried fee. Until that call happens, Jubilee is treated as Non-Carrying: its balanceOf declines as its self-demurrage accumulates. In production the Jubilee deploys idle holdings to revenue-generating subsidiaries that offset the self-demurrage, so the distinction matters less than it appears.

A Carrying account whose policy is to hold BUCKs indefinitely will accumulate self-demurrage; a transfer of the full raw will push a large carried fee onto the recipient. The contract enforces only value <= _balances[from]; the recipient's prior identity-bound approve is the social control. Wallet UIs should surface the carried-fee amount during the approve flow so the recipient sees what they're consenting to.

The mint premium computed by _computePremium is routed to insurancePool, a Non-Carrying account. The insurance pool accrues demurrage on its holdings like any other Non- Carrying account; when it deploys funds it does so via standard Non-Carrying transfer. No special handling is required.