🫴 Claimable Balances: Enabling Decentralization and Regulatory Compliance 🤝

[JFWooten4]

In re updating documentation, I believe we need to clarify some outstanding items, so that developers read accurate network information. ℹ️ In the medium term, this formalization can keep developers satisfied knowing that their noncustodial application will continue functioning on Stellar with a streamlined user-centric approach. 👩🏼‍💻

1. Decentralized Governance Innovation

Before diving into this post, I'd like to shine a spotlight on @ankeliu. Anke has been instrumental in spearheading SCF's collaboration with BlockScience to bring Neural Quorum Governance to life.¹ Along with the rest of the SCF team, her recent debuting efforts not only shaped the technical landscape of our network but also reinforce the importance of community-driven innovation. 💡

The deployment of NQG on Soroban represents a significant leap forward in our quest for a more democratic and transparent decision-making process. By integrating reputation-based voting power with the flexibility of opt-in group delegation, NQG sets a new standard for governance models. 🗳️ It ensures that every voice within our community can be heard and valued, paving the way for a more inclusive and equitable future.

The journey to develop and implement NQG has been nothing short of remarkable.² It embodies countless hours of research, an undeniable large commitment of financial resources, and generous community involvement and data shaping.³ Anke's vision and perseverance have been the guiding force behind this initiative, transforming it from a conceptual framework into a tangible, open-source reality now available on mainnet. 🥂

2. Claimable Balances Opportunities

Stellar solves payments, securities, and debt. It solves it better than anyone else. It is the root infrastructure that will become the interplanetary financial system imo. 💱 If Satoshi was around, I think he would approve of everything the burgeoning community built.

Claimable balances are essential to the efficient and compliant operation of the network. They provide a flexible and powerful tool for managing payments, regulatory compliance, and network efficiency. By leveraging CBs, we ensure that the network remains decentralized, efficient, and scalable, serving the needs of users, developers, and regulators alike.

In an effort to make Stellar's empowering mission a reality, this section continues our ongoing discussion of CBs. 💬 It's inspired by discussion at Consensus 2024 with @SirTyson where we contemplated the slowed growth of CBs on the network. Since Garand wasn't familiar with our use case, I'll also recap that in the next section.

2.1 Classic Operation Permanence

Classic operations with traditional financial applications form the backbone of the network.⁴ These operations are fundamental to the network’s integrity, recordkeeping, and transparency. Data integral to the network's functionality, such as transaction histories, account balances, and CBs should be stored perpetually, as is common in modern blockchains, promoting:

1. Trustless Verifiable Trust: Continuous storage ensures that all historical data remains accessible, promoting transparency and trust within the ecosystem. Users, regulators, and auditors can trace every transaction and balance, reinforcing the integrity of the network. 🔍

2. Secure Immutable Claims: Durable storage of critical financial data protects against tampering and fraud. 🚔 This security is paramount for maintaining the network’s reliability and reputation.

3. Client Operational Efficiency: Unending storage of classic operations reduces the overhead associated with data retrieval and validation, as this data is continually available without interim restoration, reconstruction, or recalibration. 📀 With a steady reference point through Horizon, clients don't need to worry about the changing state of an otherwise deterministic, defined, and deductible claimant amount.⁵ That simple choice not only means simpler front-end design but fundamentally it lowers the technical bar for new app developers to startup without operating their own nodes. 🚧

@jonjove brilliantly introduced the concept of CBs to solve a fundamental problem in payment systems: ensuring successful transactions regardless of the recipient's preparedness. According to his CAP, CBs were designed to separate the act of sending a payment from the act of receiving it. 🫱🏽‍🫲🏿 Might this feature also make Stellar more accessible given the trusting nature inherent in quorum sets?

2.1.1 Onboarding New Users

CBs are not just about simplifying ledger analysis. They are a foundational tool for permissionless financial services and self-custodial dApps. 📲 Most pressingly, anchors cannot distribute pre-existing assets to new users without either (i) claimable balances or (ii) centralized trust.

As further detailed infra note 10, the removal of claimable balances introduces requisite trust in centralized contract deployers, even if a standard interface gets developed. This challenge has already plagued other chains when routine implementations of contract standards go awry. 💭

More immediately, I will outline the trustless send case addressed in CAP-23, per infra note 11. Consider that a user has 500 pesos in their bank account. 🏦 The bank decides to upgrade their financial infrastructure to Stellar, letting users hold through any wallet application.

If Alice sends her public key to the bank, how will the bank send her pesos? One option requires central coordination whereby the bank creates the wallet app, programming in specific instructions to always add the bank pesos asset. 🧑🏽‍💻 This is not ideal because now only users of the bank app have a user-friendly way to hold their pesos.

Another option is that the bank gives explicit instructions for Alice to add PESOS-GABC...XYZ to her wallet's trusted assets. This is not ideal because the communicated message may be intercepted and changed to Mallory's PESOS-GDEA...STL asset, either during the message transit or local clipboard interactions. 😈 Moreover, it requires material effort from Alice that acts as a barrier to widespread adoption, especially with feature phones.

Lastly, I might consider the case where the bank operates an interim service where they can ping your device with a request to add a trustline to the pesos asset. 📡 This seems to requires a webhook built into all noncustodial wallet apps in accordance with a costly ecosystem standard for repeatedly querying anchors as to their intent to distribute assets to accounts without trustlines. 😕 While something like this could happen through Soroban, it just begs the question of why introduce such a new permissioned, costly, and demanding ongoing user requirement?⁶

2.1.2 Facilitating Wallet Decentralization

CBs contribute significantly to the decentralization of the network by eliminating the need for centralized coordination in wallet onboarding. 👛 In traditional payment systems, centralized entities often manage the onboarding process, creating potential bottlenecks and single points of failure. However, with CBs, anyone can send funds to an account without requiring the recipient to be immediately prepared to receive them.

Namely, CBs let anchors perform nuanced mission-critical real-world applications today with transparent and distributed agreement on the conditions of a claimed transfer. I posit that the network is drastically more valuable with the core financial functionality CBs provide through (i) dynamic claimant options, (ii) ledger-bound chronology, and (iii) account object association. 🔐

These three features alone let anchors integrate with existing Stellar wallets without asking permission for a wallet's asset trustlines, which may need to get approved. Might we leave the responsibility of managing claim decisions in the hands of the user rather than the sender? 🤔 This was one option suggested from the recipient end without adding even more data to the CB.

2.1.3 Self-Introduced Claimant

The existing docs recommend that you "put one of your own accounts as a claimant for a claimable balance." This is concerningly problematic in a distributed environment because of risks a claimant faces while waiting to satisfy all claim conditions. ⏲️ More to the point, it introduces undue custodianship risks if the keys of a semi-honest grantor are ever compromised.

Consider the case where Charlie creates a CB for Alice, claimable in a year. Say Charlie is also allowed to claim the CB for the sake of decreasing network data, thus increasing the amount of storage needed for the CB's additional claimant. Alice now faces the real risk that Charlie claims back the CB on day 364, which could happen for a number of reasons. ❌

Firstly, consider the case where Charlie is a real-world institution offering assets for user Alice. Say Charlie goes bankrupt on day 256, and lawyers analyzing the chain of claims on the entity decide that Alice does not come before senior debtholders. 👩🏿‍⚖️ Charlie now has a direct means of seizing the claimable asset from what would have otherwise been Alice's balance.

If the asset in question has clawbacks enabled, then this is fine and expected behavior. But if the asset is exclusively transferrable—say USDC—then Alice has been materially cheated. 🧐 Accordingly, users across the network may begin worrying as the widespread adoption of this suggested practice squarely introduces uncertainty while waiting for claim conditions, thereby introducing counterparty risk.⁷

Accordingly, the finality of CB transactions gives users comprehensive certainty of payment, per:

1. Uncoordinated Wallet Creation: CBs enable a seamless, flexible, and independent onboarding experience without the need for centralized control. Users can receive funds even if they don't have a pre-existing trustline or a prepared account. This reduces the reliance on centralized entities to manage and coordinate the onboarding process, thus promoting a more decentralized ecosystem. 🌐

2. Facilitating Transfers and Gifts: CBs allow users to make transfers and gifts without the recipient needing to take immediate action. This is particularly beneficial for scenarios such as sending gifts or making charitable donations. 🎗️ The sender can create a CB, and the recipient can claim the funds at their convenience, ensuring a smooth, effective, and hassle-free transfer process.

3. User Tax Benefits: From a tax perspective, CBs can offer significant advantages. When a user sends a gift or makes a transfer using a CB, the ownership transfer occurs at the time of claiming rather than at the time of sending. 💼 This can help users manage their tax liabilities more effectively, as the (non-accrual) taxable event is deferred until the recipient claims the balance.

2.2 Unsystematic Data Rents

As we have collectively agreed, arbitrary smart contract data does not require the same level of permanence as classic operations.⁸

Might the network continue adopting a dual approach to data storage:
  perpetual storage for classic operations and
  rent-based storage for arbitrary contract data?

Implementing a rent-based storage model for this type of data addresses the issue of state bloat and ensures sustainable network performance. Soroban's approach to state expiration exemplifies this strategy, incentivizing efficient storage management as well as commonplace execution runtimes:

Because CBs are not Soroban contracts, I believe it bears reiterating Soroban's common objectives:

1. Managing State Bloat: State bloat occurs when the blockchain's state grows uncontrollably, making it difficult for validators to manage and slowing down transaction processing. By applying a rent model, only essential data remains on the ledger long-term, reducing bloat and improving overall efficiency. This works well when applied to any and all miscellaneous user data on a resource-specific allocation curve. 🧮

2. Economic Incentives: Requiring smart contract data to pay rent creates economic incentives for developers to manage their data efficiently. This model ensures that validators only retain valuable, foundational, and imperative data; while pruning redundant, unoptimized, or outdated information. ⏳ Notably, core financial data like payments and other existing classic operations still never disappear.

3. Scalable Decentralization: By mitigating state bloat, the network can maintain high operations per second and lower the barrier to entry for new validators. This approach supports decentralization by ensuring that validator requirements remain manageable. 🛜 However, I respectfully submit that Stellar already has reasonable validation costs, per the recent validator awards program, generally in line with other major blockchains.

2.3 Core Data Permanence

One common use of CBs is for token lock-ups, which have systemically-important implications in regulated securities. Should Stellar become the new standard financial system, we respectfully submit that the maintenance of these records ought continue operating with classic efficiency. Tactful improvements on the existing model may also foster widespread community adoption, as:

"Token lockups are one of the best mechanisms for demonstrating conviction in the long-term success of a project and for aligning the interests of stakeholders over the long-term. This can be determined at various time periods, potentially far in advance of other token considerations; for example, in seed rounds when token warrants are signed."
— Adina Fischer, Matt Gleason, and Justin Simcock at a16zcrypto

Given this institutional importance, a simple fix for the spam challenge ensures transparency, security, and efficiency for critical financial operations while managing state bloat. By keeping limited core data outside of contracts, we can maintain the network’s integrity, application, and reliability, ensuring its long-term success and usability. 🌌 As originally suggested by
Igor Natanzon at Franklin Templeton, we can maintain existing critical systems by allowing users themselves to reject CBs, ensuring that only meaningful and desired transactions remain on-chain.

3. Restricted Security CBs

We at Block Transfer and the greater DRS community see great value in noncustodial distribution. The promise of CBs for out-of-the-box claim topics wholly separates Stellar from competing chains.⁹ It drastically improves the ease of auditing grants and acceptances of assets compared to existing smart-contract solutions. 😵‍💫

CBs are not just a voting tool, distribution framework, or decentralization precedent. They have practical, real-world applications that are vital to our efforts to decentralize capitalism. 🌍 A key aspect of this is their ability to seamlessly comply with the SEC's promulgated Rule 144, an American securities law mandating a stock be held for up to a year after issuance before it can be claimed and freely traded.

This regulation aims to prevent undue public distribution by ensuring that stockholders do not inadvertently act as underwriters. CBs directly address the requirements of Rule 144 by allowing us to issue stock that is claimable only after the mandatory holding period. This ensures regulatory compliance while simplifying the process for our users. 👨🏾‍💼 They can confidently hold and eventually claim their stock without the risk of violating securities laws.

3.1 Stellar's International Protocol

Our TAD3 platform leverages CBs to manage the distribution, disclosure, and claiming of equity offerings. By utilizing CBs, we can ensure that all regulatory requirements are met, providing a transparent and efficient way to handle equity distributions. 📈 This method not only simplifies compliance but also enhances trust, accountability, and reliability in our system.

In building TAD3, I've come to recognize the growing importance of a uniform standard financial system, especially for empowering today's disenfranchised. 🤐 If you agree that we're all together building a platform affecting billions down the road, then fostering adoption through existing classic operations seems inherent.

Introducing a reject_claimable_balance_op can streamline CB management. In my original undercollateralized loan example, the creditor can reject the CB upon loan repayment, burning a nominal reserve fee and returning the 10 yBTC. This operation reduces network load and simplifies transactions. 🔩

3.2 Email Protocol Parallel

We don't block emails because we're worried about storing spam. If bad actors want to spread information across the network, they will.¹⁰ This was true for email since the earliest of days when mass message distribution could generate any profit. 🪙 Thankfully, a growing number of frontend providers are disabling memo displays from unknown senders by default. 🫱🏻‍🫲🏼

The community has a unique opportunity to fix spam in a decentralized, inherent, self-incentivized way. This promising governance chance can leave the network leaps and bounds ahead of traditional centralized and often-exclusory email filters with centralized blacklists. 📨 I believe in our ability to analyze all relevant viewpoints and make a selection that keeps adoption growing!

Lastly, the related cost per CB issue seems similar to unknowing conundrum of selling postage stamps before you know the distance a letter will travel. 📬 Implementing these nuances on a contract-by-contract basis presents material ongoing concerns which are not an issue with the classic standardized operation.¹¹ One option is to continue following the example set by major postage services: standardizing costs enough to cover the average expense, inherently subsidizing remote edge-case users in the name of accessibility and inclusive public policy goals.

3.3 Collaborative Solution Discovery

As many other members I've talked to, the community's relentless humanitarian mission inspired, astounded, and enticed my imagination. Never would I imagine such care from a financial protocol when learning about the existing banking system as a kid. Our community is now planting the seeds for what might just grow into the world's most stable oak. 🌳

Let me know if this line of reasoning makes sense to you. Would love to hear how you approach any stellar principles, involvement, and adoption.¹² Claimable balances are a technological marvel that give us a real opportunity to displace incumbent oligopolies through innovation. 🌱

Might we discourage spammers by allowing the rejection of CBs, burning base reserves to the fee pool after using them to cover transaction costs? 👀 This approach can ensure that only relevant and meaningful data persists across ledgers, maintaining network efficiency and scalability. The community's unique L1 features make Stellar an unparalleled tool for empowering anyone, anywhere, anytime to employ capitalism without centralized, self-interested exclusion from a privileged few.¹³

Footnotes

1. Anke’s dedication, leadership, and tireless commitment have been pivotal in driving this project forward, marking a massive advancement in decentralized governance. ↩

2. This project is a testament to what we can achieve when we come together, pooling our resources and expertise for the greater good. ↩

3. Anke’s ability to rally support, gather insights, and drive engagement has been nothing short of inspirational. ↩

4. See, e.g., payment histories, portfolio trading, and claimable balances (“CBs”). ↩

5. By deductibility, I'm explicitly referring to the unique ability for CBs to be trustlessly modified by an asset issuer, especially when clawbacks are enabled. This foundational federated power allows for the surefire, transparent, and custodian-less implementation of asset splits, which have created challenges before and enticed an anchor solution. While infra Section 3 will detail our implementation and nuances, these can only be formatted into a SEP with certainty around CB durability. ↩

6. Open access to financial infrastructure means low cost and ultimately radically efficient wallet operations. ↩

7. See, e.g., market importance, modern implications, and incomplete alternatives. ↩

8. See, e.g., inaugural smart contracts release, design, and craft supplements. ↩

9. The differentiating ability to specify when an account can claim a payment is a groundbreaking innovation at the native network level. ↩

10. See, e.g., low barrier to entry in existing spam providers, mass payment campaigns with memos, and any number of online bots. ↩

11. See, e.g., question of entries v. instances, specific storage syntax, and ongoing retrievability should there by a redundant pressured transition. ↩

12. Id. The existing implementation, which has been subject to ongoing community improvements, elegantly solves all these challenges, as was noted during review a few years ago. ↩

13. See, e.g., financial application of the SDEX for your own gain as the only native decentralized order book, enabling market inclusion without legacy membership costs. ↩

[sisuresh]

Hey @JFWooten4, thanks for your passionate input! We've been thinking about Claimable Balances internally, but wanted to gather some data before discussing our options with the ecosystem. Rejecting a Claimable Balance and having the sponsor lose the base reserve is one of the options we're thinking about. Rest assured that we will not implement a change without input from the ecosystem.