Account Model

Design in Progress

The note structure and commitment scheme are under active development. We are exploring how notes can carry compliance requirements (ASP memberships) to ensure the bona fide rule - that anyone handling a compliant note was themselves compliant at the time. The model described here may evolve as we finalize the architecture.

Notes, Not Balances

UPP uses notes (like Bitcoin UTXOs) instead of account balances:

Ethereum:  Address → Balance (1000 tokens)
UPP:       Note A (500) + Note B (300) + Note C (200) = 1000 tokens

Transactions consume notes and create new ones.

Note Structure

interface Note {
  amount: bigint       // Token amount
  blinding: bigint     // Random value (hides commitment)
  origin: Address      // Original depositor (for compliance)
  sender: Address      // Who sent this note
  token: Address       // ERC-20 contract
}

Origin vs Sender:

origin = who first deposited. Used for ASP compliance. Only changes via merge.
sender = who sent this specific note. Changes each transfer.

Commitments

Notes are stored on-chain as hashes:

commitment = Poseidon(amount, blinding, origin, token)

Properties:

Hiding: Can't see note contents
Binding: Can't create duplicate commitments
Token-locked: No transmutation attacks

Nullifiers

Prevent double-spending:

nullifier = Poseidon(commitment, spendingKey, leafIndex)

When spent:

Nullifier computed in ZK proof
Published on-chain
Contract records it
Same note can never be spent again

Merkle Tree

All commitments stored in a LeanIMT:

Depth: 32 levels
Hash: Poseidon
Capacity: ~4 billion notes

Transfer Example

Alice sends 600 of 1000 UPD to Bob:

Note 0 is nullified. Notes 1 and 2 are new leaves.