Tinydancer

What Tinydancer Is and the Problem It Solves

Every Solana user who wants to send or receive transactions ultimately relies on a full node to interact with the network. Running a full Solana validator or archive node requires enterprise-grade hardware, a high-bandwidth connection, and significant technical overhead — well beyond what a typical user or even a small developer team can sustain at home. As a result, the vast majority of users route their activity through trusted third-party RPC providers, or through wallets that bundle RPC access on their behalf.

This creates a fundamental trust assumption. An RPC server can censor transactions, return manipulated state data, or — in extreme scenarios where a corrupt super-majority of validators colludes — facilitate invalid state transitions that full nodes would catch but light users never would. The block censorship applied to Tornado Cash by Infura and Alchemy in 2022 illustrated how real this risk is in practice.

Tinydancer was built to eliminate this trust assumption without requiring users to run a full node. Launched in early 2023 by an independent team, it is the first light client implementation for the Solana blockchain. A Tinydancer node can run on a consumer laptop or mobile phone, connect to the broader Solana network, and independently verify block data availability and transaction inclusion — without trusting any third party.

How Tinydancer Works

Tinydancer's technical design is built on top of Solana's existing block propagation architecture rather than requiring protocol changes from day one.

Shreds and Data Availability Sampling. Solana's Turbine protocol breaks blocks into small units called shreds before broadcasting them across the validator network. Each shred contains a payload of ledger entries along with a Merkle proof path back to the block's Merkle root, and a leader signature covering that root. Tinydancer's light client exploits this structure to perform Data Availability Sampling (DAS): rather than downloading and verifying an entire block — which can reach 40–50 GB per epoch on Solana — the client requests a small number of randomly selected shreds from validators found in the gossip table.

Because shreds are Reed-Solomon erasure-coded, the probability that block data is being withheld falls exponentially with the number of samples drawn. With approximately 20 randomly sampled shreds, the probability of a successful data-withholding attack drops to roughly one in a million. After receiving each shred, the client checks that the Merkle proof in its payload computes correctly to the expected root, and that the root itself is signed by the slot leader. This gives users a probabilistic but rigorous guarantee that block data exists and has not been tampered with.

Consensus Verification. Tinydancer also checks that a given block has reached Solana's super-majority threshold — the point at which two-thirds of staked validators have voted to confirm the fork. The client requests block headers containing validator vote signatures and their corresponding stake amounts. Once confirmed, a user can trust that an invalid state transition would be detectable by at least the honest minority of the network.

Shred Archival and Partition Repair. Sampled shreds that pass verification are stored in a local database for the duration of the epoch. This shred archive serves a secondary function: it feeds a peer-to-peer network of light clients that validators can query to repair partitions. When a validator node is lagging behind the chain tip — due to turbine inefficiency, network issues, or an eclipse attack — it can request missing shreds directly from geographically proximate Tinydancer nodes rather than routing repair requests back through the leader.

Local RPC Mode. The client starts a local RPC server that acts as a relay between the user's application and an external RPC provider. Wallets and dapps can point at this local endpoint. Outgoing transaction submissions route directly to the TPU (Transaction Processing Unit) of any validator, while responses are independently verified by the light client before being returned to the application.

Key Features

• Collusion-proof verification: Even if the full set of trusted RPC providers were compromised, a Tinydancer node would detect data withholding or invalid state transitions using only a small honest minority of validators.
• Low hardware requirements: Designed to run on laptops and mobile devices, requiring no specialized hardware.
• Simple Payment Verification (SPV): Users can submit a transaction and receive a verifiable proof of on-chain execution without relying on an RPC to report status honestly.
• Configurable sampling: Operators set the number of random shred samples per block, tuning the tradeoff between efficiency and security assurance.
• Open-source Rust implementation: The full client is published at github.com/tinydancer-io and installable via cargo install.
• Non-interactive sampling mode: A deterministic randomness function uses the slot number, the diet client's ed25519 public key, and the slot hash as seeds to generate a sample vector — eliminating the need for the client to manually request shreds, as validators send the relevant shreds directly.

Supported Assets and Networks

Tinydancer operates at the Solana protocol layer and is not asset-specific. It is capable of verifying any transaction executed on Solana mainnet, including SOL transfers, SPL token transfers, NFT operations, and DeFi contract interactions. Its verification guarantees apply equally to any program execution on the network.

The project's roadmap also described IBC (Inter-Blockchain Communication) integration as a future goal. A $10,000 public good grant from DoraHacks awarded in February 2024 was designated in part to support development of an IBC bridge between Solana and Cosmos-based chains, using the light client as a trust-minimized foundation for cross-chain messaging.

Security and Audit Status

Tinydancer's security model is grounded in the fraud and data availability proofs framework described by Mustafa et al. (2019) and in Paradigm Research's 2022 work on Data Availability Sampling. The implementation uses Reed-Solomon erasure coding already deployed in Solana's Turbine propagation layer, meaning the cryptographic foundations are production-tested at scale.

The project submitted SIMD-0052 to the Solana Improvement Documents process, proposing the addition of a receipt root and block Merkle structure to Solana's block headers to provide stronger protocol-level guarantees for light clients. This SIMD was co-authored by Anoushk Kharangate.

Backers include the Solana Foundation, Cubik, Staking Facilities, and DoraHacks. Solana co-founder Anatoly Yakovenko publicly called the project "one of the most important advances in Solana's security," noting it was built "with virtually zero core dev help" — entirely by ecosystem contributors. No formal third-party security audit of the client implementation has been publicly disclosed.

Team and Background

Tinydancer was co-founded by Anoushk Kharangate and Harsh Patel, both members of SuperteamDAO with backgrounds in open-source Solana infrastructure.

Kharangate is a full-stack Rust developer and multiple hackathon winner. His open-source contributions span Anchor, Solana Labs, Jito Solana, Switchboard, and Metaplex. Patel is a cryptography and zero-knowledge researcher who was part of the Solana India Fellowship in 2021, with a background in mechatronics engineering.

The project emerged from the Solana hackathon circuit and gained significant visibility at the Grizzlython hackathon in early 2023, where it demoed live on-chain slot verification from a local light client. Advisors include members of the Overclock validator team (Dubbelosix and 7Layer Magik) and Kash Dhanda of SuperteamDAO. The underlying concept for a Solana light client was originally proposed by co-founder Anatoly Yakovenko himself.

Solana Ecosystem Fit

Solana's architectural choices — fast block times, high throughput, and erasure-coded shred propagation — make it substantially harder to build light clients than it is on slower chains. Tinydancer demonstrates that Solana's existing shred infrastructure can be repurposed for data availability sampling without waiting for full protocol upgrades.

Broader adoption of the Tinydancer model would shift how Solana's decentralization is measured: rather than counting validators, the meaningful security metric becomes the number of independently verifying full nodes supported by a mesh of light clients performing DA sampling. This makes Tinydancer relevant not only to end users, but also to wallet providers, bridge protocols seeking trust-minimized Solana verification, and any application requiring on-chain state guarantees beyond what a trusted RPC can provide.