Policy Service

The Policy Service is the second signer in SohoPay’s 2-of-3 MPC scheme — and it is mandatory. No payment settles without its co-signature, and it co-signs only after every policy check passes. This page explains what it enforces, where each rule lives (on-chain vs off-chain), and what happens when the service itself is unavailable. It assumes you’ve read the MPC overview or at least know that agent signatures alone can’t move funds.

​

What the Policy Service is

Under the 2-of-3 threshold scheme, an agent’s key share expresses intent to pay; the Policy Service’s share expresses approval. Because two shares are required for a valid signature and the future third-party share is not yet active, the Policy Service is in the signing path of every settlement today. That makes it the enforcement point for the whole protocol: policy isn’t checked alongside payments, it is a cryptographic precondition of them. This is the practical difference from a conventional payments API, where rules live in application middleware. An attacker who compromises an agent — or even parts of SohoPay’s own API layer — still cannot produce a settleable signature for a payment that violates policy.

​

Rules enforced

Before contributing its signature share, the Policy Service evaluates every payment against four rule classes: A payment that fails a check is rejected with a specific error rather than silently dropped: AGENT_NOT_ALLOWLISTED (403), INSUFFICIENT_CREDIT (402), RATE_LIMITED (429 with Retry-After), or AML_DECLINED (402). Handling for each is covered in Error Handling.

​

On-chain vs off-chain enforcement

The two enforcement layers trade flexibility for trust guarantees, deliberately:

• On-chain (allowlist). The allowlist predicate lives on Base. Even a fully compromised Policy Service could not settle a payment to a non-allowlisted address — the chain itself would reject it. This is the trust boundary operators can verify independently on Basescan, and it’s why the allowlist is the one rule that is slow to change but impossible to bypass (see Trust Model).
• Off-chain (credit, rate limits, AML). These rules need data the chain doesn’t have (real-time credit ledgers, screening providers) and need to change faster than contract upgrades allow — a new AML list should apply in minutes, not after a deployment. They are enforced at co-signing time, which is still before any funds can move.

​

Availability is payments-grade

Because the Policy Service sits in the signing path of every settlement, its availability is SohoPay’s availability. It is operated against the platform-wide 99.9% uptime target, with the same maintenance window (Sundays 02:00–02:30 UTC, announced a week ahead) and support response commitments. Full details in the SLA.

​

What happens when it’s down

The system is fail-closed by design: if the Policy Service is unreachable, no settlements occur. There is no fallback signer and no degraded mode — that is the security guarantee, not a limitation. Concretely, during an outage:

1. Payment submissions are accepted and queued, not rejected — you’ll see payments hold in a pending state rather than fail.
2. No new co-signatures are issued, so nothing settles and no funds move.
3. On recovery, queued payments are evaluated against current policy and settle in order. Orders that exceeded the 10-minute TTL during the outage expire with ORDER_EXPIRED and must be recreated.
4. Normal payment.settled / payment.failed webhooks fire as the queue drains, so downstream systems reconcile automatically.

​

Monitoring

Two ways to see the Policy Service’s health:

• Status endpoint. GET /status on either environment reports component health, including the policy/co-signing path:
  curl https://api-sandbox.sohopay.xyz/v1/status \
    -H "Authorization: Bearer $SOHOPAY_API_KEY"
  
  Response

  {
    "status": "operational",
    "components": {
      "api": "operational",
      "policy_service": "operational",
      "settlement": "operational"
    },
    "updated_at": "2026-08-22T10:15:00Z"
  }
  
• Observatory dashboard. The Observatory shows live co-signing latency, policy decision rates, and queue depth, so you can distinguish “payments are slow” from “payments are queued behind an incident”.

​

Common questions

​

Next steps