Security

Predicate’s enforcement model is narrow by design. Enforcement on an enrolled asset runs through a single, purpose-specific onchain role that the asset’s administrator grants to Predicate. Administrative control of the contract remains with the issuer throughout, and the authorization can be withdrawn at the issuer’s discretion. This page describes the controls that surround that role: how the signing keys behind it are protected, how the infrastructure that uses them is operated, and what guarantees apply to the delivery and recording of enforcement actions. It is intended as an overview for security and engineering teams conducting an initial review.

Onchain authorization

Predicate does not hold, custody, or require access to an asset’s administrative keys. Enforcement is authorized by a dedicated role granted by the contract administrator: FREEZE_MANAGER_ROLE on EVM-based assets, and the blocker role on Stellar. Under the interfaces we recommend, this role is limited to freeze, unfreeze, block, and unblock operations against individual addresses. It carries no authority to mint or burn supply, transfer balances, upgrade the contract, or modify role assignments. The asset’s own contract therefore defines and enforces the scope of what Predicate can do.

Key management

The signing keys that authorize enforcement transactions are protected by multiple independent factors, such that no single operator, system, or credential can produce a valid signature on its own. Keys are never exposed to human operators and signing is performed exclusively through automated workflows. There is no operational procedure under which an individual handles key material directly.

Infrastructure and operations

The signing service is isolated from application-facing services and sits behind its own set of controls. The architecture is designed so that the compromise of any single component, including an application service, is not sufficient to produce a signed transaction. Production access follows least-privilege principles. Access is scoped to the role that requires it, logged, reviewed on a recurring schedule, and revoked as part of offboarding. All changes to production systems are peer-reviewed and built through CI rather than on developer machines. Production deployments require explicit human approval through a controlled release process; no individual is able to deploy to production unilaterally.

Delivery and availability

Enforcement actions that fail to land are retried automatically. Contracts that persistently fail enforcement are surfaced to Predicate’s operations team and reflected in the customer dashboard, so the issuer has visibility into the condition. Transactions are submitted through multiple RPC providers, allowing enforcement to continue through a single provider’s outage. The signing service itself is designed to withstand infrastructure failure, and its failover behavior is tested.

Audit trail

Every enforcement action is recorded with its originating source, the affected wallet, the resulting transaction hash, and the final outcome. Records are written to an append-only log and retained to support regulatory and law enforcement review. The same records are available to the issuer through the dashboard.