Execution Intents: The Law of Settlement

Execution Intents deliver absolute cryptographic certainty.

RPC transactions are probabilistic artifacts. They might land. They might revert. They might vanish into the mempool. Backpac Execution Intents transform these probabilities into deterministic outcomes, providing the foundational infrastructure for compliance with the GENIUS Act of 2025.

IMPORTANT

The GENIUS Act Compliance: Under the Guiding and Establishing National Innovation for U.S. Stablecoins (GENIUS) Act, issuers must maintain strict standards for audits (§ 1.1) and transaction visibility (§ 1.3). Execution Intents are the primary mechanism for meeting these institutional mandates.

The Post-Settlement Gap: Blockchain settlement typically takes seconds, but reconciling these transactions into a General Ledger (GL) often takes days or weeks. This manual reconciliation bottleneck is the single largest barrier to institutional stablecoin scaling.

Execution Intents bridge this gap by binding business context to on-chain finality. Within the Assured RPC Network, once an Intent is committed, it is governed by the law of finality.

The Risk-Scored Settlement Progression

Backpac orchestrates the transition from raw intent to immutable state across five key atomic, risk-scored stages:

1. Submission / SUBMITTED: The transaction is accepted, validated, and persisted. It is now under Backpac's jurisdiction.
2. Propagation / PENDING: The intent has been broadcast to the high-performance layer and is awaiting pickup by validators/miners.
3. Inclusion / MINED: The transaction is witnessed within an on-chain block (1+ confirmations). At this stage, it is part of the chain but potentially reversible (Risk is Moderate).
4. Settlement / FINALIZED: Upon reaching the required institutional confirmation depth (e.g., 12 blocks or codified finality), the state is considered irreversible for standard business logic (Risk is Zero).
5. Safety / SAFE: Deep settlement (e.g., 32+ blocks or finalized checkpoint) for maximum cryptographic assurance.

Configuration

Execution Intents are a premium feature that requires a high-performance Reliability Pool. To enable them:

1. Create a Reliability Pool with Type: DIN|MANAGED (e.g., leveraging the Decentralized Infrastructure Network (DIN)).
2. Enable Execution Intents in the Reliability Pool settings.
3. Route your transaction requests to the Reliability Pool.

NOTE

Intents are not created for Standard (Round Robin / Latency) legacy groups. They require the consensus guarantees of the ASSURED layer.

Execution Parameters

Control the settlement criteria using institutional headers:

Header	Intent	Default
x-backpac-confirmations	The required block depth for verified settlement.	10 (Solana), 24 (EVM)
x-backpac-metadata	Forensic data to be returned in the settlement audit.	{}
x-backpac-intent-id	Client-side identifier for tracing.	System Generated
x-backpac-poi-id	Proof of Intent identifier to bind this execution to an overarching agent workflow.	null
x-backpac-rebroadcast-max	Maximum number of active re-submissions if dropped from mempool.	0 (Disabled)

Settlement Assurance ("Must Land")

For critical stablecoin operations, passive monitoring is insufficient. If a transaction is dropped from the mempool (e.g., due to node restarts or congestion), Backpac's Active Settlement Engine intervenes.

Re-Broadcast Logic

If an intent status is NOT_FOUND (missing from chain history) and the x-backpac-rebroadcast-max threshold has not been met:

1. Detection: The Intent Monitor confirms the transaction is effectively lost (not pending).
2. Action: The system decrypts the original payload (eth_sendRawTransaction or Solana sendTransaction).
3. Re-Submission: The payload is actively re-broadcast to the network.
4. Notification: A intent.rebroadcast event is emitted.

Verified Settlement (Webhooks)

Backpac dispatches signed, high-fidelity notifications as intents transition through their lifecycle. This allows your systems to operate with the certainty of a finalized ledger.

Lifecycle Events

Event	Logic	Action
intent.submitted	Intent accepted.	Acknowledge receipt.
intent.pending	Broadcast to network.	Update UI to "Processing".
intent.mined	Included in block (1 conf).	Tentative success (risk of re-org).
intent.finalized	Reached target depth.	Release value / Settle.
intent.safe	Deep finality.	Archive / Audit.
intent.aborted	Revert or Expiry.	Initiate remediation.
intent.rebroadcast	Re-submitted to network.	Log operational intervention.

REST API Endpoints

Backpac provides high-availability REST endpoints to query the state of any Execution Intent.

Intent Status

GET /v1/intents/:id

Retrieve the current lifecycle state, confirmation count, and forensics.

Schema (ExecutionIntent)

interface ExecutionIntent {
  intent_id: string;           // Unique identifier for this execution
  status: 'PENDING' | 'MINED' | 'FINALIZED' | 'SAFE' | 'FAILED'; // Settlement status
  lifecycle_state: string;     // Active sub-state inside the state machine
  chain: string;               // Target chain (e.g., 'solana', 'base')
  network: string;             // Target network (e.g., 'mainnet', 'devnet')
  current_confirmations: number;
  required_confirmations: number;
  last_checked_at: string;     // ISO 8601 timestamp
}

Example JSON Response:

{
  "intent_id": "ei_merch_7721",
  "status": "PENDING",
  "lifecycle_state": "PENDING",
  "chain": "solana",
  "network": "devnet",
  "current_confirmations": 2,
  "required_confirmations": 3,
  "last_checked_at": "2024-02-17T20:15:00Z"
}

Bridging the General Ledger (S2L)

Execution Intents provide the necessary connectivity for Settlement-to-Ledger (S2L) automation.

By leveraging metadata headers and verified webhooks, finance teams can automate reconciliation for stablecoins without manual block explorer searches, directly addressing the Transaction Immutability & Visibility requirements of the GENIUS Act § 1.3.

Implementation Strategy

1. Binding Context: Pass your internal identifiers (orderId, invoiceId) in the x-backpac-metadata header when submitting an intent.
2. Automated Reconciliation: Configure a webhook listener for intent.finalized.
3. GL Ingestion: Use the webhook payload—which includes both the immutable on-chain txHash and your business metadata—to trigger an automatic entry into your General Ledger (e.g., NetSuite, SAP, or Sage).
4. Agent Workflows: For AI-driven interactions, tie the Execution Intent to a Proof of Intent to enable cryptographic settlement proofs (PoT).

S2L Implementation (TypeScript/Express)

import express from 'express';
const app = express();

app.post('/webhooks/backpac', express.json(), async (req, res) => {
  const event = req.body;

  if (event.type === 'intent.finalized') {
    const { txHash, metadata } = event.data;
    
    // Inject automatically into General Ledger
    await updateGeneralLedger({
      invoiceId: metadata.invoiceId,
      status: 'SETTLED',
      onChainTx: txHash,
    });
    
    console.log(`✅ Invoice ${metadata.invoiceId} successfully settled.`);
  }
  res.sendStatus(200);
});

S2L Implementation (Python/FastAPI)

from fastapi import FastAPI, Request
app = FastAPI()

@app.post("/webhooks/backpac")
async def backpac_webhook(request: Request):
    event = await request.json()
    
    if event["type"] == "intent.finalized":
        tx_hash = event["data"]["txHash"]
        metadata = event["data"]["metadata"]
        
        # Inject automatically into General Ledger
        update_general_ledger(
            invoice_id=metadata["invoiceId"],
            status="SETTLED",
            on_chain_tx=tx_hash
        )
        print(f"✅ Invoice {metadata['invoiceId']} successfully settled.")
        
    return {"status": "ok"}

---

Execution Intents: Because in finance, "maybe" is not an option.