pSignals — Trust-Gated Agent Payment Settlement FAQ

pSignals answers a narrower question than MAS as a whole: once a payment has been authorized, how does it actually get settled, safely and verifiably, on-chain? It is the settlement half of MAS’s Payment Authorization Gate — the translation layer between an authorization decision and a real, signed, ERC-4337 transaction on Circle’s Arc L1. It does not decide whether a payment should happen; MAS’s Alignment Coordinator does that. pSignals makes sure that once the decision is made, execution is solid, isolated, and auditable.

MAS is the domain-agnostic alignment base layer: a Signal Engine, an Alignment Coordinator, and the Canonical Aligned State it produces. cSignals is the specialty-chemicals vertical built on top of that base, already live in production. pSignals is the payment and agent-commerce vertical — it extends MAS toward the boundary where an aligned decision becomes an economic action.

pSignals does not reimplement MAS’s alignment logic. It contains no Signal Engine and no Alignment Coordinator of its own. It needs one dependable answer to a question MAS is built to answer, and a settlement pipeline that can act on that answer without introducing a second point of failure.

Two agent-owned smart accounts were deployed counterfactually and funded on Arc Testnet (chain ID 5042002). Agent A submitted a signed ERC-4337 v0.7 UserOperation that deployed its account and transferred USDC to Agent B. Agent B, on receipt, submitted a return UserOperation that deployed its own account and sent a smaller acknowledgment payment back to Agent A. Both transactions are confirmed on-chain and visible on the Arc block explorer.

The result that matters is not the transfer size, which was intentionally small — it is that a counterfactual smart account can be brought into existence and made to transact on a brand-new settlement chain, entirely through a signature produced inside an isolated custody service, with construction, signing, bundling, and confirmation fully automated.

No — and this is worth stating plainly. The demonstration evaluates a payment gate (registry match, scope limit, confidence floor) and prints an authorized status before each transfer, but that evaluation is currently simulated, produced by the demonstration script itself rather than a running instance of MAS’s Alignment Coordinator.

The settlement pipeline is real and on-chain. The authorization decision that precedes it is not yet wired to the system designed to make it. The simulated checks mirror the exact fields the Alignment Coordinator is designed to evaluate, so closing the gap is a matter of replacing a print statement with a live call — not redesigning the authorization model. See 2.5 and 2.6 below.

Circle’s x402 protocol and Gateway are payment execution infrastructure — they make agent-to-agent payment HTTP-native and settle it cheaply at scale. They do not decide whether a given payment should be authorized, at what amount, or with what provenance record attached. That is the trust-arbitration question MAS’s Alignment Coordinator and Payment Authorization Gate answer, and pSignals is the settlement layer that carries their decision through to Arc L1 without becoming a second point of failure. Arc and x402 provide the rail; pSignals and MAS provide the reason to trust what travels on it.

A transfer request is turned into one signed ERC-4337 v0.7 UserOperation:

1. Derive the sender — a read-only call to the factory contract’s address-computation function, using the agent’s owner key and a UUID-based salt. The address exists before the account is ever deployed.
2. Check deployment state and nonce — via eth_getCode and the EntryPoint’s getNonce.
3. Construct initCode if undeployed — the first UserOperation for any agent both deploys its account and executes its first transaction in one signed step.
4. Attach a paymaster, per the configured gas model (see 2.3).
5. Compute the v0.7 UserOperation hash, folding in chain ID and EntryPoint address so a signature cannot be replayed elsewhere.
6. Sign through the isolated signer service (see 2.2) and submit to a bundler via eth_sendUserOperation.

Settlement is split across two services on purpose. The agent-facing service builds UserOperations but holds no private key material. The signer service is the custody boundary: it runs on the loopback interface only, never reachable from outside the machine it lives on, authenticates callers with a constant-time-compared bearer token, and signs via AWS KMS using a key that never leaves KMS. It determines the correct ECDSA recovery value by re-deriving the address from each candidate rather than assuming one, and normalizes high-s signatures per EIP-2. A compromise of the settlement API’s HTTP surface does not expose signing capability.

Three configurable modes: the account pays its own gas directly in USDC (possible because Arc uses USDC as native gas); a third party sponsors gas via a conventional paymaster policy; or the account pays gas in USDC through Circle’s on-chain Paymaster contract, authorized via a locally constructed EIP-2612 permit (Circle’s Paymaster has no hosted API of its own). For mainnet, the adopted model is a hybrid routed by tier: onboarding and small-value actions are sponsored, while larger transactions route through Circle’s Paymaster, keeping ASIP’s gas liability bounded rather than unbounded.

Three failures, each generalizing beyond this one chain:

• Paymaster simulation revert (AA23): Pimlico’s sponsorship endpoint simulates every UserOperation with a dummy signature first; a compliant paymaster should return a failure status, not revert. Arc’s testnet paymaster hard-reverted instead, so the testnet demonstration bypassed the paymaster entirely and paid gas natively in USDC.
• Signature wrapping (AA24): Standard SimpleAccount contracts validate an EIP-191-prefixed hash, not the raw hash a previous custom account implementation expected. The custody pipeline needed an explicit prefixing step added before signing.
• Stale gas-fee constants: A bundler rejected submissions because hardcoded fee constants, tuned for a different testnet, sat below what Arc’s live network actually required.

None of these are failures of the ERC-4337 standard itself — they are the parts of a settlement stack that diverge between a new chain’s actual deployed contracts and the assumptions baked in from a more mature chain.

ADP 8.5 is ALI’s planned cryptographic upgrade path for MAS as a whole: a zero-knowledge proof (Halo2 or Groth16) certifying that an agent’s output was derived from a verified, bounded knowledge base without fabrication or drift. In pSignals’ end-state design, that proof hash would be anchored on Arc L1 alongside the settlement transaction and the Canonical Aligned State version, turning a settled payment into a cryptographically complete provenance chain. It is a forward-looking integration point, not a current dependency of the settlement pipeline described in 2.1–2.3.

The target design wires the settlement pipeline into the full MAS pipeline: an agent registers with a principal-attributed identity and scope, the Signal Engine and Alignment Coordinator evaluate its contribution, the Payment Authorization Gate returns one of four statuses (authorized, reduced, held, or refused) instead of the demo’s single simulated status, and only an authorized or reduced status reaches settlement. At the settlement end, a provenance hash gets written to Arc alongside the USDC transfer, binding the agent’s identity, contribution fingerprint, authorization status, and aligned-state version to the transaction itself.

What remains is sequencing, not invention: the Alignment Coordinator, Agent Registry, and Canonical Aligned State already exist in MAS’s base layer. Closing the gap means wiring pSignals to call them instead of simulating their output, and adding the provenance-hash write at the point where a UserOperation is already being constructed.

• Runtime: Rust toolchain (Cargo workspace: crates/agent, crates/signer, crates/shared)
• Signing: AWS account with a KMS secp256k1 key (ECC_SECG_P256K1, ECDSA_SHA_256)
• Bundler: A Pimlico API key scoped for Arc Testnet / EntryPoint v0.7
• Chain access: Arc Testnet RPC (chain ID 5042002)

Configuration lives in config/.env (copy from config/.env.example) — never commit the filled-in .env.