Skip to main content

​
Sovereignty Architecture

​
Anti-Surveillance by Design

​
The Core Principle

Leja witnesses events on behalf of users. Leja does not own those events. The RIN holder owns their residential identity. Leja is the infrastructure through which that ownership is exercised and verified — not the proprietor of that identity. This is not a privacy policy. It is an architectural guarantee. The design of the system makes surveillance structurally difficult — not just contractually prohibited.

​
Why This Is the Most Important Design Constraint

Leja will eventually hold the residential biography of millions of Nigerians. Every payment. Every property. Every dispute. Every behavioral pattern across three tracks of economic life. Without the sovereignty architecture, Leja’s value proposition becomes its greatest liability:
  • A government agency could compel Relvor LTD to expose all records for a region or ethnic group
  • A developer with database access could query any user’s full history
  • A data breach exposes not just passwords but entire life histories
  • A bad actor inside Relvor could sell residential patterns to landlords who use them to discriminate
The trust and permanence that make Leja valuable are the exact same properties that make Leja a surveillance infrastructure if the sovereignty layer is absent. The sovereignty architecture is what separates: “a company that holds your data” from “infrastructure through which you exercise ownership of your data.”

​
The Three Non-Negotiable Sovereignty Rules

​
Rule 1: Location is Always Approximate, Never Precise

In queryable fields: No query to Leja ever returns an exact address unless the RIN holder explicitly shares it for a specific, active, time-limited transaction. 
Trust Graph displays: "Yaba, Lagos" — not "14 Afolabi Street"
Service requests display: "within 2km" — not GPS coordinates
Trend timeline: LGA level — never street address
Property RIN: state + LGA — not full address
The exception: Exact address is shared transiently during an active, consented transaction (a service job accepted, a lease being signed, a short-let guest checking in). It is not stored in the queryable graph. It is transmitted for the purpose of that transaction and that purpose only. In the database: Exact addresses are stored in encrypted fields that require the user’s consent key to decrypt. The encrypted field exists. The key to decrypt it is not held by Leja alone — access requires user authorization. Enforcement: Every Prisma query that returns location data must pass through the location abstraction layer that enforces LGA-level output. No raw address field is returned by any API endpoint without explicit consent for a specific transaction.

​
Rule 2: Identity is Always Layered, Never Flat

What this means: A government agency, a developer, or a hacker who gains access to Leja’s database should find records that are useful for trust verification but not useful for physical targeting. How it works: Names are stored. Addresses are stored in encrypted fields. The Trust Graph that third parties query is a derived representation — not the raw record. The derived representation contains behavioral signals and tier indicators. It does not contain actionable personal information. 
Raw record (in database): name, encrypted address, full payment history
Derived representation (in API response): score tier, payment
  timeliness rate, tenancy duration pattern, dispute count
A landlord asking “can I trust this applicant?” gets the derived signal. They do not get the applicant’s full name, address history, and exact financial data. They get what they need to make a trust judgment — no more. Levels of identity exposure: 
Level 1 — Anonymous signal (no consent needed):
  Score tier, timeliness rate, stability score
  Visible to: any Leja-verified party querying a RIN

Level 2 — Named signal (standard consent):
  Full name, derived payment signals, Trend timeline (LGA only)
  Visible to: parties in active transaction with user's consent

Level 3 — Detailed signal (advanced consent, purpose-specific):
  Derived financial signals, employment stability indicator
  Visible to: named institutional partner with named purpose

Level 4 — Raw record (user + Leja action required):
  Exact payment history, full addresses, specific dates
  Visible to: the RIN holder themselves, and no one else by default

​
Rule 3: Access is Always Logged, Always Revocable

Every query is logged: Every query against any RIN — personal, business, or property — is logged with timestamp, querying party identity, query type, and consent basis. RIN holders see their own logs: Every personal RIN holder can see, in their Resident account:
  • Who queried their data
  • When the query was made
  • What consent level the query used
  • What derived signals were returned
Unauthorized queries fail immediately: If a party attempts to query a RIN without appropriate consent, the query fails with a 403. The RIN holder is notified of the unauthorized attempt within 1 hour. Consent is revocable: Any consent granted can be revoked by the RIN holder at any time. Revocation is immediate in the query layer — the consenting party’s API token for that RIN is invalidated immediately. What revocation does and does not do:
  • DOES: stop all future queries by that party against that RIN
  • DOES NOT: erase past queries or the data they returned
  • DOES: create a permanent log entry: “Access revoked: [date]”
  • DOES NOT: give the RIN holder any claim over decisions already made by the third party based on data received before revocation
Consent grant language must make this limitation explicit at the moment of granting.
A checkbox is not consent. A PIN is not consent. Leja’s consent model has a specific problem that generic SaaS products do not: the data being shared — Trust Graph signals, residential record history, residential identity — is consequential enough that a bad actor who gains access to a user’s session can consent to data sharing that harms the user permanently. A shared device, a stolen session token, or a coerced PIN provides no assurance that the actual RIN holder is making the decision. Biometric consent provides that assurance. The consent mechanism must be able to answer:
“Was this consent decision made by the person whose data is being shared — not just someone who had access to their device or session at that moment?”

​
The Three Levels — Ordered by Security (Weakest to Strongest)

​
Level 1 — Device Fingerprint

Mechanism: The user’s fingerprint is captured via the device’s biometric sensor (Touch ID on iOS, fingerprint sensor on Android). Verification is handled by the device’s secure enclave. Leja receives a pass/fail signal only — the fingerprint itself never leaves the device. What it proves:
  • The person with the registered fingerprint for this device is present
  • The device is the one registered to this RIN
Real-world security limits:
  • Device-bound: tied to one specific device. If the user changes phones, re-enrollment is required before Level 1 consent can be used.
  • Can be bypassed if the device is compromised at the OS level
  • Fingerprints can be lifted and replicated by sophisticated actors
  • Shared-device risk: if another person is enrolled on the same device sensor, they can satisfy Level 1 consent
  • Does not prove physical presence — fingerprint sensors do not have liveness detection by design
When required:
  • Standard third-party sharing (Consent Type 2 in NDPA framework)
  • Resident activation
  • Routine re-authentication within an active session

​
Level 2 — Facial Recognition via Camera

Mechanism: The user’s face is captured via the device’s front camera. A liveness challenge is presented (blink, turn head, or equivalent) to prevent photo and replay attacks. The captured frame is compared against the face registered at NIN_VERIFIED or DOCUMENT_VERIFIED tier. Match returns a confidence score. Below threshold, consent is rejected. What it proves:
  • The person whose face matches the registered face is physically present
  • Liveness detection confirms a real face, not a photograph or deepfake
  • Person-bound, not device-bound: this works regardless of which device the user is on, as long as the camera is available
Why it is stronger than Level 1:
  • Does not require a specific device — the identity check is on the person, not the hardware
  • Liveness detection is meaningfully harder to bypass than a fingerprint sensor at scale — it requires a real-time, present-moment match
  • Harder to delegate: you cannot give someone your face the way you can hand them your phone
  • Shared-device risk eliminated: being on someone else’s phone does not help you pass facial recognition as a different person
Real-world security limits:
  • Requires liveness detection to be meaningful. Without it (2D face unlock), facial recognition is weaker than fingerprint — it can be bypassed with a photograph.
  • Deepfake attacks are a real threat if liveness detection does not include depth sensing or adversarial detection
  • Camera quality and lighting affect match reliability — low-confidence matches must be rejected, not accepted with a warning
  • Environmental conditions (darkness, partial occlusion) may force fallback to Level 1 in some contexts — this fallback must be logged and limited
When required:
  • Advanced third-party sharing (Consent Type 3 in NDPA framework)
  • Institutional API — Score Report (Consent Type 4)
  • Consent grants that will remain active for more than 7 days
  • Any consent action taken on a new or unrecognized device

​
Level 3 — Device Fingerprint + Facial Recognition (Both)

Mechanism: The user must pass Level 1 (device fingerprint) and Level 2 (facial recognition with liveness) simultaneously or in immediate sequence within a single consent session. Both signals must pass within the same 60-second window. Neither alone is sufficient. What it proves:
  • The person whose face matches the registered face is present (Level 2)
  • They are using their registered device with their registered fingerprint (Level 1)
  • Three implicit factors are satisfied simultaneously:
    • Possession: their registered device
    • Biometric A: their registered fingerprint
    • Biometric B: their face with liveness confirmation
Why it is the strongest:
  • An attacker would need: the user’s physical device, a working fingerprint match on that device, AND the ability to pass facial liveness detection with the user’s face — simultaneously, within a 60-second window
  • Delegation is architecturally impossible: you cannot give someone all three at once without being physically present
  • Even a coerced consent event leaves biometric evidence: both the fingerprint and the facial capture are logged as part of the consent record
Real-world security limits:
  • Physical coercion: the only remaining attack vector. If someone forces the user to present both biometrics, Level 3 can be satisfied under duress. This is a limitation of all biometric systems — not unique to Leja. Future mitigation: duress pattern detection (tremor, gaze patterns) as an advisory signal only — never an automatic block.
  • Accessibility: some users cannot satisfy both (damaged fingers, facial conditions). An accommodation path must exist and be logged.
When required:
  • Federated computation consent (Consent Type 5 in NDPA framework)
  • Revocation of a previously granted institutional consent
  • Any consent involving a named institution with a purpose-specific query that will run more than once
  • Milestone Wave 4 on-chain consent recording (the signature authorizes the Solana transaction — Level 3 is the key ceremony for on-chain consent)
LEVEL 1 — Device Fingerprint
  Factor:    Something you are (fingerprint) + something you have (device)
  Proves:    Registered user on their registered device
  Weakness:  Device-bound, no liveness, shared-device risk
  Required:  Standard sharing, Resident activation, routine re-auth

LEVEL 2 — Facial Recognition (with liveness)
  Factor:    Something you are (face, with proof of presence)
  Proves:    The actual person is physically present
  Weakness:  Liveness quality matters; deepfake risk without depth sensing
  Required:  Advanced sharing, Score Reports, new device, 7+ day consents

LEVEL 3 — Both (device fingerprint + facial recognition)
  Factor:    Possession + biometric A + biometric B, within 60 seconds
  Proves:    The right person, on their device, physically present
  Weakness:  Physical coercion only; accessibility accommodation required
  Required:  Federated computation, institutional consent, on-chain (Milestone Wave 4)

​
Implementation Rules

  1. Level 1 never downgrades to PIN or password. If the fingerprint sensor is unavailable, the consent action is blocked — not redirected to a PIN. PIN is session authentication, not consent authentication.
  2. Level 2 requires a liveness challenge every time. A stored facial image from a previous session is not sufficient. The capture must be live.
  3. Level 3 requires both to pass within the same 60-second window. A fingerprint from 10 minutes ago does not count. The session is fresh.
  4. All biometric consent events are logged in full:
    • Timestamp (millisecond precision)
    • Level used
    • Confidence score (facial recognition)
    • Device identifier
    • Consent payload hash (what exactly was consented to)
    • Result: PASSED / FAILED / TIMED_OUT
  5. Failed biometric consent is logged and shown to the RIN holder. Three consecutive failures within one hour trigger a notification: “Someone attempted to consent to data sharing using your account and failed.”
  6. Biometric data never leaves the device (Level 1) or Leja’s servers (Level 2). For Level 1: the secure enclave result is pass/fail only. For Level 2: the facial capture is compared server-side against the registered template, then immediately discarded. The capture is never stored beyond the matching operation.
  7. Accessibility accommodation for Level 3: Users who cannot satisfy both biometrics due to a documented condition may request an alternative path via support. This path requires identity verification via a Leja-witnessed in-person process. It is logged as “Accommodation: Level 3 equivalent.” It is not a downgrade — it is an equivalent assurance through a different channel.
Applied to every feature before it ships:
“If a bad actor — hacker, corrupt official, stalker, kidnapper — gained access to this data, what is the worst they could do?”
If the answer includes physical harm: The data must be further abstracted before it is stored in queryable form. If the answer is “identify the person and contact them:” The data must be gated behind at least Level 2 consent. If the answer is “understand their behavioral patterns:” This is acceptable — behavioral patterns are what the Trust Graph is for. But patterns must be derived, not raw, and consent must be appropriate. If the answer is “nothing harmful:” The feature passes the test. This test has no exceptions. It applies to every surface, every API endpoint, every new data field, every integration, forever.

​
The Federated Computation Model

For institutional use cases (banks, lenders) that need deep signals: The bank does not get Leja’s data. The bank gets the benefit of Leja’s data. 
How federated computation preserves sovereignty:
  1. Bank submits proprietary risk model parameters to Leja endpoint
  2. Leja AI runs the bank's model against anonymized user data in sandbox
  3. Bank receives only the model's output score
  4. Raw data never leaves Leja's infrastructure
  5. User consent: named bank, named purpose, time-limited, revocable
This means:
  • A bank can use Leja’s residential data to improve their mortgage model
  • The bank never holds any Leja user’s personal data
  • If the bank is breached, no Leja user data is exposed
  • If the user revokes consent, the bank can no longer run computations

​
What Leja Cannot Be Used For

By design, Leja’s architecture prevents: Mass surveillance: No bulk export of user data. No query that returns all records in a region without individual consent for each record. Targeted physical harm: No query returns an exact current address for any RIN holder. Location data is always at LGA level minimum. Discrimination at scale: No query returns data that could be used to systematically discriminate against groups — ethnic, religious, geographic, or otherwise. Data returned is behavioral, not identity-categorical. Government overreach: Leja cannot comply with a government order to expose “all records for residents of [area/group]” because the system does not support bulk, unconsented extraction. Individual records require individual consent. The Milestone Wave 4 on-chain consent rail makes this architecturally enforced, not just policy-based.

​
Sovereignty Maturity Labels

These labels describe maturity and dependency order. They are not standalone execution doctrine; build order comes from milestone loops. 
Milestone Wave 1 (MVP — in data model from Day 1):
  - Location stored as LGA in all queryable fields
  - Exact address in encrypted field (access logging schema present)
  - Consent architecture in data model (UI not yet built)
  - No third-party API access (no sovereignty risk yet)

Milestone Wave 2 (Resident launch):
  - Access log visible to RIN holder in Resident UI
  - Consent grant and revocation UI live
  - Standard and advanced consent tiers enforced
  - Unauthorized query notification to RIN holder

Milestone Wave 3 (Institutional API):
  - Federated computation endpoint with full consent enforcement
  - Purpose-specific consent language per institution
  - NDPC registration complete
  - All institutional queries logged and user-visible

Milestone Wave 4 (On-chain consent):
  - Consent transactions recorded on Solana
  - Revocation on-chain — independent of Leja database
  - User holds cryptographic proof of consent history
  - ZK proofs for highest-sensitivity disclosures