Stakestone 2.0 connects agent payment mandates with authorized settlement
Stakestone 2.0 describes agent payments that connect AP2 mandates with payment verification and settlement. An Intent Mandate defines the conditions for automated spending, while a Cart Mandate supplies transaction-specific terms. Verified terms become a payment intent that an authorized smart contract or an x402 facilitator can execute. Identity credentials, account permissions and the selected payment route govern execution. The user’s authorization defines the permitted spending; completing the payment requires successful settlement.
An account restriction can block an agent payment even when its signed mandate authorizes the proposed transaction.
Pre-authorized payments connect agents with paid services
An agent can use predefined authorization to pay for a service when the payment conditions are satisfied. The agent needs an identified account, payment authority and an execution route that the service supports. AI agents transacting through Stakestone must also pass Know Your Agent (KYA) verification. AP2, the Agent Payments Protocol, carries the authorization terms. x402 connects payment handling with access to a paid resource through an HTTP interaction.
An agent needs authority to fund the service that it requests. Its account permissions and mandate determine whether that payment falls within its authority. A merchant quotation contributes concrete transaction terms, including where the payment should go. The service integration must support the resulting payment.
The machine account binds identity to payment authority
The 2.0 account layer connects a machine’s onchain identity with its funding account and permission policies. It calls this arrangement an Identified Machine Account, or IMA. The identity also links the account to compliance modules. Its credentials and access controls matter when an automated action requests funds. Registering an identity and authorizing a payment answer different questions: who acts and what that account permits.
EIP-7702 supplies a way for an externally owned account to use smart-contract logic without changing its address. In this architecture, that logic supports programmable permissions and account controls. A mandate needs an account that can enforce the applicable rules. A familiar sign-in method concerns access to the account. It does not, by itself, define the authority that an agent receives or the settlement integration that the account supports.
Intent and cart mandates carry different payment terms
In the 2.0 design, an authorized Intent Mandate permits automated payment actions under predefined conditions.
AP2’s mandate model permits purchases without user cart confirmation only when the user has signed the Intent Mandate and its confirmation requirement is disabled. A merchant can separately require cart confirmation. The intent and cart also specify expiry times.
A Cart Mandate contains the merchant’s signed transaction terms. The design generates it from triggered pre-authorization conditions or merchant-side quotations. The system then performs two-way verification before packaging the data for execution. A quotation contributes terms for a proposed payment; it does not supply the account holder’s spending authority. Both the transaction terms and the relevant authorization must fit the payment that proceeds.
The payment intent packages verified execution data
The packaged payment intent includes the amount, recipient, execution conditions, contextual data and execution logic. The recipient identifies the destination for funds, while the conditions govern when execution is allowed. Context helps relate that instruction to the authorized task. Packaging follows verification in the 2.0 sequence. The resulting object is ready for an execution route to handle; its existence alone does not establish that funds have reached the recipient.
Smart contracts and x402 handle different execution paths
The 2.0 architecture provides a direct smart-contract route and a route through an x402 facilitator. Both use the verified payment intent. Their practical difference is which component handles payment execution and which settlement infrastructure the integration uses. That choice must fit the account’s authority and the payment service’s supported integration.
The 2.0 design permits direct execution of a payment intent by an authorized smart contract. It requires the deployed contract to have the relevant authority and execution logic.
A facilitator handles payment verification and settlement coordination for the other path. It verifies signatures and authorization, then executes settlement or forwards the transaction for onchain execution. The 2.0 design also describes offchain or hybrid settlement through facilitator integrations. The integration determines which of these routes it actually supports; the architectural alternatives do not establish one universal settlement method for x402.
Forwarding leaves execution to the receiving component. A valid signature can establish authority while the transfer still awaits execution. The settlement outcome answers whether the payment completed.
Account controls remain relevant whichever route handles the payment. The accepted asset and settlement environment belong to the deployed integration, so compatibility must hold at the account, executor and service. Shared use of AP2 does not establish the same asset or network support across the two routes.
What does HTTP 200 confirm in an agent payment?
HTTP 200 indicates a successful response, whose payment meaning depends on the service’s implemented payment flow. HTTP 402 signals that payment is required. The 2.0 design associates a success response with payment completion and service accessibility. In an HTTP-based x402 integration, the resource server returns the service response, while a facilitator reports verification and settlement results. A bare status code alone does not establish an onchain transfer or identify the recipient that received funds.
Account controls can prevent an otherwise authorized payment
Programmable account policies constrain spending even when the payment carries a valid mandate and signature. The 2.0 account design includes spending limits, multisignature controls, freeze policies and role-based authorization. Their effect follows the policy that the account actually applies.
A restricted account can encounter a payment that fits its mandate yet fails the applicable account-level rules. The compliance design records account states such as Compliant, Restricted and Pending. These states connect to transaction-level permission control. A valid mandate establishes one part of authorization; an applicable restriction can still prevent execution. The restriction affects permission to execute the payment, without changing the meaning of the signed terms.
A configured multisignature policy can require additional approval alongside the agent’s payment mandate.
Gas abstraction determines how execution fees are funded
Gas abstraction lets the account infrastructure sponsor or manage network fees on behalf of a payment user. The 2.0 design combines smart accounts with relayers and fee sponsorship. It also describes payment abstraction that allows verified assets to fund fees, with routing to handle conversions. The amount payable to the service and the cost of processing that payment remain separate inputs.
Institutions, protocols or merchants can sponsor gas within the architecture. A supported sponsor can change who bears the network cost, while a conversion route can change the asset used to fund it. Neither mechanism establishes a permanent zero-cost service. The applicable sponsor arrangement, accepted fee asset and conversion terms determine the practical cost. These choices need to fit the deployed route that executes the payment.
Compliance verification connects credentials with transaction rules
The compliance layer checks identity credentials and applicable transaction rules alongside the machine account’s payment activity. Its design combines zero-knowledge identity verification with anti-money-laundering controls. Certified identity providers validate identities and risk profiles, then issue compliance credentials. Those credentials allow onchain verification through proofs. This connects an account’s identity status with the permission rules that apply when it requests payment execution.
The architecture also provides programmable regulatory interfaces for transaction restrictions. Supported rule types include cross-border transfer limits, restricted address lists and reporting intervals. A payment mandate does not replace these rules. Transaction and settlement states feed back into risk controls and regulatory interfaces. The applicable rules can vary by jurisdiction and account status, so an account’s credential does not establish universal payment eligibility.
Payment settlement and yield-token redemption have different dependencies
A payment uses the settlement route for its account and service; yield-token redemption follows the relevant product’s accounting. The 2.0 balance-settlement design distinguishes Ethereum L1 transactions from activity in L2 or appchain environments. It associates larger, less frequent transfers with L1 and smaller, frequent payments with higher-performance execution environments. This is an architectural distinction, not a fixed numerical threshold that determines every agent payment’s network.
STONE redemption depends on ETH liquidity and the applicable withdrawal route. STONEUSD and STONEBTC involve custodial strategies and settlement coordination. A signed payment mandate does not complete a withdrawal or turn a pending redemption into funds available for payment. OPAP governs STONE portfolio allocation, which is separate from authority to execute an account payment.
Match the execution route to the account and service
Choosing between direct execution and a facilitator starts with the payment that the account is authorized to make. Direct execution suits a supported contract-based payment path. The facilitator path delegates payment verification and settlement handling to the configured facilitator. For paid-service access, that integration must also connect payment handling with the service response.
- Use the account’s actual agent permissions to determine whether the proposed payment is allowed.
- Match the amount, recipient and execution conditions to the verified payment intent.
- Choose direct execution only where the authorized contract supports that payment instruction.
- Choose the facilitator path only where its settlement route and the service integration are compatible.
- Keep account restrictions and fee-funding requirements in force whichever path handles execution.
An integration that supports only one execution path limits the available payment route. Account restrictions can also exclude the proposed payment. If the service’s supported path does not match the account’s permitted execution, the mandate alone cannot make that payment usable.
Common questions about Stakestone
Does each Stakestone payment mandate require a separate blockchain transaction?
The transaction count depends on the integration that executes the payment. Intent Mandates, Cart Mandates and packaged payment intents describe different authorization data within the 2.0 flow. Their names do not prescribe a separate blockchain transaction for each object or establish how the implementation groups its operations.
How do STO governance votes relate to agent payment authorization?
STO governance concerns protocol decisions, while an agent payment mandate concerns authority to carry out a particular payment. Converting STO to veSTO and locking it for voting power supports governance participation. Those rights do not, by themselves, authorize an agent to spend from a user’s account.
Can Stakestone payment infrastructure handle a foreign-exchange conversion?
The 2.0 fee layer includes routing that uses oracle-based exchange rates for asset conversions. That routing belongs to payment and fee infrastructure, while a mandate carries authorization terms. Whether a particular conversion can accompany a payment depends on the deployed route and the assets that it supports.
Is every detail of a Stakestone agent payment hidden by zero-knowledge identity verification?
Zero-knowledge identity verification keeps plaintext identity information private during onchain credential checks. It does not make the whole payment anonymous. The 2.0 design records transaction and settlement states for risk monitoring and regulatory reporting, alongside the credentials that establish the machine account’s compliance status.
What determines whether an x402 service accepts a Stakestone yield token for payment?
Acceptance of a yield token depends on the payment options that the service and settlement integration support. STONE, STONEUSD and STONEBTC have documented yield functions, which do not establish universal acceptance for service payments. An agent’s mandate cannot supply compatibility that the selected payment route lacks.
Are Stakestone payment mandates also permission to change an account’s yield allocation?
A payment mandate authorizes the payment within its terms, without automatically authorizing portfolio changes. The 2.0 account design separately describes automated asset management under preset conditions. Reallocation requires relevant account authority; changes to STONE’s underlying strategies follow OPAP governance rules rather than an agent’s payment mandate.