mech.app
Financial

Keeta's 11M TPS Financial Pipeline: What Spanner's Distributed Transactions Teach Agent Tool Builders

Reverse-engineer Keeta's 11M TPS blockchain architecture on Spanner to extract lessons about distributed state, transaction boundaries, and consistency.

Source: cloud.google.com
Keeta's 11M TPS Financial Pipeline: What Spanner's Distributed Transactions Teach Agent Tool Builders

Keeta Network recently stress-tested its layer-1 blockchain to 11 million transactions per second on Google Cloud Spanner. The company, backed by former Google CEO Eric Schmidt, built a cross-chain payment network that unifies transactions across blockchains and traditional payment systems. The architecture runs on Spanner as the source of truth for account balances, transaction history, and compliance metadata.

The number is impressive, but the architecture underneath matters more for anyone building multi-agent financial tools. Keeta’s design exposes how distributed transactions, external consistency, and horizontal scaling work when you cannot afford coordination overhead or stale reads. If you’re orchestrating agents that call payment APIs, reconcile balances across regional boundaries, or coordinate multi-step financial workflows, Keeta’s plumbing offers a production blueprint.

This article focuses on distributed transaction architecture, not blockchain technology itself. It’s about how Spanner’s TrueTime API and transaction semantics enable agents to operate on shared mutable state without breaking consistency or requiring expensive locks.

Keeta’s Transaction Architecture

Keeta’s blockchain runs on Spanner as the operational database. The network processes cross-chain transfers, fiat on-ramps, and tokenized asset movements through a unified transaction model. The architecture includes on-chain compliance protocols (KYC and AML) that run as part of each transaction. If compliance fails, the entire transaction rolls back.

Core components:

  • Account state: Spanner tables store balances, KYC status, and AML flags. Each account row includes a version counter for optimistic concurrency control.
  • Transaction log: Immutable append-only table records every operation with a TrueTime commit timestamp.
  • Compliance layer: On-chain KYC and AML checks run as part of the transaction. If compliance fails, the entire transaction rolls back.
  • Cross-chain bridge: Keeta’s network connects to multiple blockchains and payment systems, eliminating costly intermediaries.

The architecture separates read and write paths. Agents query account state using stale reads for balance checks. Write operations use strongly consistent transactions with automatic retries.

Why Spanner for Financial Agents

Spanner provides external consistency: transactions commit in a global order that matches real-world causality. If transaction A completes before transaction B starts anywhere in the world, Spanner guarantees A’s effects are visible to B. This property is critical when agents retry operations, read balances, or coordinate multi-tool workflows.

Key properties for agent orchestration:

  • TrueTime API: GPS and atomic clocks provide a bounded uncertainty interval (typically under 7ms). Spanner uses this to assign commit timestamps without coordination.
  • Serializable isolation: Agents see a consistent snapshot of data. No dirty reads, no phantom rows.
  • Automatic retries: Spanner handles transient failures internally. Your agent code sees clean success or failure.
  • Horizontal scaling: Add nodes to increase throughput without changing transaction semantics.

Keeta’s 11M TPS benchmark demonstrates that Spanner can handle agent-driven financial operations at scale. The architecture does not rely on eventual consistency or optimistic locking. Every transaction either commits atomically or rolls back cleanly.

Transaction Boundaries for Multi-Agent Workflows

When multiple agents coordinate financial operations, transaction boundaries determine correctness. Financial systems typically implement three patterns:

PatternUse CaseConsistency GuaranteeTypical Latency
Single-row transactionAgent updates one account balanceSerializableLow single-digit ms
Multi-row transactionAgent transfers funds between accountsSerializable, atomic commitSingle-digit to low double-digit ms (cross-region)
Read-modify-write with retryAgent checks balance, then debitsExternal consistency with idempotencyVariable (includes retry)

Conceptual pseudocode: Single-row update with version check

-- Illustrative Spanner SQL pattern
-- Actual implementation uses Spanner's parameterized query API
UPDATE accounts
SET balance = balance - @amount,
    version = version + 1
WHERE account_id = @account_id
  AND balance >= @amount
  AND kyc_status = 'VERIFIED'
  AND version = @expected_version;

If the version check fails, Spanner aborts the transaction. The agent retries with a fresh read. This pattern prevents lost updates when multiple agents operate on the same account.

Conceptual pseudocode: Multi-row atomic transfer

-- Illustrative Spanner SQL pattern showing atomic multi-row update
BEGIN TRANSACTION;

-- Debit source account
UPDATE accounts
SET balance = balance - @amount
WHERE account_id = @source_id
  AND balance >= @amount;

-- Credit destination account
UPDATE accounts
SET balance = balance + @amount
WHERE account_id = @dest_id;

-- Log transaction with TrueTime timestamp
INSERT INTO transaction_log (tx_id, source_id, dest_id, amount, timestamp)
VALUES (@tx_id, @source_id, @dest_id, @amount, PENDING_COMMIT_TIMESTAMP());

COMMIT TRANSACTION;

Spanner commits both updates atomically. If the debit fails, the credit never happens. The transaction log entry gets a TrueTime timestamp that reflects the global commit order.

Idempotency and Retry Semantics

Financial agents must handle retries without double-charging customers or creating duplicate transactions. Keeta’s architecture likely implements idempotency via unique constraints on transaction IDs, which is the industry standard pattern for financial systems. The Google Cloud blog post does not detail Keeta’s specific idempotency implementation, but the pattern is well-established in production financial infrastructure.

Idempotency key design pattern (industry best practice):

  • Agent generates a UUID before attempting the transaction.
  • Database table includes a unique index on (account_id, tx_id).
  • If the agent retries after a network timeout, the duplicate insert fails with a constraint violation.
  • Agent queries the transaction log to determine if the original operation succeeded.

Deduplication window considerations:

Financial systems typically keep transaction IDs in active tables for a bounded time period (days to weeks) before archiving. This window balances storage cost against the risk of duplicate processing. Agents that retry after the window expires must use a new transaction ID.

Illustrative retry logic pattern:

# Conceptual pseudocode showing retry semantics
# Actual google-cloud-spanner Python API uses:
# client.database().run_in_transaction(callable, *args, **kwargs)

def transfer_funds(source_id, dest_id, amount, tx_id):
    try:
        # Spanner client handles retries for aborted transactions
        database.run_in_transaction(
            execute_transfer, source_id, dest_id, amount, tx_id
        )
        return {"status": "success", "tx_id": tx_id}
    
    except UniqueConstraintError:
        # Transaction ID already used, check if it succeeded
        result = query_transaction_log(tx_id)
        if result.status == "committed":
            return {"status": "success", "tx_id": tx_id}
        else:
            raise Exception("Transaction ID collision")
    
    except TransactionAbortedError:
        # Spanner aborted due to contention
        # Client already retried, so this is a terminal failure
        raise

The agent retries on TransactionAbortedError but not on unique constraint violations. This pattern ensures exactly-once semantics even when the network drops responses.

TrueTime and External Consistency

Spanner’s TrueTime API provides a bounded uncertainty interval: [earliest, latest]. When a transaction commits, Spanner waits until latest has passed before returning. This wait ensures that the commit timestamp is globally unique and reflects causality.

Why this matters for agents:

  • Causal ordering: If Agent A completes a payment and then notifies Agent B, Agent B’s read will always see Agent A’s update.
  • No clock skew: Agents running in different regions see the same transaction order.
  • Audit trails: The transaction log’s timestamps match real-world event order, enabling compliance reporting.

Keeta’s 11M TPS benchmark demonstrates that TrueTime’s wait period does not bottleneck throughput. The system scales horizontally by adding Spanner nodes, not by relaxing consistency.

Observability and Failure Modes

Production financial systems instrument every transaction with structured logs and metrics. Recommended practices for Spanner-based agent systems include tracking:

  • Transaction latency: P50, P99, and P99.9 latencies for each operation type.
  • Abort rate: Percentage of transactions aborted due to contention or constraint violations.
  • Retry count: Number of retries per transaction ID.
  • Compliance failures: KYC or AML checks that caused rollbacks.

Common failure modes in distributed financial systems:

FailureCauseAgent Response
Insufficient balanceAccount balance < debit amountReturn error to user, do not retry
Version mismatchConcurrent update by another agentRetry with fresh read
Compliance failureKYC status expiredTrigger re-verification workflow
Database unavailabilityRegional outageFail over to secondary region, retry

Agents should isolate transient failures (version mismatches, aborts) from permanent failures (compliance violations, insufficient funds). Retry only when the failure is transient.

Advanced Patterns: Multi-Region Deployment

Financial systems that require global availability typically deploy Spanner in a multi-region configuration with multiple replicas per region. This deployment pattern minimizes latency for global users while maintaining strong consistency.

Regional placement strategy:

  • Distribute replicas across geographically diverse regions to survive regional outages.
  • Place replicas near user populations to reduce read latency.
  • Configure leader placement based on write traffic patterns.

Spanner automatically replicates data across regions and elects a leader for each transaction. Agents connect to the nearest Spanner endpoint to reduce network latency.

Capacity planning considerations:

Production systems provision Spanner nodes based on sustained throughput, not peak load. Autoscaling handles traffic spikes. Each node’s throughput capacity depends on workload characteristics (read/write ratio, transaction complexity, row size).

Security Boundaries for Agent Access

Financial agent systems should enforce security at multiple layers. Recommended architecture:

Security layers:

  1. Network isolation: Run the database in a private network. Agents connect via authenticated endpoints.
  2. Identity and access management: Use service account credentials with principle of least privilege. Rotate credentials regularly. Spanner integrates with Cloud IAM for role-based access control.
  3. Audit logging: Generate audit log entries for every transaction with the agent’s identity and operation details.

Recommended access control patterns:

  • Implement application-level authorization checks before database operations.
  • Use Cloud IAM roles to restrict database access by service account.
  • Validate compliance status (KYC, AML) before committing financial transactions.

Agents should authenticate using short-lived credentials. The compliance layer validates regulatory requirements before committing any transaction. If an agent attempts an unauthorized operation, the system rejects the transaction and logs the attempt.

Lessons for Agent Tool Builders

Keeta’s architecture demonstrates how to build financial tools that agents can call without breaking consistency or requiring manual reconciliation.

Design principles for multi-agent financial systems:

  • Idempotency first: Every operation must accept a client-generated ID. Use unique constraints to prevent duplicates.
  • Explicit transaction boundaries: Define what commits atomically. Avoid long-running transactions that hold locks.
  • Retry on abort, not on constraint violation: Database aborts indicate transient contention. Constraint violations indicate permanent failures.
  • Use stale reads for balance checks: Agents can tolerate bounded staleness when checking balances. Reserve strong consistency for writes.
  • Instrument everything: Log transaction IDs, retry counts, and abort reasons. You will need this data when debugging agent behavior.

If your agents coordinate financial operations across multiple tools, Spanner’s transaction model provides a solid foundation. The TrueTime API eliminates the need for distributed locks or two-phase commit protocols. Agents can retry freely without risking duplicate charges or inconsistent state.

Technical Verdict

Use Spanner-style distributed transaction architecture when:

  • You need serializable isolation across geographically distributed agents.
  • Your agents perform multi-step financial workflows that must commit atomically.
  • You require external consistency for audit trails and compliance reporting.
  • You can tolerate single-digit millisecond commit latency in exchange for strong consistency.

Avoid this approach when:

  • Your workload is read-heavy and can tolerate eventual consistency.
  • You need sub-millisecond latency for high-frequency trading.
  • Your transaction rate is very low (distributed databases have minimum cost thresholds).
  • You prefer optimistic concurrency control with application-level conflict resolution.

Keeta’s 11M TPS benchmark proves that Spanner can handle agent-driven financial operations at scale. The architecture trades latency for correctness, which is the right trade-off for most financial use cases. If your agents need to coordinate payments, reconcile balances, or enforce compliance rules, Spanner’s transaction model eliminates entire classes of bugs.