How it works
PGTAIL is live today: your wallet or application calls the engine before a transaction is signed. Policy is defined in the OCS Policy Configurator, stored in the engine, and evaluated in milliseconds. Forensics and deeper institutional integrations are on the roadmap below.
1. Configure Your Policy
Policy Configurator
You define your protection rules in the OCS Policy Configurator. Choose from five named postures — Standard through Zero-Trust — or build a Custom policy with per-guard control. Configure which threat vectors are active, set thresholds, deploy. Your policy is stored in the PGTAIL engine and applies immediately.
2. PGTAIL Pre-Transaction Evaluation
Before funds move
Before a transaction leaves your wallet or application, it is submitted to the PGTAIL engine for evaluation. PGTAIL checks the proposed action against your active policy: 60+ guards covering behavioral patterns, registry matches, approval risks, network health, and transaction anomalies. This evaluation happens before signing — while the decision can still be changed.
3. Structured Decision
Allow, warn, hold, or block
PGTAIL returns a structured result: allow, warn, hold, or block. Blocks occur only when policy explicitly demands them — clear deny-list matches, posture-defined thresholds, or guard-level triggers. Every decision is logged with full context: which guards fired, what scores were assigned, what the policy state was at evaluation time.
On the Roadmap
Phase 2 — Forensics: Case intake, transaction graph analysis, pattern extraction, and law enforcement evidence packages. Every investigated case feeds back into prevention policy.
Phase 3 — Institutional API: SDK and SLA-backed integration for exchanges and custody providers. The same PGTAIL engine at institutional transaction volume.
Phase 4 — Protocol-Native Enforcement: On-chain smart account contracts enforce policy at the transaction execution layer. Policy is embedded in the account itself, not just the API layer. Testnet deployment is the next milestone.