bitpro가 원문에서 글자만 모은 내용이에요. 표·그림·수식은 빠지거나 깨질 수 있어요. 전체 17쪽 중 9쪽
o when they are elected as block proposers. Clients can be assured of strict ordering of `state` events and other events that would benefit from strict ordering at the block boundary and data compaction.
Typically, `maps` are used to store snapshot data in nodes as the data itself is amenable to `key -> value` pairs.
Below is the `Snapshot` messages defined in the protocol protobuf that nodes adhere to.
```protobuf theme={null}
/**
* Snapshot contains a summary of all state events up to the most recent miniblock
*/
message Snapshot {
CommonPayload.Snapshot common = 1;
// Snapshot data specific for each stream type.
oneof content {
SpacePayload.Snapshot space_content = 101;
ChannelPayload.Snapshot channel_content = 102;
UserPayload.Snapshot user_content = 103;
UserSettingsPayload.Snapshot user_settings_content = 104;
UserDeviceKeyPayload.Snapshot user_device_key_content = 105;
MediaPayload.Snapshot media_content = 106;
DmChannelPayload.Snapshot dm_channel_content = 107;
GdmChannelPayload.Snapshot gdm_channel_content = 108;
UserToDevicePayload.Snapshot user_to_device_content = 109;
}
}
```
Take `SpacePayload.Snapshot` for example. It defines 4 maps and an inception event, which is an immutable singleton for each Space stream. Every time a node is tasked with proposing a block for a stream, if enough events have accrued (controlled on a stream-by-stream setting in the inception payload of each stream, `MinEventsPerSnapshot`), a snapshot will be taken as part of miniblock construction potentially updating all 4 maps in place and including the mutated snapshot object in the miniblock.
> The reason snapshots take place after at least `MinEventsPerSnapshot` events have been seen by the node since the last snapshot is that taking a snapshot is a global memory intensive operation for a node. Updating the snapshot for every event would increase memory complexity of miniblock creation to the complexity of including message events. By doing so periodically in batches, strict ordering latency is traded for node memory efficiency.
```protobuf theme={null}
message SpacePayload {
message Snapshot {
// inception
Inception inception = 1;
// streamId: Channel
map<string, Channel> channels = 2;
// userId: Membership
map<string, Membership> memberships = 3;
// userId: Username
map<string, WrappedEncryptedData> usernames = 4;
// userId: Displayname
map<string, WrappedEncryptedData> display_names = 5;
}
}
...
```
# Stream Checkpointing
Source: https://docs.towns.com/concepts/stream-checkpointing
Stream Checkpointing is how Towns Protocol ensures data integrity of a stream on a secure L2 blockchain. This guide provides an in-depth understanding of the process, focusing on the mini block headers, their structure, and their role in the Towns Protocol.
## Mini Block Headers
Mini block headers serve as a compact summary of a mini block's contents, providing essential information needed to verify the integrity and finality of transactions within the Towns Protocol.
### Components of a Mini Block Header
A mini block header is an event that encapsulates several critical pieces of information:
1. **Hash of Previous Mini Block Header**: This links mini blocks in a chain, ensuring continuity and traceability.
2. **Hashes of Events**: These are references to the events included in the current mini block, acting as a summary of the block's content.
3. **Snapshots (0-1)**: Optional snapshots may be included for additional context or state information. (see [Snapshotting](./snapshotting))
4. **Vote Proof**: Evidence of consensus from participating nodes, confirming the validity of the mini block's contents.
5. **Signature**: The entire event is signed by the elected leader node, adding an additional layer of security and authenticity.
### Storage and Distribution
* **Local Storage by Nodes**: Each node participating in the Towns Protocol stores the mini block headers locally. This storage plays a critical role in maintaining the network's integrity and redundancy.
* **Sent to Clients**: Mini block headers are also transmitted to clients, providing them with the necessary information to verify transaction finality and integrity.
## Finality and Verification
Understanding the finality of transactions within the Towns Protocol is crucial for maintaining trust in the system. The mini block header plays a central role in this process:
* **Transaction Finality**: If a client or node possesses a mini block header and observes a transaction on the Towns Chain with the same header hash, the transaction can be considered final.
* **Verification Process**: The interconnected nature of the mini block headers, along with the consensus proof and node signatures, allows for a robust verification process, ensuring the authenticity and integrity of the data within the Towns Protocol.
# Towns Protocol Grants Program
Source: https://docs.towns.com/grants/grants-program
Build the future of blockchain communication
## **Overview**
The **Towns Protocol Grants Program** is designed to accelerate the growth of decentralized social by funding builders who contribute meaningfully to the protocol. Our goal is to:
* Drive innovation through new products and features
* Onboard new projects that enhance the Towns ecosystem
* Improve protocol infrastructure with better tooling, automation, and scalability
Each year is divided into **two Seasons**, with **grants awarded on a rolling basis** throughout each season. This structure allows us to **adjust priorities every six months**, ensuring that grant allocations align with the protocol’s most pressing needs.
## Season One Details
Grant Funding: **Up to \$250,000**
Season 1 Deadline: **April 30, 2025**
[**Apply Here**](https://hntlabs.deform.cc/grants)
## **Types of Grants**
Towns Protocol Grants are categorized into two primary funding tracks:
### **1. Ecosystem Grants** 
These grants fund specific technical projects that expand the **capabilities of Towns Protocol**. We are looking for teams to:
* **Build New Clients**
→ Develop custom interfaces and applications on top of Towns Protocol, just like propeller.chat, which launched its own independent Towns-based client.
### **2. Registry Grants**
For developers building **bots, entitlement modules, and pricing models** needed for Towns Protocol:
* **Develop Bots**
→ Automate governance, moderation, engagement, and integrations across the Towns ecosystem.
* **Create Custom Modules**
→ Design new entitlement (access control) and pricing models that enable novel economic structures and community governance.
## **Grant Funding & Distribution**
In Season 1, **River Eridanus Association** will distribute grants up to \$250k allocated in Towns tokens to fund grants across four categories:
<AccordionGroup>
<Accordion title="Building New Clients">
We're looking for teams to build independent clients on Towns Protocol-mobile apps, web interfaces, or something entirely new. You can build any type of product that has a forum or messaging component: Think web3 versions of Substack, Patreon, Telegram, Reddit, etc.
* Check out Propeller.chat, a product feedback client built on Towns Protocol. If you want to launch your own product on top of Towns Protocol, we'll fund you.
* We have an SDK to make things easier as you get started. You can find our React SDK in our docs.
</Accordion>
<Accordion title="Building Bots ">
Bots make communities smarter. Build tools that automate **moderation, governance, notifications, or integrations** with DeFi, trading, or other apps. If it makes Towns Protocol more functional, we want to support it.
Here are some ideas:
* Cross-Platform Social bots (post to Towns and also Lens/Farcaster)
* Wallet following bots
* DAO voting bots
* Music/Translation/Gaming/Meme bots
</Accordion>
<Accordion title="Building Entitlement Modules">
Access control matters. We’re funding **token-gated systems, staking-based roles, NFT memberships, and other permission models** to give communities more control over who can do what.
Here are some ideas:
* Token-Staking Access (If you stake a token for a certain length of time, you can access a specific Town)
* Submit a bid for a membership to a Town
* NFT-Based Permissions (Different NFT traits grant unique abilities, like voting power, moderation rights, or premium content access)
* Proof of Participation Roles: Users must complete tasks (e.g., voting, attending events, posting in discussions) to unlock new permissions.
* POAP-Based Entry: Users must have attended specific events (verified via POAPs) to gain access.
Check out the current entitlement modules implemented in Towns Protocol: [https://github.com/towns-protocol/towns/tree/main/packages/contracts/src/spaces/entitlements](https://github.com/towns-protocol/towns/tree/main/packages/contracts/src/spaces/entitlements)
</Accordion>
<Accordion title="Building Pricing Modules">
Monetization is key. Build **paywalls, tipping systems, subscriptions, or custom pricing models** that let communities experiment with value exchange on Towns Protocol.
Here are some ideas:
* Recurring weekly/monthly/yearly payments to access Towns
* Time-Release Models (This Town can be joined for a certain period of time)
* Auctions to create bidding for premium access to Towns
* Leaderboard-driven contributions (Top supporters of a Town get recognition and special perks)
Check out current pricing modules implemented in Towns Protocol: [https://github.com/towns-protocol/towns/tree/main/packages/contracts/src/spaces/facets/membership/pricing](https://github.com/towns-protocol/towns/tree/main/packages/contracts/src/spaces/facets/membership/pricing)
</Accordion>
</AccordionGroup>
## Grant Review Process
### First Round
| | |
| ------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Initial Review on Relevance** | We assess the project's alignment with **Towns Protocol’s mission**, its potential impact on decentralized social, and its contribution to the ecosystem. |
| **Technical Assessment** | We evaluate the project's technical feasibility, scalability, potential challenges, and how it integrates with **Towns Protocol** and broader Web3 infrastructure. |
| **Decision on Progression** | Reviewers determine whether the project meets our criteria for innovation, feasibility, and value to **Towns Protocol**. Successful projects move on to the second round. |
### Second Round
| | |
| ---------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- |
| **Plan Presentation** | Selected teams present a detailed project plan, incorporating feedback from the first round. |
| **Milestone & Grant Amount** | We finalize key milestones and confirm the grant amount with each team, ensuring alignment on deliverables and funding structure. |
| **Q\&A Calls** | Grant reviewers and project teams engage in **Q\&A sessions** to clarify objectives, expectations, and next steps before funding is released. |
## How to Apply
If you have an idea that fits, [apply for a grant here.](https://hntlabs.deform.cc/grants)
We look forward to reviewing your application and if you have any questions about the grants process, please reach out to the Grants Council at [grants@towns.com](mailto:grants@towns.com).
# Introduction
Source: https://docs.towns.com/introduction
### What is Towns Protocol?
Towns Protocol is an open source protocol for building decentralized real-time messaging apps. It consists of an EVM-compatible L2 chain, decentralized off-chain stream nodes, and smart contracts that are deployed on Base. Towns allows people to create programmable communication use cases, referred to as “Spaces,” in a permissionless manner. These Spaces are ownable, feature on-chain subscriptions (”Memberships”), an extendable reputation system, and end-to-end message encryption.
### Purpose and Vision
At its core, the ecosystem seeks to empower people to create, manage, and participate in digital communities in a secure and permissionless manner. The primary goal is to provide a robust, secure, and decentralized platform where people have complete control over their data, privacy, and engagement in these digital spaces, while protecting their reputation. The vision extends to fostering an era of digital social that is both user-centric and community-driven, leveraging blockchain technology to ensure trust and security.
Towns’ goal is ambitious. To secure freedom of communication for a sustainable permissionless future.
### Key features
**An app chain purposefully built for social networking** – Towns secures Read/write entitlements separately on Base, allowing our app chain to make liveliness tradeoffs and send messages to thousands of participants as fast as any existing centralized social network.
**Ownable communication** – Space creators truly own the space they created as an onchain asset.
**Programmable spaces** – Spaces are deployed onchain with programmable interfaces allowing the rules, like who can read and write, to be customized to integrate with any other external EVM-compatible contract.
**On-chain memberships** with built-in protocol fees – Users are required to hold a valid membership token to send and receive messages in a Space. Paid memberships enforce a protocol fee used to pay for the operation of the network, while free Spaces do not incur protocol fees.
**On-chain social graph** – Membership tokens and Spaces are discoverable on chain.
**Extendable reputation system** – Towns’s communication spaces can be programmed to allow members peer-based, Space-specific ratings discoverable on chain.
**End-to-end encrypted messaging** - Ensures secure, private communication with advanced encryption, protecting messages between sender and entitled users.
### High-Level Component Summary
1. **Towns Smart Contracts**: Deployed on the Base Mainnet Chain, an Ethereum Layer 2 platform, these contracts enable users to create and manage their programmable communication space. Each space is minted as a unique entity, with the minter receiving an owner token, representing their controlling interest in the space. The smart contracts facilitate various functionalities, including membership pricing, gated-access, role-based entitlements, and moderation customizations for each space.
2. **Towns Protocol**: The backbone for social messaging within the ecosystem. It comprises the Towns Chain and Stream Nodes, collectively managing encrypted communications across the network. The protocol ensures secure and private group messaging, essential for maintaining the integrity of communications within each space.
3. **River Eridanus Association**: Initially established in the first quarter of 2024 as a Swiss Association – the **River Eridanus Association** supports the further growth and development of the **Towns Protocol**, through operating its grant programs and disbursement of its initial grant of tokens. The interaction between the **River Eridanus Association** and the **Towns Protocol** operates through a series of smart contracts that ensures transparency and alignment. Notably, the funding for the **River Eridanus Association** is decided by the holders of the TOWNS Token holders through the governance of the [Towns Lodge](https://townslodge.com).
4. **[Towns Lodge](https://townslodge.com)**: Responsible for governance and stewarding of the 3 billion TOWNS Tokens within its Treasury, with the holders of the TOWNS tokenholders ultimately deciding how to deploy the Treasury in support of the Towns Protocol. The [Towns Lodge](https://townslodge.com) provides essential balance to the Towns ecosystem as it provides the TOWNS tokenholders the ability to direct funding decisions through token governance.
5. **Clients**: Towns is a permissionless protocol meaning anyone can build a client to interact with it. Here is a list of popular clients already building on Towns: Towns, LateCheckout
# Contracts
Source: https://docs.towns.com/node-operator/contracts
Smart Contracts powering the Towns Protocol are deployed to Ethereum L2 networks for testnet and mainnet. This page provides a list of deployed contracts needed for running nodes and their network coordinates.
<Note>
All contract source and deployed addresses can also be found on the [Towns Protocol repository](https://github.com/towns-protocol/towns).
Contract source code is located in the `contracts` [directory](https://github.com/towns-protocol/towns/tree/main/packages/contracts).
Deployed addresses can be found under `packages/generated` for testnet and mainnet, respectively.
</Note>
### Network Chain Ids
| Network | Chain Id | Network Environment |
| ------------------- | -------- | ------------------- |
| Base Sepolia | 84532 | Testnet |
| Towns Chain Testnet | 6524490 | Testnet |
| Base | 8453 | Mainnet |
| Towns Chain | 550 | Mainnet |
### Contract Addresses
Below are contract addresses to diamond contracts that are required to register a node operator on Base.
<Note>All contracts are deployed using the [Diamond](https://eips.ethereum.org/EIPS/eip-2535) pattern for modularity.</Note>
| Contract Name | Testnet Address | Mainnet Address | Network |
| ------------- | ------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------- | ------- |
| Base Registry | [baseRegistry.json](https://github.com/towns-protocol/towns/blob/main/packages/generated/deployments/beta/base/addresses/baseRegistry.json) | [baseRegistry.json](https://github.com/towns-protocol/towns/blob/main/packages/generated/deployments/omega/base/addresses/baseRegistry.json) | Base |
Below are the deployed diamond contracts that are required to run Stream Nodes in the Towns Network.
| Contract Name | Testnet Address | Mainnet Address | Network |
| -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- | ----------- |
| SpaceFactory | [spaceFactory.json](https://github.com/towns-protocol/towns/blob/main/packages/generated/deployments/beta/base/addresses/spaceFactory.json) | [spaceFactory.json](https://github.com/towns-protocol/towns/blob/main/packages/generated/deployments/omega/base/addresses/spaceFactory.json) | Base |
| Entitlements | [entitlementChecker.json](https://github.com/towns-protocol/towns/blob/main/packages/generated/deployments/beta/base/addresses/entitlementChecker.json) | [entitlementChecker.json](https://github.com/towns-protocol/towns/blob/main/packages/generated/deployments/omega/base/addresses/baseRegistry.json) | Base |
| River Registry | [riverRegistry.json](https://github.com/towns-protocol/towns/blob/main/packages/generated/deployments/beta/river/addresses/riverRegistry.json) | [riverRegistry.json](https://github.com/towns-protocol/towns/blob/main/packages/generated/deployments/omega/river/addresses/riverRegistry.json) | Towns Chain |
### Towns Token Addresses
| Network | Address |
| ---------------- | --------------------------------------------------------------------------------------------------------------------- |
| Base Sepolia | [0x00000000A22C618fd6b4D7E9A335C4B96B189a38](https://basescan.org/address/0x00000000A22C618fd6b4D7E9A335C4B96B189a38) |
| Base | [0x00000000A22C618fd6b4D7E9A335C4B96B프로젝트로 돌아가기
