EDITORIAL ARTICLE
Turnkey: Giving Agents Signing Ability Without Unlimited Authority
Project reference · Turnkey Wallet Infrastructure ↗Product analysis · Sources checked October 28, 2026. Based on public information; no real payment test was performed.
An agent does not necessarily need to see a private key to make a payment. Turnkey’s focus is to expose wallets, keys and signing through APIs, with policies defining who may request which signatures. For teams building payment, trading or asset-management agents, it is infrastructure, not an out-of-the-box shopping agent.
Company background and users
Turnkey’s team has experience in digital-asset custody. Its product targets developers and institutions that need to create wallets, manage keys and authorize signatures. See company information and its agent offering.
| User | Task | What they still need to provide |
|---|---|---|
| Agent developers | Create wallets and sign under policies | Task decisions, merchant selection and application experience |
| Payment or financial platforms | Embed signing into business workflows | Merchant connections, compliance and operational responsibilities |
| End users | Authorize according to the application’s design | An understanding of who can change policies and recover access |
How does a transaction work?
Suppose an agent needs to make a stablecoin payment. The application first establishes policies for the wallet and requester. The agent submits transaction details such as destination, amount and chain; only a request that meets the policy proceeds to signing. Verify policy capabilities and signing support for the relevant chain and integration. A signature alone does not guarantee that the provider delivers or offers a refund.
| Control layer | Question | Limitation |
|---|---|---|
| Identity and roles | Who may initiate or approve a request? | An administrator with excessive permissions might change normal transaction rules |
| Policy | Which destinations and operations can be signed? | Examine every signature type and the process for policy changes |
| Signing | Is a signature produced for an eligible request? | A signature does not establish that a product is genuine, useful or delivered |
| Submission and records | Who broadcasts and tracks the transaction? | The caller must handle retries, network fees and reconciliation |
Pricing and business model
The pricing page lists a usage-based Pay as You Go tier, a Pro tier with a monthly charge and lower signature fees, and custom enterprise plans. It also describes transaction management pricing per successful on-chain transaction and separate charging mechanisms for Swaps and Earn. Confirm current prices and billing terms with the provider and in the applicable agreement.
Analysis, not disclosed revenue: Turnkey’s business model is to sell secure signing and related transaction infrastructure, with potential expansion through usage, enterprise support and additional services. Public information reviewed here does not disclose agent-specific revenue.
Who should consider it?
A team that already has payment protocols, merchants and agents, and needs granular signing controls, can evaluate Turnkey for that layer. A team seeking an integrated service directory, purchasing and reconciliation will need other systems as well. When comparing Privy, DFNS or Fireblocks, ask for demonstrations of where restrictions are enforced, who can modify policies, key recovery, rejection logs, and coverage by chain and transaction type.
Breaking down an API purchase
Imagine a development team wants an agent to buy a $1 on-chain data service. The following is a design illustration, not a test. First create an organization, wallet and requester identity, and establish what the organization administrator, end user and agent can each manage. Then configure destination, permitted transaction types and approval rules, and test rejection in a test environment. Once the agent receives a payment request, the application constructs a request for signing; Turnkey checks the requester’s identity and policy. If approved, it signs; the application or its transaction-management service submits the transaction to the network. Finally, match the on-chain result to the provider’s order.
“Turnkey signed” establishes only that a signature was produced. Insufficient funds, network failure, a fee-estimation error or failed delivery may still prevent the purchase from completing. After a timeout, check request records and transaction status for an existing signature or broadcast before following the integration’s idempotency process; otherwise a retry may lead to duplicate spending.
| Risk event | First question |
|---|---|
| The agent enters 100 instead of 1 | Does the policy check that asset and amount, rather than just the destination? |
| The agent is induced to sign an arbitrary message | Does the policy cover messages and structured data as well as transfers? |
| A policy administrator’s account is compromised | Who can modify or delete policies, and which independent approvals are required? |
| The service is not delivered | Who supplies order evidence, refunds and human support? |
| A key needs recovery or migration | Who can recover, export or replace the key, and what happens when service ends? |
Pricing example: signatures and purchases are not necessarily equal
The pricing page listed 25 free signatures per month on Pay as You Go, then $0.10 per signature. Illustrative calculation: if exactly 125 billable signatures in a month all qualify for that tier and there are no other charges, signing alone would cost (125 − 25) × $0.10 = $10. Additional approval signatures, retries, transaction management, network fees or conversion can make the total different. Prices change; use the actual agreement.
The page also lists a monthly minimum and per-signature price for Pro. Ask the provider for a usage-based estimate, including any allowance and how different features are billed. When an API call costs only a few cents, even one extra signature cost per call can change the economics; the API price alone is not the complete bill.
Why teams may make different choices
Turnkey typically serves teams embedding keys, signing and policies in their own products. If they already have identity, merchant discovery, billing and reconciliation, Turnkey can address the key and transaction-signing layer. Otherwise, those pieces must also be built or purchased. Privy also provides wallets and policies with a more developed end-user login and embedded experience; Fireblocks is more focused on institutional governance and workflows. Judge the actual differences through supported networks, key control, policy-change permissions and support commitments.
Technical, risk and finance teams should jointly assess whether the system rejects over-limit transactions and restricts signable messages; whether policy changes require multiple people; whether an agent can be revoked; whether transactions reconcile to orders; and whether keys and historical data can migrate. Without testing in the actual environment, mark these as questions to verify rather than guarantees.
Contract questions beyond the technical decision
Ask the provider whether signing stops during critical outages and who is needed for recovery; whether keys can be migrated and with what approvals; how long logs are kept and whether policy changes are fully recorded; and what the agreement says about availability, security-incident notification and responsibility for customer funds. Institutional customers must also assess their own regional compliance obligations. Secure signing is not the same as the provider taking responsibility for identity checks, sanctions screening or merchant refunds. Since published pricing is per signature rather than per agent, measure signatures per task as orchestration becomes more complex. See Turnkey’s agent offering.
Before purchase, confirm the current Pro billing rules and the relationship between the monthly minimum and signature usage. For a multi-chain product, test each chain and signature format separately: successfully restricting one transfer does not establish that all signing requests have the same controls.
Sources: Agent offering; company background; pricing; developer documentation.