As @sol_idity makes it clear in this tweet thread, the cost of Associated Token Account rent is too damn high. At ◎0.002 per ATA, any large-scale issuance of tokens (such as stablecoins) becomes economically infeasible to deploy. In this sRFC i hope to outline a potential solution to the problem, with some trade-offs that i think are worth making. As a preface, i'm looking to solve stablecoin deployment at the scale of about >5mm wallets (USDC on Solana only has 1.5mm holders), and i am not looking for 100% parity with existing systems. Tiny SPL introduces a clever solution to the fungibility of compressed NFTs by wrapping a compressed NFT tree with a program that allows the splitting and combination of the "balance" associated with any given compressed NFT. However, one restriction is that the information in this tree doesn't yet interoperate with traditional SPL Tokens (e.g., USDC). Additionally, because the data structure used by state compression (a Merkle tree) cannot effectively be used to create a proof-of-exclusion, you cannot directly "send" an asset to a specific account, you just append amounts and force the end-user to combine those amounts. There are a few possible improvements to Tiny SPL that fit into a broader vision for compressed token accounts: Allow state compression leaves to be "decompressed" into SPL Tokens, which provides some interoperability with existing integrations with SPL Tokenkeg (i.e., exchanges, wallets). A PDA of the Tiny SPL program could be the owner of an omnibus account for the SPL Tokens and each leaf acts as a "claim" on those SPL Tokens, and outbound sends from the tree end up requiring an ATA to be the destination account. By swapping the data structure of state compression to an indexed Merkle tree (h/t Noah P., Swen), one can identify the exact leaf owned by a specific user, eliminating the need to do splits and combinations and allows sends to go directly to a unified balance Create a program that manages a user-owned list of trees with relevant balances. Whenever a third-party sends to this user, they need to check that list and are otherwise responsible for adding to the list for indexers to ensure they're indexing all possible compressed token accounts

One key issue for compressed NFTs is that data availability for suitably large drops can be problematic. One poignant example is that a million+ sized drop (often exhibited by the DRiP team) takes roughly (1mm NFTs / 5,000 mints per min / 60) ~= 3 hours per million. However, one key requirement for data availability of compressed NFTs necessitates the use of the Solana ledger in this way. Below i propose an improvement to a state compression tree that allows large amounts of data to be made available within the space of a single transaction, while still preserving the eventual data availability of the tree. Otherwise known as "batch minting", state compression trees can be initialized with a precomputed Merkle root. The key issue for broad usage of that tree, however, is the "leaves" that represent NFTs on Solana. How can RPCs / indexers and subsequently wallets know enough information about that tree to take advantage of a precomputed root? While the state compression program will respect any proofs used to make modifications to the tree, we need to think critically about the data availability. One option would be to add additional instructions to the state compression program to allow an InitializeTree instruction with a few additional fields: uri: points to an offchain database dump with all relevant information related to the leaves in the tree activation slot: the first slot that is the tree will allow updates

Context The Solana Tech Discord would like to be able to gate certain roles (and thus channels) to people and teams that verifiably operate testnet and mainnet-beta validators. By using Discord's "linked roles": Prompts to verify gossip identity keypairs can happen directly within the Discord interface Linked roles provide additional badging within the Discord interface, helping support trust & safety within the server After linking a wallet, roles can automatically be provided and revoked by Discord itself Constraints