Architecture

System Architecture

The Sinai Standard is a four-layer stack: a Dashboard UI, a Compliance Oracle API, an SDK, and on-chain programs.

  +------------------------------------------------------+
  |                    Dashboard                         |
  |                   (Next.js 14)                       |
  |   Token management, compliance monitoring, KYC UI   |
  +----------------------------+-------------------------+
                               |
  +----------------------------v-------------------------+
  |                 Compliance Oracle                    |
  |                    (Express)                         |
  |   REST API · KYC Adapters · Webhooks · WebSocket    |
  +----------------------------+-------------------------+
                               |
  +----------------------------v-------------------------+
  |                      SDK                             |
  |               (@sinai-standard/sdk)                  |
  |   AksumKit · Managers · PDA Helpers · Types          |
  +----------------------------+-------------------------+
                               |
  +----------------------------v-------------------------+
  |                On-Chain Programs                     |
  |                  (Anchor / BPF)                      |
  |   Token Factory · Allowlist · Tax · Hold ·           |
  |   Max Balance · Router · SSTS Verifiers              |
  +------------------------------------------------------+

• Dashboard — Web UI for issuers to create tokens, manage allowlists, configure hooks, and monitor compliance events in real time.
• Oracle — Express server that bridges off-chain KYC providers to on-chain allowlists. Listens to chain events and dispatches webhooks and WebSocket streams. See Compliance Oracle.
• SDK — TypeScript library for building and signing Solana transactions. See SDK Reference.
• On-Chain Programs — Anchor programs deployed on Solana that enforce compliance rules at the protocol level. See Programs.

Hook Composition

The Sinai Standard uses Solana's Token-2022 TransferHook extension to enforce compliance at the protocol level. Every transfer is validated on-chain before it can complete.

                    Token-2022 Mint
                         |
              +----------+----------+
              |                     |
        TransferHook ext    ConfidentialTransfer ext
              |                  (native Token-2022)
   +----------+----------+
   |          |          |
Allowlist  Tax Hook  Hold Hook  Max Balance
  Hook                  Hook       Hook
   |          |          |          |
   +-----+----+-----+---+-----+---+
         |          |
    Router Hook   (single hook)
   (multi-hook)

Single Hook Mode

When only one compliance feature is needed, the mint's TransferHook extension points directly to that hook program. This is the simplest setup and has the lowest compute cost.

Multi-Hook Mode (Router)

When two or more features are needed, the mint points to the Router Hook, which chains sub-hooks inline in order:

1. Allowlist — checks that both source and destination are on the approved list
2. Tax — logs the transfer for later tax collection via Permanent Delegate
3. Hold Period — verifies the source wallet's lock-up has expired
4. Max Balance — ensures destination wallet stays within per-wallet cap

The Router reads each sub-hook's config account directly (raw byte deserialization), rather than using CPI calls. This keeps compute usage within Solana's transaction limits.

Confidential Transfers

The Confidential Transfer extension is a native Token-2022 feature (not a custom Sinai Standard program). It encrypts on-chain balances and transfer amounts using ElGamal encryption. Only the account owner and an optional auditor can decrypt actual values.

Confidential transfers can be combined with TransferHook-based compliance features. A token can have both the TransferHook extension (for allowlist, tax, hold period, max balance) and the ConfidentialTransfer extension enabled simultaneously.

AksumKit Auto-Selection

AksumKit.createToken() automatically selects the right mode:

Data Flow

Transfer Execution

1. User calls transferChecked on Token-2022
2. Token-2022 invokes the TransferHook program (CPI)
3. Hook program validates the transfer against its config
4. If valid, transfer completes; if invalid, transaction reverts

Tax Collection

Tax is collected in a separate step (not during the transfer):

1. During execute (TransferHook CPI), the tax hook logs the transfer
2. A separate collect_tax instruction uses the Permanent Delegate PDA to burn/transfer the tax amount
3. This two-step design keeps the transfer CPI within compute limits

Account Structure

Each hook program uses two key PDAs per mint:

The ExtraAccountMetas PDA must be initialized before any transfer_checked call, or the transaction will fail.