The audit ledger

Your standing tier isn’t a guess. It’s a read on a specific set of events stored in a database your model reads cleanly. This page is the user-facing view of the audit ledger. The architectural detail is at Security → Audit ledger.

​

What’s in the ledger

Every meaningful thing you do on Guild lands in one of two tables. Together they’re “the ledger.” Both tables are append-only. Once a row is written, it cannot be edited or deleted. By application code. By an engineer. By anyone short of dropping the database-level trigger that enforces this — and that action would itself be auditable. This is the structural property that lets a lender trust the ledger as a credit signal.

​

Why this matters to you

Three reasons.

​

1. Your work history is yours, forever

Every job you’ve completed, every review you’ve received, every payment you’ve earned — all of it is preserved. A future employer asking about your reliability can see (with your consent) a verified record. A future lender can see (with your consent) a verified earnings history. The platform can’t erase a job you did. We can’t pretend you ghosted when you didn’t. The record protects you as much as it informs others.

​

2. Disputes settle on data

If an employer disputes that you worked a day, the attendance row in the ledger settles it. If you dispute that the payment was for the right amount, the payment audit row settles it. We don’t relitigate disputes on testimony. We read the ledger.

​

3. Your standing builds on real ground

When the model reads your standing, it’s reading rows from this table. Not screenshots, not hand-coded estimates. Actual rows the system can prove are correct. Three months of consistent work compound into a score a bank can underwrite on. That’s the loop.

​

What you can see

Your transaction history page (guild.com.ng/wallet) reads from the payment-motions table. You see every credit and debit with the counterparty, the amount, the timestamp, and the source. Your standing-score page (/standing) reads from both tables to compute the signals behind your tier. We don’t expose every audit row directly to you — there are operational events (signature verifications, idempotency checks) that aren’t user-meaningful. But every event that affects your wallet, your standing, or your records is surfaceable.

​

What you cannot see

You see your own activity. You don’t see other users’ activity. (Obvious privacy boundary.) The aggregates a lender sees are computed from your audit data; you can see the same aggregates if you ask. But neither you nor a lender sees transaction-level details about your counterparties. “You received ₦12,000 from employer X” — yes. “Here’s the breakdown of every transaction from every employer in the last 90 days, with names” — yes, to you, the user. The lender sees the aggregate, not the names.

​

What persists forever

The audit ledger is the long-memory layer. Everything else is operational.

​

What happens if you delete your account

A user who deletes their account triggers an erasure workflow:

1. Personal identifiers (phone, name, address) are anonymised in the identity schema.
2. The encrypted KYC payload is deleted.
3. The audit rows persist with the anonymised user ID.

The trail is still there for transaction integrity (Guild needs to be able to reconcile historical payments). The link from “this row → this real person” is removed. If a future lender tries to read a snapshot for the deleted user, the snapshot fetch fails because there’s no longer a user record to read. If you want to download a copy of your data before deletion, the dashboard’s data-export feature gives you a signed JSON archive of everything we hold on you.

​

How the aggregates flow to a lender

The lender never sees the raw rows. They see aggregates. They verify the signature. They make a decision. You can revoke consent at any time. The next snapshot fetch fails.

​

What to read next