Extending Guardrail Guarantees to External Payment Rails

Overview

Most of the internet economy is already built on conventional payment rails like credit card and ACH. Existing payment infrastructure can only confirm that a transaction happened; it cannot verify that the transaction matched what the user actually authorized.

For agents to operate in the existing internet economy, we need mechanisms to constrain what an agent can spend, and to verify after the fact that the agent did what it was supposed to do. delta's guardrail model can be used to provide guarantees to agentic commerce even when the payment occurs offchain, by sandwiching the conventional payment in a delta transaction and settlement.

The user signs a constrained spend authorization before any agent action takes place. The domain or solver fronts the merchant payment on existing rails (card, bank transfer, stablecoin), then claims reimbursement from the user's vault only after generating a proof that the agent's purchase satisfied the signed constraints.

delta's agentic payments model provides hard settlement guarantees: a user's funds will only move if the agent's actions provably satisfy the conditions the user signed upfront.

This means:

• No pre-funded agent wallets. The user's funds stay in their vault until settlement is proven.
• No merchant-side changes. The domain pays merchants on whatever rails they already accept.
• No trust required. The user's authorization cannot be exploited for anything outside the guardrails they signed.

Payment flow

1. User signs a constrained authorization

Before any agent action, the user reviews and signs a delta transaction that encodes their intent as a set of guardrails. This may be generated from a natural-language instruction by the domain application.

The signed message includes:

• A debitAllowance authorizing the domain vault to debit the user's vault up to a defined maximum
• Guardrails defining the constraints the agent must satisfy (e.g. item category, maximum price, merchant, delivery window)
• The guardrail hash included in the auxiliary field, binding the authorization to the specific policy

// Example: user-signed spend authorization with guardrails
SignedMessage {
    message: Message::DebitAllowance(DebitAllowance {
        debited_vault: user_vault_id,
        credited_vault: domain_vault_id,
        max_amount: 15000,           // $150.00 in base units
        token_id: usd_token_id,
    }),
    auxiliary: Some(guardrail_hash), // binds this authorization to the signed policy
    signature: user_signature,
}

The guardrails are defined separately and submitted alongside the signed authorization. See Implementing guardrails for a full reference.

// Example guardrails struct
AgentPurchaseGuardrails {
    max_price_usd: 15000,
    allowed_categories: vec!["office-supplies"],
    require_delivery_by: Some("2025-09-30"),
}

2. Agent executes the purchase

The agent completes its assigned task using whatever payment method the merchant accepts (card, bank transfer, or stablecoin on another chain). This step is entirely off-chain and handled by the domain application. The domain or solver fronts the cost of the purchase and takes on settlement risk in exchange for a fee or spread captured at the reimbursement step.

3. Domain packages a verifiable receipt

After the purchase completes, the domain fetches a receipt from the merchant and packages it into a verifiable receipt object. Provenance is established using zkTLS, so the receipt cannot be fabricated or altered.

// Example verifiable receipt object
VerifiableReceipt {
    merchant: "example-supplier.com",
    item: "A4 copy paper, 5 reams",
    category: "office-supplies",
    amount_usd: 12750,               // $127.50
    delivered_by: "2025-09-15",
    tls_proof: zktls_proof_bytes,    // provenance proof
}

4. Proof is generated and settlement finalizes

A guardrail on the delta settlement layer verifies:

1. The user's signature on the spend authorization is valid
2. The receipt satisfies each constraint in the signed guardrails (amount ≤ max, category matches, delivery date within window, etc.)

If the proof passes, the debit from the user's vault to the domain vault is finalized. If any constraint is violated, the proof fails and the user's funds are not moved.

// Example guardrail verify logic (simplified)
fn verify(
    authorization: &SignedDebitAllowance,
    receipt: &VerifiableReceipt,
    guardrails: &AgentPurchaseGuardrails,
) -> Result<(), GuardrailError> {
    verify_signature(&authorization)?;
    require!(receipt.amount_usd <= guardrails.max_price_usd, GuardrailError::ExceedsMaxPrice);
    require!(
        guardrails.allowed_categories.contains(&receipt.category),
        GuardrailError::CategoryNotAllowed
    );
    if let Some(deadline) = guardrails.require_delivery_by {
        require!(receipt.delivered_by <= deadline, GuardrailError::DeliveryDeadlineMissed);
    }
    Ok(())
}

The settlement flow follows the standard delta SDL lifecycle: POST /sdls/submit → POST /sdls/{hash}/prove → POST /sdls/{hash}/submit_proof.

What this enables

Agentic checkout without merchant changes. The domain pays merchants on rails they already accept. Merchants see a normal transaction. delta's role is entirely in the settlement and proof layer.

Hard spend guarantees for users. Because the debit cannot finalize without a valid proof, users can authorize an agent with confidence that it cannot exceed its mandate, even if the domain application is compromised or acts in bad faith.

Monetizable settlement risk. The domain fronts the purchase cost and earns a fee or spread at reimbursement time. The verifiable guarantee they can offer to users (funds will only move if constraints are satisfied) positions domains as the trust infrastructure for agentic commerce in high-stakes payment contexts.