Audience: partner engineering teams, ecosystem collaborators, research institutes, and compliance reviewers
Keywords: DAG, Taproot-only, client-side validation (RGB), parallel anchoring, multi-lane commitments, batch proofs, packager-as-a-service

1. Executive Summary

This document presents a practical approach to significantly increase application-layer throughput (TPS) without modifying base-layer consensus. The design uses Tondi (DAG, Taproot-only) for finality and audit trails, RPB as an off-chain routing/matching accelerator, and RGB for client-side validation. The overall strategy is on-chain commitments + off-chain parallelization:

Parallel anchoring (multi‑anchor lanes): Distribute state across multiple independent anchoring lanes to raise per-epoch commitment capacity and mitigate hotspots.
Batch commitments: Aggregate many application events into Merkle/Verkle roots; commit only the root on-chain, preserving finality and auditability.
Tick anchoring: Seal batches on fixed time slices to smooth tail latency and simplify capacity governance.
Packager-as-a-Service: Near-miner packaging of dependency-closed transaction groups with fee-aware ordering, streamed into block templates.

With stable on-chain anchoring throughput and proper batching/parallelization, effective application TPS can grow by orders of magnitude while finality and auditability remain intact via Tondi’s DAG acceptance and RGB proofs.

2. Background & Problem Statement

For high-concurrency applications (payments, settlement, gaming assets, verifiable logs), per-event on-chain recording is constrained by byte budgets, network propagation, and verification cost. Replacing per-event recording with commitment compression and shifting throughput pressure to off-chain routing and client-side validation is a pragmatic path to scale. The main challenges are:

Preserving auditability and finality;
Balancing end-to-end latency and throughput at steady state;
Providing standardized interfaces and compatibility to reduce integration friction.

3. Design Goals & Principles

No consensus changes: DAG/GHOSTDAG and block production remain unchanged.
Auditable & verifiable: All application events are independently replayable via RGB proofs and on-chain anchors.
Parallel & elastic: Multi-lane anchoring and batch commitments enable near-linear scaling until hitting client/network limits.
Interface-neutral: Support both gRPC and wRPC/WebSocket; browsers/wallets and services/miners choose the best fit.
Governed reliability: Clear SLOs, observability, and risk controls to keep tail risks and costs bounded.

4. Architecture Overview

[Clients / Wallets]
    |  (wRPC / gRPC)
[RGB Verifier & Router (RPB)]  --(batch roots)-->  [Anchor Builder]
    |                                               /
    | (stream tx groups)                           /
[Packager Service]  <====(mempool/fees)====>  [Tondi Node + Miner]
                                  |                   \
                             [DAG headers]            [Finality]

RPB: Aggregates and routes application events, forms batch commitments and routing decisions.
RGB: Client-side proof construction/verification for trustless correctness.
Anchor Builder: Consolidates batch roots per tick into anchor transactions.
Packager: Groups mempool transactions with dependency closure and fee-aware ordering; streams template deltas.
Tondi: Provides finality and an auditable record via DAG acceptance.

5. Key Elements

5.1 Parallel Anchoring (Multi‑anchor Lanes)

Partition global state into M independent lanes, each with its own batch sequence.
Wallets/routers balance load across lanes by pressure, fees, and topology.
Expose lane-selection policy and capacity limits to partners for planning.

5.2 Batch Commitments

Aggregate K events into a batch_root (Merkle/Verkle/multi-root).
Anchor transactions carry the root(s) and minimal metadata (§7.2).
Participants store or retrieve subproofs; verification is client-side.
Combine with privacy enhancements (blinding/ selective disclosure) and audit modes (threshold disclosure) as needed.

5.3 Tick Anchoring

Seal batches every fixed Δt, yielding predictable traffic patterns and bounded tail latency.
Δt can adapt to network health, fee pressure, and queue depth.
Stagger across lanes and use priority queues to protect latency-sensitive flows.

5.4 Packager-as-a-Service

Deploy near miners to: ensure dependency closure, rank by package feerate, group transactions, and stream template deltas over bidirectional streaming.
Publish strategy and audit logs to reduce fairness concerns; support backpressure and windowing.

6. Performance Methodology & Capacity Planning

6.1 Concepts & Formulae

Anchor transaction size: S_anchor (bytes)
Effective on-chain payload: B_eff (bytes/s)
Events per anchor: K
Number of lanes: M
Effective application TPS:
TPS_app ≈ (B_eff / S_anchor) × K
Multi-lane operation improves utilization and smooths bursts; batching raises K.

6.2 Target Metrics & SLOs (examples)

End-to-end latency (submit → DAG acceptance): p95/p99 targets.
Template payload utilization: ≥ specified threshold (e.g., 85%).
Orphan/red rate: ≤ specified threshold (e.g., 0.5%).
Proof size distribution: p50/p95 bounds.
Lane balance: hotspot ratio and rebalancing frequency.

6.3 Measurement & Validation (high-level)

Mempool throughput and rejection reasons;
Verification CPU histograms and batch-verification gains;
P2P propagation (p50/p95/p99);
Template load latency and dependency-closure rate;
DAG acceptance delays;
Client proof build/verify times;
RPB soft-confirmation latency and rollback rate.

7. Interfaces & Compatibility

7.1 Transport

gRPC: service-to-service and miner proximity; bidirectional streaming, mTLS, observability, and policy control.
wRPC/WebSocket: browsers/mobile/wallets; lightweight, event subscriptions, broad language reach.

7.2 Anchor Transaction Metadata (recommended)

lane_id — lane identifier
epoch — tick or sequence number
batch_root — commitment root (support multiple trees)
count — events included in the batch
version, network_id, proof_hint (optional retrieval hint)

7.3 Minimal Chain Adapter (example)

getUTXO(outpoint) → {value, script, spent}
broadcastTx(rawTx) → txid
subscribeBlocks() → stream{header, acceptedIDs, blueScore}
getHeadersSince(cursor) / getAcceptanceData(txid)

Proto sketch (excerpt):

service ChainAdapter {
  rpc BroadcastTx(RawTx) returns (TxID);
  rpc GetUTXO(Outpoint) returns (UTXO);
  rpc SubscribeBlocks(SubscribeReq) returns (stream BlockEvent);
  rpc GetHeadersSince(Cursor) returns (Headers);
  rpc GetAcceptanceData(TxID) returns (Acceptance);
}
service MinerAdapter {
  rpc StreamTemplate(stream TemplateReq) returns (stream TemplateDelta);
  rpc SubmitBlock(Block) returns (SubmitResult);
}

8. Security, Privacy & Compliance

Client-side verification: RGB proofs validate independently on endpoints; correctness does not rely on node assertions.
Auditability: Public commitment formats enable third-party audits and forensics.
Privacy: Batching works with zero-knowledge and selective disclosure; tune batch policies to balance privacy and latency.
Compliance: Provide disclosure interfaces and threshold alerts for high-frequency/cross-border use cases and regulatory sandboxes.

9. Risks & Mitigations

Risk	Description	Impact	Mitigation
Proof bloat	Oversized per-event proofs from aggressive batching	CPU/bandwidth pressure on clients	Cap `K`, layered proofs, incremental retrieval
Anchor congestion	Tick-aligned bursts	Elevated tail latency	Adaptive `Δt`, lane staggering, priority queues
Lane hotspot	Imbalanced load on a lane	Slow confirmations on that lane	Wallet LB, re-sharding, quotas
DoS/junk traffic	Low-fee or malicious traffic	Verification/bandwidth exhaustion	Min fee + package feerate, rate limits, reputation lists
Ordering disputes	Packaging strategy gaming	Perceived unfairness	Public strategy, audit logs, randomized + fee-weighted ordering

10. Ecosystem & Business Value

Cost efficiency: More events per on-chain byte; lower per-event cost.
Developer friendliness: Stable interfaces and transport neutrality; compatible with existing wallets/frontends and service stacks.
Scalability knobs: M (lanes) and K (batch size) tune capacity with near-linear growth.
Trust & compliance: Client-side validation plus open commitment formats preserve privacy choices and support audits.

11. Deliverables & Collaboration (examples)

SDK/adapters: ChainAdapter (gRPC/wRPC) and Anchor Builder.
Reference implementations: Packager prototype, batch-commit tooling, proof build/verify libraries.
Observability dashboards: Template utilization, propagation delay, DAG acceptance, proof-size distribution.
Integration guide: Lane strategy, batching parameters, security settings, and audit workflows.

12. Glossary (selected)

Tondi: DAG-based, Taproot-only execution/anchoring layer providing finality and auditable records.
RPB: Off-chain routing/matching with soft confirmation for sub-second UX; anchors for finality and audit.
RGB: Client-side validation for trustless correctness with local proofs.
Parallel anchoring: Multiple lanes writing commitments concurrently.
Batch commitments: Aggregating many events into an on-chain root.
Packager-as-a-Service: Near-miner grouping/ordering and streaming of transaction packages.

Appendix A. Metrics Cheatsheet

End-to-end latency (submit → DAG acceptance) p50/p95/p99
Template payload utilization, dependency-closure rate
Orphan/red rate
Proof size distribution (p50/p95)
Lane balance and rebalancing count
Anchors per second and events per anchor

Appendix B. Interface Sketch (Proto Excerpt)

service ChainAdapter {
  rpc BroadcastTx(RawTx) returns (TxID);
  rpc GetUTXO(Outpoint) returns (UTXO);
  rpc SubscribeBlocks(SubscribeReq) returns (stream BlockEvent);
  rpc GetHeadersSince(Cursor) returns (Headers);
  rpc GetAcceptanceData(TxID) returns (Acceptance);
}
service MinerAdapter {
  rpc StreamTemplate(stream TemplateReq) returns (stream TemplateDelta);
  rpc SubmitBlock(Block) returns (SubmitResult);
}

Appendix C. Tick Anchoring Timeline (Schematic)

Δt: [Gather RGB events] -> [Build batch Merkle] -> [Assemble anchor tx] -> [Broadcast] -> [DAG acceptance]

Disclaimer: This report describes a technical direction and capabilities. It is not a regulatory opinion or commercial commitment. Actual metrics depend on joint integration and auditing.

Technical Report | Tondi + RPB + RGB Application-Layer TPS Scaling