EDITORIAL ARTICLE
Privy and Turnkey: What Wallet Infrastructure Does for Agent Payments
An agent product can use a packaged agent-payment offering or combine wallet, signing, permissions and payment protocols itself. Privy and Turnkey are useful examples of the latter: they provide infrastructure for wallets and signing workflows, while application developers design the experience.
Evidence: Based on vendor documentation reviewed October 28, 2026. The configurations below are conceptual; we have not tested them. Mechanisms vary by product, account type and version.
Wallets, signatures and payments are different
A wallet address identifies or receives assets; a signature proves authorization by a key; a policy decides which requests can be processed; and a payment interaction coordinates buyer and provider. Infrastructure may cover several steps but does not automatically handle merchant fulfillment, refunds or business reconciliation.
Privy: configurable wallet control and policies
Privy’s wallet policy documentation describes authorization keys, threshold approvals, multifactor authentication and a policy engine. Its control models range from user to service control; actual powers depend on configuration.
The documentation gives examples such as transfer limits and recipient or contract lists and states that some policies run in a secure environment, while transfer-size restrictions depend on simulation currently running outside it. Evaluate each restriction and enforcement location rather than assuming every check occurs in the secure environment.
If an agent can pay three data providers but high-risk actions need user confirmation, check whether allowlists cover every call type the application uses and whether restrictions still apply to indirect contract transfers. These are design questions to test, not assertions about a particular configuration.
Turnkey: signing requests, policies and approvals
Turnkey’s policy documentation describes permitting or denying activities based on initiator, approval conditions and request content. Its examples include restricting a user to a target address; most actions default to denial without an applicable allow policy.
A key detail is that the documentation says the Root Quorum can bypass policies. Investigate who holds root access, credential security, quorum configuration and recovery, not just ordinary-user restrictions.
Comparing infrastructure
| Question | Privy documentation example | Turnkey documentation example | Verify |
|---|---|---|---|
| Who can act? | Authorization keys and thresholds | Users, policies and approval conditions | Administrator, recovery and service-account permissions |
| How are actions limited? | Amount, recipient and contract policies | Policies based on activity and request conditions | Covered assets, networks and call paths |
| Who controls funds? | User- or service-control configurations | Depends on organization and key configuration | Export, recovery, migration and ownership terms |
| How is a merchant paid? | Combine application and payment components | Combine application and payment components | Merchant protocol, asset and delivery interface |
| Costs | Product and agreement dependent | Product and agreement dependent | Free allowance, overages, network and support fees |
This is a reading framework, not an exhaustive comparison. Different configurations do not justify a security or price ranking from a single row.
When to choose infrastructure
Custom experiences, permission roles, existing identity systems or multiple payment methods may make composable infrastructure attractive. The trade-off is more integration, testing, failure handling and operations for the application team. This follows from the product layer; it is not a recommendation for any particular vendor.
Before building, verify networks and assets, policy coverage, administrator bypass, key recovery and migration, recovery of control during outages, and actual pricing. Test approval, rejection, expiry and revocation against the same task.
Continue with Privy’s product analysis.