OCS Architecture Overview
API-Native Policy Enforcement — Production Today
1. Current Architecture (Phase 1 — Live)
The production system is an API-native pre-transaction evaluation layer. A wallet or application calls the PGTAIL engine before signing any transaction. The engine evaluates the proposed action against the user's active policy and returns a structured decision. No custody, no key access, no infrastructure change required.
| Layer | Component | Function | Security Role |
|---|---|---|---|
| Policy Control | Dashboard | Policy Configurator UI | User configures postures, guard thresholds, and deploy policy to the engine. No code required. |
| Evaluation | PGTAIL Engine | Pre-transaction risk evaluation API | 60+ guards evaluated against active policy. Returns allow / warn / hold / block with full audit log. |
| Storage | PostgreSQL (RDS) | Policy and registry persistence | All deployed policies, postures, guard states, and decision logs stored with full history. |
| Infrastructure | AWS EC2 + ALB + ACM | Production deployment | Health endpoints, TLS termination, Docker containerization, Prometheus observability. |
| Caller | Wallet / dApp / Integration | Calls PGTAIL before signing | The calling application acts on the decision before the transaction is submitted to any chain. |
2. Transaction Evaluation Flow
Protection happens before signing — in the only window where the outcome can still be changed.
- Policy Configuration: User sets their protection profile in the OCS Policy Configurator — posture, guard thresholds, registry entries. Policy deploys to the PGTAIL engine immediately.
- Pre-Sign Submission: Before a transaction is signed, the wallet or application submits the proposed action to the PGTAIL API: from address, to address, amount, token, and context.
- Guard Evaluation:PGTAIL runs the proposed transaction through 60+ active guards — registry matching, behavioral analysis, velocity checks, sanctions screening, token risk, approval risk — against the user's active policy.
- Structured Decision: The engine returns allow, warn, hold, or block — with the full guard result set, scores, and policy state logged for audit.
- Caller Acts: The wallet or application enforces the decision before submitting to any blockchain. Block means the transaction is not signed. Hold means the user must confirm within the hold window before signing proceeds.
3. Threat Mitigation Model
PGTAIL addresses the structural failures in the current ecosystem — not by replacing key management, but by adding a policy gate before any funds move.
Custodian / Insider Override
OCS holds no custody and issues no overrides. Policy is the user's. The engine evaluates it and returns a decision — no third party can override a block.
Unauthorized Destination (Phishing, Address Poisoning)
Registry guards check the destination against blacklist and graylist before signing. Whitelist-only mode blocks every non-approved destination, regardless of how the address was obtained.
Bulk Drain / Velocity Attack
Velocity guards track rolling spend patterns. The sovereign cap and block threshold stop large or anomalous transfers before they are signed — not after they settle.
Compromised Front-End (Supply Chain)
Even if the UI submits a tampered destination, PGTAIL evaluates it against policy before the transaction is signed. A substituted blacklisted address is caught at evaluation time.
Approval Drain (Malicious Token Approvals)
Approval guards check allowance size and simulate the approval before signing. Multi-step drain patterns and unlimited approvals are flagged or blocked per policy.
No Kill-Switch During Live Exploit
The E5 incident switch gives users an immediate engine-wide lockdown: PGTAIL blocks all non-whitelisted destinations until cleared. One action, immediate effect.
4. Protocol Architecture — Roadmap
The API layer is the foundation. Each phase extends enforcement closer to the protocol itself.
Phase 4A — Smart Account Contracts
Contracts written, public testnet deployment is the next milestonePolicyRegistry.sol and SmartAccount.sol are written and tested on a local OP Stack testnet. The SmartAccount calls the PolicyRegistry before executing any transfer — non-approved destination = transaction rejected at the contract level, without a backend API call. Deploying to OP Sepolia (Optimism public testnet) is the next milestone.
Phase 4B — Sequencer-Level L2 Enforcement
Vision — long-termA forked OP Stack L2 with PGTAIL integrated as a mandatory pre-execution hook in the sequencer's transaction ordering logic. Every transaction on the chain goes through PGTAIL automatically — no smart account adoption required, no API integration required by the application. This is the endgame: policy enforcement as a fundamental property of the network itself.
The intelligence layer is built and working. The remaining phases extend its reach — from API to smart account to sequencer — without changing the core evaluation logic.