BengarTrust infrastructure

Architecture

How the pieces fit

Five services, four trust boundaries, and one rule: the thing that decides is not the thing that holds the keys, and neither is the thing that witnesses.

The path of one request

   Human  ·  AI agent  ·  Your backend
                    │
                    │  POST /v1/authorize      (API key)
                    ▼
        ┌───────────────────────────┐
        │        GATEWAY            │   decides · executes · records
        │                           │
        │   Permit  ∩  Policy       │   the meet, never the sum
        │      ∩  Risk / Approval   │
        └───────────┬───────────────┘
                    │
        ┌───────────┴───────────┬──────────────────┐
        ▼                       ▼                  ▼
   EXECUTION               CUSTODY             AUDIT
   merchant call           mTLS · signs        append-only
   idempotent              never exports       batched
   UNKNOWN is a            a key               │
   real outcome                                ▼
                                          ANCHOR  ──▶  BENGAR CHAIN
                                                       witness · finality
                                                            │
                                                            ▼
                                                        INDEXER
                                                     derived read model
                                                            │
                                                            ▼
                                                          SCAN
                                                       public, read-only

The boundaries, and what each one buys

Gateway ↔ Custody

Mutual TLS, and the Gateway is on an allow-list rather than merely holding a certificate from the right CA. What crosses is a semantic operation from a closed set — never bytes, a digest, a raw sign document or a type URL, because there is no field for one.

A fully compromised Gateway gains the ability to ask for signatures over operations it could already ask for. It does not gain a key, and it cannot ask for anything outside the set.

Gateway ↔ chain

One direction only, and never in the hot path. The Gateway anchors audit roots; the chain never calls the Gateway, and an authorization does not wait for a block. A chain outage delays anchoring and stops nothing else.

Indexer ↔ Scan

Scan’s server reads the Indexer; browsers read Scan. The Indexer needs no public exposure and no CORS policy, and an indexer error’s detail never reaches a browser. The Indexer is a derived model — the chain remains the authority, and every answer carries the height it was derived at.

Wallet

Entirely separate. The key is generated and used in the browser and is never sent to a Bengar server. The wallet is not part of the authorization path and holding an account grants no Trust authority.

What runs where

ServiceHoldsReachable from
GatewayTenant data under row-level security. No signing key.Your backend, and the Console
CustodyApproval and chain signing keys, encrypted at rest.The Gateway only, over mTLS, on an internal network
IndexerA derived read model, rebuildable from the chain.Scan’s server
Chain nodeBlocks, anchors, Trust records, assets.The Indexer, and anybody running a node
Console / Scan / WalletNothing secret. Scan holds no session at all.Browsers

Failure behaviour

When this is downWhat still works
CustodyAuthorization and execution. Approval ceremonies cannot complete, and a lost answer is UNKNOWN rather than a retry.
The chainEverything except anchoring, which resumes. Existing proofs stay verifiable.
The IndexerEverything except Scan, which reports NOT READY rather than serving a stale number as current.
RedisDecisions. Counters rebuild, and a lost counter is treated as lost rather than as zero.

The security model →