Skip to main content
This is the page for engineers and judges who want to see the whole picture before zooming in. Guild’s job is to do three things, well, and at scale.
  1. Carry every kobo through OPay — direct debit, payouts, virtual accounts, transactional SMS, webhooks. Twenty-three OPay surfaces wrapped in one client. Five fire on every demo.
  2. Talk to people on whatever rail they actually have — phone call, WhatsApp text, WhatsApp Calling, SMS, web. Voice agent in Nigerian English with code-switching. Intent engine across five languages.
  3. Write everything to an append-only ledger that a bank or microfinance institution can read with consent, in a signed format their underwriting model can verify.
Below is the whole system. Walk through it once at this altitude, then drill into any chapter on the left.

​
The system, end to end

Read the diagram top to bottom: who reaches us, on what channel, through what edge, into which service, talking to which downstream.

​
Headline numbers

​
Where the four pillars live

Guild was designed to ship all four pillars of the OPay Scholars 2026 challenge. The next chapters walk through each.

OPay API depth

The 23 wrapped surfaces. Why the wrapper looks the way it does. How the reconcile guard defends against signature-replay even if the secret leaks. Idempotency at every layer. The five demo-critical paths.

AI/ML layer

Standing model (XGBoost-class multiclass tier classifier). Matching model (lambdarank, four factors). Negotiation engine (Thompson sampling, online). Transcription (five languages). Why each model has the shape it does.

Use of data

The append-only audit ledger as the data substrate. Every webhook, every approval, every payment is a row. The standing model reads it. The Partner API reads it. The dashboard reads it. One source of truth.

Resilience & scale

Circuit breakers around every OPay call. Idempotency keys with Postgres-durable + Redis fast-path. Reconcile guard before any wallet credit. Demo-resilience tooling. The horizontal-scale path to a national footprint.

​
The shape of every request

If you only remember one diagram on this page, make it this one. Almost every transaction in the system follows the same shape. Three properties this shape gives us:
  1. Idempotent end to end. A retried request hits the Redis fast-path and returns the cached response. No double debits. No double credits. Ever.
  2. Audit-complete. Every step writes a row to an append-only table with BEFORE UPDATE OR DELETE triggers. The ledger is structurally immutable; even we cannot tamper with the history.
  3. Defense in depth on OPay calls. The reconcile guard means even if a webhook is forged with a stolen secret, we’d refuse to credit because OPay’s own verify endpoint would tell us no.

​
What lives where

​
The locked decisions, in one place

A short list of architectural commitments. Each is a choice we made deliberately and a chapter explains why.

Services in depth

Every backend service, what it owns, how it boots, how it talks to its neighbours.

OPay integration

The 23 wrapped surfaces. The reconcile guard. The five-times-during-a-demo flow.

ML layer

Four models. Each with the shape it has for a specific reason. The data they read.

Infrastructure

The VPS layout. CloudPanel. nginx. PM2. System services. Deploy.

SMS infrastructure

The Go gateway. The paired Android devices. Why two-way SMS runs through hardware we control.

SIP infrastructure

The Asterisk bridge. How WhatsApp Calling lands on Tola.

Inter-service comms

HMAC signing, skew window, nonces, replay protection.

Resilience & scale

Circuit breakers, reconcile guard, demo-resilience tooling, the partition path.