Towns 백서 전문

s attributes. ## Implementation of Custom Pricing Modules To implement a custom pricing module, a contract must adhere to the `IPricingModule` Interface. This interface includes the `getPrice` function, which can be programmed to calculate prices based on different criteria, such as the total number of memberships minted or other programmable attributes. See more examples in \[Recipes]. ### Default Pricing Modules in Every Space Every newly deployed Space in the Towns ecosystem is equipped with two default pricing modules: 1. **Dynamic Pricing Module** (default setting): * **Pricing Strategy**: This module adopts a dynamic pricing approach, where the price is influenced by the number of members in the Space. * **Price Calculation**: The price logarithmically approaches \$10 USD as membership reaches 1,000, and then again increases logarithmically to approach \$100 USD as membership reaches 10,000. * **Price Cap**: Membership prices never exceed \$100 USD. * **Initial Offer**: The first 100 memberships are offered for free. * **Payment Method**: Accepts ETH as payment. * **Reference**: For more details, see `DynamicPricing.sol`. 2. **Flat Fee Price**: * **Fixed Pricing**: This module implements a straightforward fixed pricing strategy. * **Minimum Price**: Sets a minimum price of \$10 USD for a membership. * **Payment Method**: Also accepts ETH as payment. ## Transaction Fee Distribution An essential aspect of the pricing modules is the distribution of fees from transactions. These fees are split among key stakeholders: * **Space Owner**: A portion of the fees is allocated to the SpaceOwner, providing an incentive for maintaining and growing the Space. * **Towns Community**: At present, a share of fees contribute to the **River Eridanus Association**, supporting the overall development and sustainability of the ecosystem. Upon implementation of they buy-and-burn function, the remaining fees will be contributed to the [Towns Lodge](https://townslodge.com) giving TOWNS tokenholders the decision on how to deploy those funds to further the Towns Protocol. * **Referrers**: Referrers, if any, are also rewarded, encouraging community growth and engagement. Referrers can be set for both members of a Space as well as for the client being used to interact with the protocol. **Note**: Free Spaces do not incur protocol fees on membership transactions (joining or renewing). Tipping within any space (free or paid) incurs a separate protocol fee on member tips, while bot tips have no protocol fee. # Roles and Entitlements Source: https://docs.towns.com/towns-smart-contracts/roles-entitlements Understanding Roles, Entitlements, and Permissions in Towns Protocol In the Towns ecosystem, `Permissions` are defined actions that users can undertake within a `Space`. These permissions are fundamental to governing user interactions and activities within the ecosystem. The Towns system includes a range of permissions, each tailored to specific functionalities: * **Read**: Allows users to access and view message content within a Space. * **Write**: Allows users to create and modify message content within a Space. * **React**: Allows users to add reactions to messages. * **AddRemoveChannels**: Allows users to create and delete channels within a Space. * **ModifyChannel**: Allows users to edit channel settings. * **ModifySpaceSettings**: Allows users to change Space settings. * **ModifyRoles**: Allows users to create, update, and delete roles and entitlements within a Space. * **ModifyBanning**: Allows users to ban and unban members from a Space. ## Concept of Roles `Roles` in the Towns system are aggregations of the aforementioned `Permissions`. By combining different permissions into distinct roles, the system simplifies the management of user capabilities and access within a Space. ## Functionality of Entitlements `Entitlements` play a crucial role in determining user eligibility for different Roles. They dictate how users qualify for certain Roles and can be specific to different Channels or the Space itself. ## Implementation of Entitlement Modules `Entitlement Modules` are instrumental in defining the requirements for Entitlements. These modules are akin to pricing modules, allowing for the deployment of bespoke smart contracts on the chain. To be incorporated into the Towns system, these contracts must adhere to the `IEntitlement` Interface and be deployed to Base, with their settings adjusted for each Space. ## Default Settings in Spaces Upon the minting of a new Space, the Towns system automatically deploys two standard Entitlement Modules: 1. **UserEntitlementModule**: This module enables the assignment of Roles based on specific addresses or ENS. For instance, "vitalik.eth" could be assigned the Moderator Role, while "0x44..ccbb" might receive a Read-Only Role. 2. **TokenEntitlementModule**: It facilitates the assignment of Roles based on the ownership of certain assets on-chain. An example would be assigning a Special Role to users holding a Cryptopunk or a Whale Role to those with at least .1 ETH. ## Default Roles in Newly Minted Spaces Each newly minted Space in the Towns system is initialized with two predefined Roles: **Owner** - Assigned automatically to the address holding the Owner NFT through the Token Entitlement Module. This Role encompasses all permissions within the Space and is irrevocable. **Member** - Granted to any address holding a Member NFT. By default, this Role includes "Read" and "Write" Permissions, allowing for basic interaction within the Space. # Space Membership Source: https://docs.towns.com/towns-smart-contracts/space-membership Space Membership in Towns Protocol is built on Membership Tokens—on-chain assets that grant holders defined rights and capabilities within individual Spaces. These tokens serve as a gateway, enabling their holders to participate actively, access exclusive features, and engage in various interactions determined by each Space's unique rules and configuration. **Subscription Model:** Memberships are initially defined with a 1 year expiry, while still allowing renewal at the original price that it was purchased rather than the current market price for a new membership. This prevents early members of a Space from getting priced out and provides additional value to the membership token itself. **Configurable Supply:** The supply of Membership Tokens is under the direct control of the Space owner. This feature allows for the customization of the Space’'s exclusivity, tailoring the community size to the owner's vision. **Flexible Pricing Models:** Pricing for these tokens is highly versatile. Space owners can set fixed prices or implement any custom pricing scheme that can be articulated through code. For further details on the pricing structure, refer to the \[Pricing Modules] section. **Access Control Mechanisms:** Membership Tokens can be gated based on the possession of specific [ERC-20](https://eips.ethereum.org/EIPS/eip-20) or [ERC-721](https://eips.ethereum.org/EIPS/eip-721) tokens across multiple networks including Ethereum Mainnet, Optimism, Polygon, Arbitrum, and Base. This creates a flexible and inclusive gating system. **Custom Entitlement Logic:** In addition to standard ERC20/721 and address gating mechanisms, Membership Tokens can also incorporate custom logic. For example channels rules can be composed based on the current score of an on-chain game or the liquidity in a defi protocol. Combining this with on-chain oracles allows for even greater flexibility to gate based on real-world events. This logic can be coded and deployed on any of the supported chains, offering a higher degree of customization for access control. For more information, see \[Entitlement Modules]. **Reputation System:** Within a Space, Membership Tokens have the unique ability to accrue reputation from other members. This feature fosters a community-driven environment where member interactions contribute to one’s standing in the Space. For detailed insights, refer to the \[Reputation] section. **Token Standards and Composability:** Membership Tokens align with the [ERC-721](https://eips.ethereum.org/EIPS/eip-721) standard. This adoption ensures seamless integration and interoperability with other blockchain components, making them easily composable within the wider ecosystem. # Space Ownership Source: https://docs.towns.com/towns-smart-contracts/space-ownership Space Ownership in Towns is designed with a unique approach emphasizing direct and transferable control over Spaces through a specially minted token. This section outlines the intricacies of Space Ownership, focusing on fund management, ownership transfer, and enhanced security features. ## Creation and Ownership * **Token Minting**: Upon the creation of a Space on Base, the creator is awarded a special on-chain token. This token is not merely symbolic; it confers complete ownership over the corresponding Space. * **Ownership Rights**: Space contracts are pre-configured to recognize the holder of this token as the Owner. This design choice introduces flexibility in ownership, allowing the token to be transferred or controlled by decentralized entities like a DAO or a multisig wallet. ## Financial Management * **Funds Management**: The process of Membership minting channels all funds directly to a contract. This contract is wholly controlled by the ownership NFT. Access to these funds is granted through direct ERC-721 ownership validation, providing the NFT holder with exclusive financial control. ## Transfer and Security * **Space Sale**: The ownership model facilitates the transfer of ownership rights. Owners can sell their Space by simply transferring their NFT, effectively passing on all ownership privileges. * **Enhanced Security**: For added security and collective management, Spaces can be stored in multisig wallets or managed by other DAO structures. This arrangement allows multiple parties to partake in the control and decision-making processes of the Space. * **Guardian Module**: Prevents the Owner token from being transferred immediately in case of holding wallet compromise. * **Interface Implementation**: The Space Owner NFT implements [ERC-721](https://eips.ethereum.org/EIPS/eip-721), ensuring compliance with established standards and facilitating interoperability within the blockchain ecosystem. ## Additional Resources * For more detailed technical information, please refer to the \[Space Contract Interface]. # Upgradeability Source: https://docs.towns.com/towns-smart-contracts/upgradeability The Diamond Pattern with Facets In the blockchain and smart contract realm, the [Diamond Pattern](https://eips.ethereum.org/EIPS/eip-2535) emerges as a sophisticated solution for contract upgradeability. This pattern is designed to overcome the limitations of traditional smart contract systems, where deployed contracts are immutable and cannot be upgraded. The Diamond Pattern, also known as [EIP-2535](https://eips.ethereum.org/EIPS/eip-2535), introduces a modular structure using 'facets', which allows for more flexible and manageable contract upgrades. Spaces meanwhile always retain the right to opt out of upgrades and always fully retain control ownership and funds. ## Understanding Facets Facets are individual, modular contracts that together form the complete Diamond. Each facet can contain a specific set of functionalities or logic. The beauty of this approach lies in its compartmentalization; facets can be added, replaced, or removed without affecting the entire system. ## The Role of the Diamond Proxy At the core of the Diamond Pattern is the Diamond Proxy. This is a single proxy contract that delegates calls to the appropriate facets. The Diamond Proxy maintains the state and delegates function calls to specific facets that implement these functions. This setup enables the core logic of the Diamond to be updated or expanded by modifying its facets. ## Benefits of the Diamond Pattern 1. **Upgradeability**: The most significant advantage of the Diamond Pattern is the ability to upgrade smart contracts. Facets can be replaced or updated, allowing for improvements and bug fixes post-deployment. 2. **Modularity**: By dividing functionality into different facets, the system becomes more organized and manageable. This modular approach also aids in understanding and auditing the contract's code. 3. **Gas Efficiency**: The Diamond Pattern can be more gas-efficient compared to other upgradeable contract systems. Since only the facets are upgraded, the gas costs associated with deploying large contracts are significantly reduced. 4. **Enhanced Functionality**: The pattern allows for a broad range of functionalities to be implemented, which might not be possible in a single contract due to block gas limits. ## Implementing the Diamond Pattern Implementing the Diamond Pattern requires careful planning: * **Designing Facets**: Determine the functionalities to be encapsulated in each facet. This division should be logical and efficient. * **Managing State**: Ensure that the Diamond Proxy effectively manages the state across all facets. * **Security Considerations**: Given its complexity, the Diamond Pattern demands rigorous testing and auditing to prevent security vulnerabilities. # Claiming Rewards Source: https://docs.towns.com/towns-token/claiming ## Claim Process At the end of each distribution period, addresses that are delegating or designated as [Authorized Claimers](./delegation) can claim their rewards. ## Claim Execution Rewards are claimed by calling the `claimReward(address beneficiary, address recipient)` function on the [RewardsDistribution](https://github.com/towns-protocol/towns/blob/main/packages/contracts/src/base/registry/facets/distribution/v2/RewardsDistribution.sol) contract, which transfers the tokens to the recipient's wallet. The `claimReward` function is called from the claimer address, who is either the beneficiary or an authorized claimer that can claim the reward for the beneficiary. <Note> Since the RewardsDistribution contract is a facet of the BaseRegistry contract, the `claimReward` function is called from the BaseRegistry contract address (see [contracts](/node-operator/contracts)). </Note> To view the current reward claimable by `claimReward` in wei, call `currentReward(address beneficiary)` on the RewardsDistribution contract from the BaseRegistry diamond contract. The following example shows how to call `currentReward` from the BaseRegistry diamond contract with `cast`: ``` cast call \ --rpc-url $BASE_RPC_URL \ "0x7c0422b31401C936172C897802CF0373B35B7698" \ "currentReward(address)(uint256)" \ "0xa4742402D6E314a069CeB1c3C2C4eFb2982d7D44" 37995641418907243501899 [3.799e22] ``` <Note> To convert the current reward to base token units from wei, divide the result by `1e18`. </Note> # Economics Source: https://docs.towns.com/towns-token/economics ## Inflationary Mechanism * **Annual Inflation Rate**: The TOWNS token features an annual inflation rate of 8% beginning after year 1, which is programmed to decrease linearly over a period of 20 years, reaching a final inflation rate of 2%. This gradual reduction is intended to decrease the rate of new token issuance over time, aligning with the expected maturation and growth of the network. The DAO can vote to lower inflation only. * **Epoch-Based Distribution**: Inflation rewards are distributed bi-weekly to all active Node Operators in the system. Each operator receives rewards proportionally based on the total tokens staked to their nodes. Operators retain their defined commission, after which the remaining rewards are passed to delegators. Delegators then receive their portion of rewards proportional to the number of tokens they have staked with that operator. ## Reward Allocation and Fees * **Node Operator Fees**: Each Node Operator has the ability to set a percentage fee for their services. This fee is subtracted from the total inflation rewards allocated to the Node Operator for the epoch. * **Distribution to Delegators**: After the deduction of the Node Operator's fee, the remaining inflation rewards are distributed pro-rata among the delegators of that Node Operator. This mechanism ensures that both Node Operators and their delegators are rewarded for their contribution to the network's security and operability. # Mechanics Source: https://docs.towns.com/towns-token/mechanics ## Deployment and Initial Supply TOWNS is deployed as an ERC20 token on the Ethereum Mainnet with an initial supply of 10 billion tokens. ## Inflation Process * **Annual Inflation**: TOWNS's supply is inflated once per year through a publicly callable function ensuring a predictable increase in token supply. This inflation rate can only be lowered via an onchain governance vote. * **Minting**: This inflation process involves minting new tokens, with the total amount being that one years value of inflation. ## Distribution on Base * **Bridging to Base**: TOWNS tokens are distributed on the Base blockchain. Tokens are minted via the inflation function on the mainnet Towns contract and bridged via the Base Standard Bridge to the origin contract of the Towns Treasury contract which supplies the Rewards Distribution contract. * **Distribution Contract**: The distribution contract on Base must be invoked once per claim cycle. This contract is responsible for allocating rewards based on various factors, including the active Node Operators, their set percentage fees, and the distribution of delegated tokens. ## Reward Allocation and Claiming * **Claim Cycles**: Tokens are supplied to the Distribution contract on a biweekly cadence and tokens are claimable via the Distribution contract at any time by the beneficiary or authorized claimer specified when staking. * **Signaling and Reward Adjustment**: The protocol incorporates a signaling mechanism for bad node behavior. Reports from other nodes and the DAO regarding misconduct or underperformance will be considered in the reward allocation process, ensuring that rewards are distributed fairly and incentivize good behavior. # Staking Source: https://docs.towns.com/towns-token/staking ### Staking Process The Towns token can be staked on Base to contribute to the security and decentralization of the Towns proof-of-stake network. Any holder of Towns tokens can participate by delegating their tokens to node operators within the ecosystem. Staking can be done directly on the contracts or via an interface at [towns.com/token](https://towns.com/token). Rewards for staking are continuously accrued and distributed on a biweekly schedule. Each operator receives rewards proportionally based on the total tokens staked to their node. Operators retain a defined commission, after which the remaining rewards are passed to delegators. Delegators then receive their portion of rewards proportional to the number of tokens they have staked with that operator. Delegators rewards can be claimed at any time. Upon initiating an unstaking request, a 30-day cooldown period is enforced before the staked tokens become fully withdrawable. ### Staking Contracts Staking is handled by the v2 version of the [RewardsDistribution](https://github.com/towns-protocol/towns/blob/main/packages/contracts/src/base/registry/facets/distribution/v2/IRewardsDistribution.sol) contract. External methods from RewardsDistribution can be called from the BaseRegistry diamond contract directly using any ethereum compatible client such as [cast](https://getfoundry.sh/cast/overview/). The BaseRegistry diamond is deployed on Base (see [contracts](/node-operator/contracts)). ### Staking Execution <Warning>Though we illustrate programmatic instructions below, interacting with the staking contract is best performed through the staking site available in [www.towns.com/token](https://www.towns.com/token)