Towns 백서 전문

.</Warning> #### Basic Staking To stake, the user must call the `stake(uint96 amount, address delegatee, address beneficiary)(uint256 depositIds)` method of the RewardsDistribution facet from the BaseRegistry diamond contract. Users must select a delegatee, for instance an active operator (active operators are listed on [www.towns.com/token](https://www.towns.com/token)), to delegate to in order to earn periodic rewards. Users must also select a beneficiary, which is the address that will receive the rewards. Once `stake()` is called, a unique `depositId` is returned to track the stake for the owner. A given address can have multiple deposits or can manage a single deposit. To increase the amount of stake, the deposit owner can call `increaseStake(uint256 depositId, uint96 amount)`. <Note>Users can switch their delegatee at any time without withdrawing their stake by calling `redelegate(uint256 depositId, address delegatee)`.</Note> #### Advanced Staking Methods **Gasless Staking with Permits** For users who want to stake without paying gas for token approvals: * `permitAndStake(uint96 amount, address delegatee, address beneficiary, uint256 nonce, uint256 deadline, bytes signature)` * `permitAndIncreaseStake(uint256 depositId, uint96 amount, uint256 nonce, uint256 deadline, bytes signature)` **Staking on Behalf of Others** Authorized users can stake on behalf of others using: * `stakeOnBehalf(uint96 amount, address delegatee, address beneficiary, address owner, uint256 nonce, bytes signature)` **Managing Your Stakes** * `changeBeneficiary(uint256 depositId, address newBeneficiary)` - Change who receives the rewards from a specific deposit #### Claiming Rewards Rewards can be claimed at any time using the `claimReward(address beneficiary, address recipient)` method: **For Regular Stakers:** * Call with `beneficiary = your_address` to claim your own staking rewards * You can send rewards to any `recipient` address (yourself or someone else) **For Node Operators:** Operators can claim both: 1. **Their own staking rewards** (if they've staked tokens) 2. **Commission rewards** from users who delegated to them #### Withdrawing Stake To withdraw stake, the owner of the depositId should follow the below steps or use the staking site available in [towns.com](https://www.towns.com/token). 1. Call `getDepositsByDepositor(address depositor)` to get the list of depositIds for the depositor. 2. Call `initiateWithdraw(uint256 depositId)` with the depositId to start the withdrawal process. 3. Wait for the withdrawal to be processed subject to token lockup period. 4. Call `withdraw(uint256 depositId)` to complete the withdrawal process transferring the stake back to the owner. # Utility Source: https://docs.towns.com/towns-token/utility ## Overview Towns Token serve multiple purposes that include delegation to Node Operators, Space address delegation, and governance participation. ## Delegation to Node Operators * **Node Operator Delegation**: Towns Tokens are delegated to Node Operators, who are essential for the network's operation. To be approved by the [Towns Lodge](https://townslodge.com) and operate, Node Operators must secure a minimum delegation amount, ensuring they have sufficient stake in the network's success and security. * **Delegation Period**: Once delegated, Towns Tokens become non-transferable for a 30-day cooling-off period. This lock-in period starts from the moment the `unstake()` function is called. This restriction is in place to maintain network stability, allowing adequate time for nodes to rebalance their stream data following a reduction in their delegated tokens below the minimum requirement, leading to their potential exit from the network. ## Space Address Delegation * **Direct and Space Delegations**: Delegation can be directed either to the Node Operator's address or to any valid Space address within the network. Spaces, in turn, can redirect their delegated tokens to any specific Node, providing flexibility in delegation strategies. * **Voting Power and Delegation**: Delegating tokens to a Space allows the Space to retain its voting power in governance decisions while still contributing to a Node Operator's required delegation. Conversely, tokens directly delegated to a Node Operator not only count towards their operational stake but also transfer governance power to them. * **Enhanced Features**: Spaces with enough delegation will unlock enhanced features at the protocol level. Spaces can get additional storage retention of their data or set custom pricing modules that can allow members to join for free by having enough tokens delegated to them. ## Governance Participation * **Voting with Towns Tokens**: In addition to their role in delegation and network operation, Towns Tokens are instrumental in the governance of [Towns Lodge](https://townslodge.com). Token holders can participate in decision-making processes, influencing the direction and policies of the [Towns Lodge](https://townslodge.com). * **Balancing Delegation and Governance**: The dual utility of Towns Tokens in both delegation and governance allows for a balanced ecosystem where token holders can support network operations while actively engaging in its democratic processes. # MiCA Whitepaper Source: https://docs.towns.com/white-paper/mica-whitepaper # Towns Protocol Technical Whitepaper Source: https://docs.towns.com/white-paper/technical-whitepaper Comprehensive technical whitepaper covering Towns Protocol's architecture, cryptographic methodologies, consensus mechanisms, economic model, and governance structure for decentralized communication. ## Abstract Communication underpins every aspect of digital life, yet it remains largely centralized, leaving users dependent on platforms prone to censorship, manipulation, and limited economic participation. The Towns Protocol leverages blockchain technology to redefine digital communication by creating decentralized, secure, and economically integrated community platforms. Built with a custom appchain (Towns Chain) and Base, Ethereum's scalable Layer 2 solution, Towns Protocol introduces decentralized communication through "Spaces", user-owned and programmable digital communities. Each Space employs smart contracts to manage memberships represented by ERC-721 NFTs, enabling tailored governance, dynamic access control, and economic interactions directly integrated with blockchain financial services. Towns ensures secure messaging via advanced cryptographic methodologies, including Curve25519 key pairs and AES-GSM encrypted shared session keys, safeguarding against censorship, spam, and malicious activities. Nodes within the Towns network validate encrypted messages, achieving consensus through decentralized miniblock production and integrating cryptographic proofs directly onto the blockchain for verifiable immutability and transparency. An innovative economic model incentivizes robust participation by rewarding node operators, delegators, community referrers, and space owners, aligning ecosystem stakeholders through transparent token economics. Governance of the Towns Protocol is fully on-chain via the [Towns Lodge](https://townslodge.com) DAO, empowering token holders to propose, discuss, and implement protocol upgrades transparently and democratically. ## Introduction Communication is the most valuable aspect of the internet, underpinning nearly every facet of digital life—from personal interactions and community building to critical business operations. Today, centralized platforms such as Slack, Discord, WhatsApp, Telegram, and WeChat dominate this essential utility, capturing significant economic and social value. Decentralized communication technologies represent an unprecedented opportunity to reclaim a portion of this value, providing more resilient, secure, and user-governed alternatives. The evolution of internet communication has passed through distinct phases: initially limited to text, it expanded into images, then audio and video, and is now extending to include financial transactions. Blockchain technology uniquely enables the integration of financial primitives directly into communication platforms, significantly enriching interactions and offering new possibilities for digital communities. With blockchain infrastructure reaching maturity, it is now possible to create decentralized communication applications offering user experiences competitive with centralized services. The Towns Protocol harnesses this technological advancement, providing a robust, scalable platform specifically designed to facilitate decentralized communication. The benefits of decentralized communication platforms built on blockchain technology are numerous and impactful: * **Global Decentralization**: Operated by a distributed network of node operators worldwide, Towns ensures resilience against censorship and centralized shutdowns, safeguarding the freedom of digital expression and collaboration. * **Permissionless and Programmable**: Open and programmable infrastructure allows developers and users to innovate freely, unlocking infinite potential applications and extensions without centralized approval. * **Transparent Governance**: With rules and protocols transparently encoded into blockchain smart contracts, governance decisions and operational mechanisms are clear, auditable, and resistant to manipulation. * **Cryptographic Verification of Humanity**: Integrating cryptographic identity verification directly into the communication layer ensures genuine user participation, preventing spam, bots, and other malicious activities. * **User Ownership and Sovereignty**: Users truly own their digital spaces via cryptographic on-chain assets (NFTs), granting them control, transferability, and economic sovereignty over their communities. * **Integration with On-Chain Finance**: Seamlessly merging financial services directly into communication channels enables novel interaction models, including tipping, subscriptions, payments, and complex economic interactions, fostering vibrant digital economies within each decentralized community. The Towns Protocol addresses the limitations of centralized communication and the constraints of early decentralized attempts by delivering a user-friendly, economically integrated, and censorship-resistant platform designed explicitly for the next generation of internet communities. ## System Design ### Protocol Architecture The Towns Protocol employs a decentralized architecture consisting of three primary components: #### Spaces Spaces are programmable communication channels that users can deploy and manage onchain. Each Space has a unique contract address, allowing independent operation and governance structures. Key functionalities include customizable membership management, role-based entitlements, and moderation tools, all facilitated through specialized smart contracts deployed on the Base Mainnet, a highly performant Ethereum Layer 2 solution. #### Memberships Memberships are implemented as NFTs adhering to the ERC-721 standard, providing proof of membership and granting users specific access rights within Spaces. The supply and pricing of Membership NFTs are configurable by Space owners, allowing for dynamic or fixed pricing models and cross-chain token gating mechanisms. Membership tokens can integrate custom entitlement logic, leveraging on-chain assets or off-chain data via oracles, ensuring flexible and inclusive access control. #### Streams Stream is a core abstraction in Towns Protocol. Each stream is identified by a unique 32-byte id. Each channel, group message session, space, user, media file are stored in the specific stream. I.e. a single channel is stored in a single stream with this channel's id. Each stream is replicated to multiple (but not all) nodes. Encrypted messages are stored into the stream's minipool. Every two seconds, if the minipool is not empty, a new miniblock is produced by one of the participating nodes through a voting process. The hash and number of the new miniblock is written in Stream Registry Smart Contract on Towns Chain. Only one miniblock can be registered in the smart contract for the given height. Once a hash on the miniblock is stored on the blockchain, it becomes "canonical". By tracking these hashes, participating nodes and users know which state each stream is supposed to be in, i.e. what is the "canonical" view of each stream. #### Nodes Nodes form the decentralized infrastructure underpinning the Towns network. Managed by a Node Registry deployed on Base, nodes are responsible for validating, propagating and storing encrypted messages across the network. Nodes undergo a rigorous registration and monitoring process to maintain high operational standards, and their performance is continuously evaluated to ensure network reliability and security. ### Consensus and Incentive Mechanisms The Towns Protocol utilizes a decentralized consensus mechanism built upon the Layer 2 blockchain (Towns Chain), designed specifically for scalability and efficiency. Consensus is achieved through synchronized validation and mini-block production managed by Stream Nodes. These nodes validate message events, coordinate on their inclusion into miniblocks, and achieve consensus through a voting mechanism, ensuring accurate and secure message sequencing. Incentive mechanisms in the Towns Protocol revolve around clearly defined token economics. Node operators set commission rates deducted from periodic inflationary rewards distributed bi-weekly. Rewards are allocated equally among active operators, adjusted for their set commissions. Remaining rewards are then proportionally distributed to delegators, incentivizing active participation and staking. Economic incentives extend further to encourage robust node operation and active community participation. Nodes are continually evaluated based on their operational performance and receive rewards based on delegated tokens, ensuring alignment of interests across the network's stakeholders and maintaining overall protocol health and reliability. ## Protocol Specification ### Operational Mechanics The operational mechanics of the Towns Protocol delineate a sophisticated interplay between Ethereum-based smart contracts, decentralized node operations, and rigorous data stream validation. #### Smart Contract Interactions The Towns Protocol employs Ethereum smart contracts to facilitate decentralized governance and membership management within distinct digital communities, referred to as "Spaces". Each Space can be uniquely configured to enforce customized governance rules and community standards. Membership within these Spaces is represented and managed through minting ERC-721 compliant NFTs, embedding programmable pricing and entitlement logic directly within token metadata. To enhance secure fund management, the Towns Protocol integrates ERC-6551 token-bound accounts. These accounts securely associate funds and digital assets directly with individual ownership tokens, streamlining secure and transparent resource management. #### Node Operations Nodes within the Towns Protocol are responsible for validating, propagating, and securely managing encrypted communications. Each node performs critical entitlement checks alongside rigorous cryptographic verification, thus safeguarding the integrity and authenticity of all messages within the network. A deterministic approach governs stream allocation, administered by the Stream Registry, leveraging the immutable state provided by the blockchain. Nodes collaboratively coordinate to reach consensus, performing event validation and systematically constructing miniblocks, which ensures precise and sequential event logging across the network. #### Data Streaming and Validation Event-driven communication within the Towns Protocol relies upon encrypted payload transmission. Each event is a part of some stream, and copies of the event are stored in each stream's replicas hosted by different nodes. Upon receiving events, nodes execute comprehensive validation checks, verifying digital signature authenticity, entitlement permissions, and ensuring coherence with previously validated mini-block hashes. Validated events are subsequently committed locally to stream-specific minipools. Nodes put events from minipools into consensus-driven miniblocks, thus maintaining synchronized state across the decentralized network and guaranteeing resilient data integrity and consistency. ### Messaging Protocol and Miniblock Production The message lifecycle in the Towns Protocol involves several distinct stages, each designed to ensure decentralization, security, reliability, and efficiency. The following describes the detailed technical steps: #### 1. Message Creation (Client-Side) **Client Initialization:** Users interact with Towns Protocol via secure client applications. Each client generates and securely stores a pair of Curve25519 cryptographic keys for secure identification and end-to-end encryption of messages. **Cryptographic Encryption:** * Peer-to-peer messages used for sharing sessions are encrypted using asymmetric key pairs cryptographically associated with the user's wallet. * Group and channel messages are encrypted using shared session AEG-GSM encryption. **Signing:** After encryption messages are signed with the user's wallet. #### 2. Message Submission **Message Format:** Messages conform to a standardized Protocol Buffers payload format containing encrypted content, metadata, sender signatures, hash of the recent miniblock in the stream message sent to, and other required fields. **Client-to-Node Submission:** Clients transmit messages via gRPC-based API calls to Towns Protocol nodes, ensuring efficient, reliable, and structured data exchange. #### 3. Node Processing and Validation Upon receiving a message, nodes perform critical validation tasks: **Membership Verification:** Nodes query the corresponding Space smart contract on the Towns Chain to verify if the sender possesses the requisite Membership NFT, validating their right to post messages within that space. **Cryptographic Verification:** Nodes verify digital signatures using the sender's Curve25519 public key to ensure authenticity and message integrity. **Timestamp and Replay Protection:** Nodes enforce timestamp synchronization thresholds and validate uniqueness of message signatures to prevent replay attacks. #### 4. Decentralized Miniblock Production Towns Protocol employs decentralized miniblocks to batch and immutably store validated messages. The process involves: **Message Aggregation:** Validated messages are grouped by nodes into miniblocks, each representing short timeframes (2 seconds), ensuring near-real-time messaging. **Consensus and Agreement (OP-Stack):** Nodes use OP-Stack Towns Protocol L2 blockchain to store stream hashes and maintain consensus and agree on what is "canonical" version for any given stream. **Miniblock Structure:** Each miniblock comprises: * **Header**: Contains metadata such as miniblock height, previous miniblock hash, timestamp, Hashes of included events, hash of snapshot. The header is signed by producing a node, hash of the header is used as a hash identifying the miniblock. * **Body**: Contains a sequence of included unmodified client message that match hashes listed in the header #### 5. Miniblock Submission to Towns Chain (L2) After miniblock creation and consensus, nodes submit miniblock hash to the Towns Chain (Layer 2) StreamRegistry Smart Contract, inheriting Ethereum's strong security guarantees and ensuring that only one miniblock is "canonical" for any given stream height. **Optimistic Rollup Integration:** Miniblocks are periodically batched and submitted to Ethereum's Layer 1 via optimistic rollups, inheriting robust Ethereum consensus and security. Miniblock