InterSnap: Cross-Chain Auditability

• InterSnap is an auditable ledger snapshot archival system that creates cross-chain transaction receipts to ensure non-repudiation in permissioned blockchains.
• The methodology employs need-based snapshot scheduling, selection of the peer with the maximum ledger height, and encryption with decentralized storage for secure archival.
• Empirical evaluations on Hyperledger Fabric demonstrate efficient snapshot generation and recovery with minimal overhead, validating its practical scalability.

InterSnap is an auditable ledger snapshot archival methodology for enabling auditability of cross-blockchain transactions and enforcing non-repudiation in permissioned blockchain environments (Sengupta et al., 20 Nov 2025). It introduces cross-chain transaction receipts so that snapshots of ledger data, together with those receipts, can serve as non-repudiable proof of bilateral agreements among different networks. The method is motivated by the observation that tamper-resistance inside a single blockchain does not by itself guarantee accountability across distinct blockchain networks, especially when failures, historical data loss, or malicious repudiation arise.

1. Problem setting and motivation

InterSnap addresses cross-blockchain non-repudiation in settings where separate blockchain networks, particularly permissioned blockchains, cannot directly inspect one another’s ledger history or consensus state (Sengupta et al., 20 Nov 2025). In this setting, a transaction that was honestly committed inside one network may later be disputed by another network, or may become unverifiable after a crash or partial ledger loss. The paper’s central claim is that intra-chain immutability does not imply inter-chain accountability.

The threat model includes both failures and malicious behavior at the level of whole networks. The paper identifies three salient cases. One network may commit a malicious breach of contract by refusing to acknowledge a prior cross-chain transaction. A network may also lose historical ledger data after catastrophic failure and become unable to confirm past obligations even without malicious intent. More seriously, a foreign network may exploit that failure by fabricating liabilities or endorsing fraudulent claims against the weakened network. The motivating examples include financial gain, double spending, wrongful payment demands, and reputational harm.

The paper argues that existing interoperability and snapshot systems leave four gaps: no inter-blockchain history preserving proof of acknowledgment, no snapshot transfer mechanism for external auditing, limited snapshot records that preserve current state rather than transaction evidence, and recency problems caused by ad hoc snapshot generation. This suggests that InterSnap is not merely a recovery mechanism; it is an evidentiary framework designed for dispute resolution as well as fault tolerance.

2. System model and evidentiary objects

InterSnap is formulated for interoperating permissioned blockchain networks, typically a source network $\mathcal{N}_1$ and a destination network $\mathcal{N}_2$ (Sengupta et al., 20 Nov 2025). The architecture includes peers, interoperability smart contracts or chaincode, drivers and relays supplied by the interoperability framework, identity interoperability agents (IIN agents), private IPFS nodes, and a trusted third-party auditor. The implementation target is Hyperledger Fabric interoperability through Hyperledger Cacti, although the paper later discusses conceptual portability to Cosmos IBC, Chainlink CCIP, and Polkadot XCMP.

The basic source-side endorsement object for a cross-chain transaction $T_{cc}$ is defined as

$$\psi_{\mathcal{N}_1}(T_{cc}) = \bigcup_{i=1}^{k}\mathrm{Endorsements}_{p_i}(T_{cc}),$$

and the source transaction is treated as valid when

$$|\psi_{\mathcal{N}_1}(T_{cc})| \ge \frac{2|\mathcal{N}_1|}{3}.$$

The destination network verifies the source endorsements and, if it accepts the transaction, produces destination-side endorsements

$$\psi_{\mathcal{N}_2}(T_{cc}) = \bigcup_{j=1}^{l}\mathrm{Endorsements}_{p_j}\!\left(T_{cc}\|\psi_{\mathcal{N}_1}(T_{cc})\right).$$

The paper’s core evidentiary unit is the cross-chain transaction set

$\mathcal{T}_{\text{Set}} = \{T_{cc}, T_{rt}\},$

where $T_{rt}$ is a response transaction functioning as a receipt. The receipt is generated by the destination network after accepting the transaction, and it carries signed or endorsed evidence that the destination acknowledged the source-side action. A transaction set is considered complete only if the receipt arrives within a stipulated time limit; otherwise it is marked incomplete and excluded from future references. This completion rule is central to the paper’s non-repudiation argument, because it prevents ambiguous one-sided claims from becoming durable archival evidence.

3. Snapshot architecture and operational workflow

InterSnap organizes its mechanism around six named pillars (Sengupta et al., 20 Nov 2025).

Pillar	Role
Recording Non-Repudiable Transaction Receipts	Preserves signed acknowledgment of cross-chain actions
Need-based Snapshot Scheduling	Triggers archival when ledger growth exceeds a threshold
Selection of Snapshot Generating Peer	Chooses the peer with maximum ledger height
Archive Encryption	Protects snapshot confidentiality before external storage
Saving Encrypted Archives in Decentralized Storage	Stores archives in private IPFS
Data Interoperability	Transfers archive references and keys across networks

Operationally, a peer in $\mathcal{N}_1$ initiates $T_{cc}$, endorsements are collected, and the payload $\mathcal{N}_2$0 is propagated cross-chain. Once $\mathcal{N}_2$1 verifies and commits the transaction, it generates the receipt $\mathcal{N}_2$2. The paper then states that the next snapshot can include both objects, for example

$\mathcal{N}_2$3

Across time, the archive grows as

$\mathcal{N}_2$4

Snapshot creation is not periodic by default. Instead, InterSnap uses a need-based threshold

$\mathcal{N}_2$5

where $\mathcal{N}_2$6 is the average number of blocks added per hour and $\mathcal{N}_2$7 is a tunable time window in hours. Archival is triggered when

$\mathcal{N}_2$8

This algorithm is invoked every $\mathcal{N}_2$9 hours, and after archival the stored snapshot height is updated to the current ledger height.

To avoid snapshotting from lagging peers, the generating peer is selected by maximum ledger height. The paper states this as

$T_{cc}$0

If multiple peers have the same maximum height, one is chosen randomly. Service Discovery Protocol rather than static configuration is used for this selection.

4. Archival, interoperability, and auditor-based recovery

Once generated, the snapshot archive is compressed and encrypted before decentralized storage (Sengupta et al., 20 Nov 2025). The paper specifies tar for compression and GPG with symmetric AES-128 encryption, a random passphrase, KDF with salt, and SHA-2/512 in key derivation. Each snapshot uses a unique symmetric key, and the key is also backed up in participants’ wallets.

The encrypted archive $T_{cc}$1 is stored in private IPFS, which returns a content identifier: $T_{cc}$2 This binds the integrity of the archive to content addressing. The paper’s sharing model then transfers the $T_{cc}$3, the decryption key, and metadata across networks through the interoperability framework; to preserve confidentiality, the $T_{cc}$4 and decryption key are encrypted using the destination network’s public key before transfer.

The auditor is modeled as an independent trusted third party composed of reputed organizations. Both participating networks regularly send snapshots to the auditor. In a dispute, the auditor retrieves the archive from IPFS using the shared $T_{cc}$5, swarm key, and decryption key, checks whether the disputed transaction and receipt are present, and confirms or refutes the claim accordingly. The same archival path also supports fault recovery: after ledger loss, a network can bootstrap or restore from the archived snapshots. A plausible implication is that InterSnap recasts snapshots as cross-network forensic records rather than merely local checkpoint files.

5. Formal properties and correctness claims

The paper attributes InterSnap’s safety to the atomicity rule linking $T_{cc}$6 and $T_{cc}$7 and to majority endorsement on both sides (Sengupta et al., 20 Nov 2025). Authenticity derives from digital signatures and endorsements. Integrity derives from IPFS content addressing through the $T_{cc}$8 relation above. Confidentiality derives from AES-128 archive encryption, the private IPFS swarm key, and public-key encryption of transfer metadata. Liveness is argued from dynamic peer selection, operational relays and drivers, and the persistence of archives in IPFS.

The non-repudiation argument is given by cases. If a valid receipt exists, is endorsed by a majority of $T_{cc}$9, and is present in the snapshot archive, then $$\psi_{\mathcal{N}_1}(T_{cc}) = \bigcup_{i=1}^{k}\mathrm{Endorsements}_{p_i}(T_{cc}),$$0 cannot credibly deny acknowledgment without contradicting its own prior signatures. If no receipt exists, then the transaction set is incomplete and $$\psi_{\mathcal{N}_1}(T_{cc}) = \bigcup_{i=1}^{k}\mathrm{Endorsements}_{p_i}(T_{cc}),$$1 cannot claim acknowledgment. Within the paper’s model, repudiation is therefore either contradicted by archived evidence or structurally excluded by the completion rule.

The fault assumptions are explicitly bounded. Local blockchain trust is assumed when more than two-thirds of peers are non-faulty, and the Byzantine bound is stated as the number of Byzantine faulty nodes at an instance not exceeding $$\psi_{\mathcal{N}_1}(T_{cc}) = \bigcup_{i=1}^{k}\mathrm{Endorsements}_{p_i}(T_{cc}),$$2. At the same time, the paper does not provide an exact message schema for receipts, timestamps, sequence numbers, Merkle proof structure, or a complete wire-level verification protocol. The omission is explicit and marks a boundary between the methodological contribution and a fully standardized interoperability specification.

6. Prototype implementation, empirical evaluation, and limitations

The prototype is implemented on Hyperledger Fabric 2.4 with Hyperledger Cacti, Fabric interoperability chaincode, Fabric relays, Fabric drivers, gRPC relay communication, Service Discovery Protocol, IIN agents, private IPFS, and go kubo version 0.17.0 (Sengupta et al., 20 Nov 2025). Two consortium Fabric networks, A and B, were deployed. The experimental environment used four on-premise machines with Intel Core i5-4570 CPU, 8 GB RAM, and Ubuntu 18.04.6 LTS 64-bit, plus three AWS EC2 instances and one virtual machine in a private cloud. Hyperledger Fabric networks used block size 512 KB.

The paper reports the following quantitative behavior.

Aspect	Reported result
Archive encryption time	below 0.6 s up to 12,000 transactions
Encryption + IPFS save	under 1 s up to 12,000 transactions
Snapshot throughput	roughly 103–115 snapshots per minute
InterSnap generation time	roughly 0.5–0.6 s
Fabric “as-is” snapshot time	around 0.42–0.45 s
Reported added overhead	approximately 0.2 s
Recovery from local store	about 5.0–5.12 s
Recovery from IPFS	about 5.76–6.3 s
Cross-network archive transfer	roughly 19.3–21.2 s
One-hour integrated test	around 900 transactions, 99.33% success rate

The payload-size experiment further reports approximately 0.913 s at 0.1 GB, 1.091 s at 0.5 GB, 1.558 s at 1 GB, 1.89 s at 2 GB, 2.20 s at 4 GB, 3.69 s at 6 GB, and 4.12 s at 8 GB. Resource usage remained mostly within 30%–65% CPU, with occasional spikes to 95%, and 30%–70% memory. The paper interprets these results as evidence that InterSnap preserves cross-chain receipts, can recover from malicious attacks or failures, scales with load, and securely transfers archives with modest overhead.

The stated limitations are equally important. The auditor is assumed honest, and collusion between an auditor and a participating network is acknowledged as a remaining risk. The current design is centered on permissioned blockchains, especially Hyperledger Fabric. Large ledger volumes may require future incremental snapshotting or selective purging. The method does not provide a fully standardized receipt format or a complete formal message specification. Its liveness also still depends on blockchain liveness, relay and driver operation, IPFS availability, and key management. Within those assumptions, the paper presents InterSnap as a framework for turning cross-chain receipts and snapshots into durable, auditable evidence for private-to-private blockchain interoperability.