SkillLedger

The decision

SkillLedger encrypted its wallet balances at the column level (AES-256-GCM ciphertext, not a plaintext integer), so the database itself could never read a balance. That choice moved overdraft protection out of SQL and into the application: balances could not be summed, indexed or constrained at the database layer, so every balance check ran as C# logic inside a Serializable transaction instead.

In exchange, a leaked database export would have exposed no balances, and every transaction row carried an HMAC-SHA256 signature, with a KeyIdentifier column reserved for key rotation.

A self-commissioned audit of that wiring later found gaps between the design and the running code: Program.cs never bound the key-vault configuration, so the flag gating a real Azure key stayed false in every environment and both signing keys resolved to hashes of hardcoded string constants; the branch that does reach Key Vault fetches a real key object and then discards it, deriving the AES key as a hash of the key’s name and the current calendar month instead, so wiring the flag correctly would not have fixed it; and the key-rotation method behind the KeyIdentifier column logged “not yet implemented” and returned true, reporting success on a rotation that never ran. None of it touched the column-level encryption itself: the database still never held a plaintext balance.

Architecture

Three .NET projects (Api, Core, and Infrastructure) sat in front of a Next.js frontend, over PostgreSQL. Program.cs was the composition root, and every one of its 93 service registrations was inline.

The project moved from SQL Server to Postgres in February 2026 and collapsed everything before that into one InitialPostgresCreate, so three EF Core migrations covered the 70-table schema.

Escrow held credit between agreement and delivery, and its six-state lifecycle was modelled as methods on the entity itself rather than scattered conditionals. Active and PartiallyReleased are the hub of the machine, and the repository draws it as two graphs rather than one, because all seven of their outbound transitions on a single graph put the labels close enough to merge:

money moving forward
  (start) -> Active                      client funds the project
  Active -> PartiallyReleased            a milestone is released
  PartiallyReleased -> PartiallyReleased the next milestone
  Active -> Completed                    one release covers the total
  PartiallyReleased -> Completed         releases reach the total
  Active, PartiallyReleased -> Cancelled

the account paused or contested
  Active, PartiallyReleased -> Disputed
  Active, PartiallyReleased -> Frozen
  Frozen -> Disputed
  Disputed, Frozen -> Active             nothing released yet
  Disputed, Frozen -> PartiallyReleased  something already released

Every arrow is a real call site rather than an inferred state. The four release edges are gated on CanBeReleased, and the two resume edges carry a guard on the amount already released, which is why Frozen and Disputed return to PartiallyReleased instead of Active once anything has gone out. The four transitions that move credit (funding, milestone release, full release and cancel) are each written from inside a Serializable transaction, and each release or refund writes a row through the same signed transaction log: the state machine and the ledger are two views of one write. The four that only change state (dispute, resolve, freeze, unfreeze) save without one.