Are you an LLM? Read llms.txt for a summary of the docs, or llms-full.txt for the full context.
Skip to content

Architecture

Who it's for: Developers and technical evaluators who want to understand how Shika's services, contracts, and identity layer connect before building on top of them. Why it matters: Every service is isolated and independent, so teams can integrate one product — say, savings groups — without taking on the complexity of the full stack.

How Shika Is Built

Shika is a stack of independent backend services that sit between your app and a set of smart contracts on Base. Each service owns one domain — identity, stablecoins, savings, lending, liquidity, or real-world assets — and exposes a clean HTTP API.

All services share one rule: no user ever touches a private key. Transactions are submitted through Shika Wallet on behalf of the user's address.

Layers

Your App (mobile or web)
        ↓
Shika API Services
  Identity · Stablecoin · Savings · Lending · Liquidity · RWA
        ↓
On-Chain Protocol (Base Mainnet)
  Identity registry · Stablecoin · Lending pools
  Savings pools · Liquidity engine · RWA tokens
        ↑
Automated Keepers
  Price feeds · Late payment detection · Default processing

Identity as the Root of Trust

Who it's for: Any user of any Shika product — they benefit from this automatically, without any extra steps. Why it matters: Verifying once and reusing everywhere means users in Ghana are never asked to re-upload their ID just to switch from savings to borrowing.

Every user completes KYC once. That verification is stored as an on-chain credential — silently checked by every product without the user doing anything extra.

User completes biometric KYC
        ↓
Shika issues an on-chain identity credential
        ↓
All products check that credential automatically:
  Borrow · Provide liquidity · Hold RWA tokens · Open collateral positions

How Writes Work

Every state-changing action follows the same pattern — your app never waits for a blockchain confirmation:

1. App calls POST /resource/action
2. Service validates the request
3. Transaction submitted via Shika Wallet
4. Service returns { id, status: 'pending' } immediately
 
When the transaction confirms on-chain:
5. Background job picks up the event
6. Status updated to 'active' or 'complete'
 
App polls GET /resource/:id to check finality

Service Isolation

Each service has its own database and owns its domain fully. There are no cross-service database joins — services communicate over internal bindings when needed (e.g. identity checks at loan time).