@farcaster

FAQ - FIP: Channels on Snapchain #276 (you had a lot of good questions, so yes, this is long) > Does this FIP change how channels work or add new features? No. This FIP simply moves channels onto the protocol. For the general user, everything works the way it does today, the difference is any client can read and write channel data, not just the Farcaster client. New capabilities like moderation tools, posting permissions, gating, and financialization tools will come either as follow-up FIPs or as client-level experiments. > I own a channel today. What would I need to do if this change is made? Nothing. Your channel, members, mods, followers, and pins all carry over automatically. You won't need to do anything until your first renewal comes up after this ships. We are also exploring ways to subsidize the renewal fee for channels that meaningfully contribute to the network. > Which chain will this live on, Base or ETH L1? Undecided. Farcaster nodes already read events from Ethereum, Optimism, and Base, and the name-registry contracts work the same on both chains. --Base ----For: it's the cheaper, already-proven path. Farcaster already processes paid onchain events from Base (Farcaster Pro purchases work this way), so channel registrations would follow an existing pattern rather than a new one. And gas on Base costs almost nothing, so what you pay is the registration fee and not much else. ----Against: Base is run by Coinbase. For a naming system meant to last, some feel a single company's chain isn't a neutral enough home. --ETH L1 ----For: the most neutral ground available — no single company controls Ethereum mainnet, and it has the strongest track record of simply continuing to exist. Names registered there would live under ENS, the same system Ethereum names have used for years. ----Against: gas costs more. Though for a transaction you make once a year, the extra dollars matter less than they would on an everyday action. > What is the fee for? Why $25? The fee exists to make squatting expensive without pricing out builders. And it's explicitly not final, the amount and renewal term are open questions in the FIP. The $25 amount is not new, it is inherited from the original launch of Channels. > Was the old $25/yr ever actually enforced? No. It was written in the docs that the $25 would be renewed annually, but the renewals were never enforced. > Can pricing change after launch? Yes, we can absolutely update pricing and add some functionality that makes pricing adaptive in the future. Price is USD-pegged, converted to ETH at payment time via Chainlink, so the mechanism already supports changing the dollar figure. > Do existing channels have to pay now? No. Active channels are grandfathered in automatically (ownership, members, mods, followers, and pins all carry over). Owners won't pay anything until their first grandfathered term ends. Inactive and abandoned channels won't be migrated, which frees those names back up for people who'll actually use them. Activity criteria TBD. > How often do I renew? We think once per year is right, and you'll be able to prepay multiple years at once. Renewal term length is an open question in the FIP. > Where do the registration/renewal fees go? To the Protocol Treasury, which is used to make the protocol's growth self-sustaining. > Are the channel NFTs (ownership) transferable? Yes. Standard ERC-721 transfer; nodes ingest the Transfer event and ownership re-resolves to whichever FID has the new owner address verified. > How long do migrated legacy channels get registered for? We think one year is right, but this is an open question in the FIP. > What happens when a channel expires? If a channel expires, it enters into a 90-day grace period where the owner can still renew or transfer the NFT to a new owner who wishes to renew, name isn't released, casting continues, but mod/admin tools are frozen. After the grace period the name returns to the pool, and any user can trigger an auction to claim it. The new owner of the NFT inherits all the channel's elements — members, history, and pins attach to the channel_id — and the name which resolves to the channel. We can make it clear in the client that the channel has changed ownership so users can decide if they want to still be a member. > What happens to moderation rights when ownership transfers? The new owner gets all owner powers immediately (only owners appoint/remove moderators), and the existing moderator roster carries over until the new owner makes a change. > How do moderation and posting permissions work on protocol generally? - owner appoints/removes moderators (max 10); owner can't be banned - owner + mods: add/remove members, ban/unban, pin (one pin per channel, new replaces old), hide/unhide casts - ban always supersedes a membership add - membership_mode OPEN (self-join valid) or APPROVAL (self-join rejected) - casting is never gated at the protocol level — casting_mode (EVERYONE / MEMBERS_ONLY / RECOMMENDED) is advisory metadata that clients enforce, deliberately, to avoid cross-shard reads - cast hiding (ChannelModerate) is also advisory to clients > How will channels generate value for owners instead of just costing money (rev share, tokens, monetization)? No change. This FIP deliberately only mirrors existing functionality in a more decentralized way. Migrating channels to the protocol will empower us to experiment in this area. > Can I rename a channel without losing its identity and members? No. Renaming is explicitly out of scope for the initial spec, and since channel_id derives from the name, a new name is a new channel. This is the same as the current channel system. > Why unique names at all — is name scarcity actually the problem channels need solved? Because names are how people actually use channels. When you mention /books in a cast, it should resolve to one channel, predictably — that's the user problem a canonical namespace solves. Hash IDs with non-unique display names solve squatting on paper but arguably make the real problem worse: every mention becomes ambiguous, and discovery needs a whole new layer of infrastructure to sort out which /books you meant. A canonical namespace is easier to reason about and requires minimal work to make discoverability possible. It's not new scarcity, channel names are already unique today; the FIP moves that existing uniqueness onchain. Display names will continue to exist alongside /names for flexibility. > Do channel display names stay alongside /names? Yes, and this is the answer to "can I rename my channel." The /name is immutable, same as today. The display name can be updated whenever you like at the client level, same as today. > Can multiple names point to one Channel? No, explicitly not included in the initial spec. > Why build an "ENS-style" system instead of using actual ENS, .farcaster.eth subdomains, or contract-address/DID identity? This is built on ENS. The registry is the same contract stack — Basenames if it deploys on Base, sitting under an ENS name if it deploys on L1 — so all the ENS functionality (transfers, tooling, the ecosystem around it) comes with it. As for .farcaster.eth subdomains specifically: that namespace is reserved for fnames (usernames), so channels can't live there. > Can a multisig or multiple FIDs own a channel? ----Contract-owned (a multisig): yes. A team can share control of the _wallet_ that owns a channel. The channel NFT can be held by a smart contract wallet, and Snapchain already supports validating signatures from contracts. ----Multi-FID owned: No. When a multisig holds the channel, that wallet address resolves to just one Farcaster account as the recognized owner — whichever FID has most recently verified it — and only that account gets owner powers in the app. Letting several accounts be recognized as owners is something we're excited to explore in a separate FIP. > Will there be FC-owned channels for important hubs? Kind of. Longer term, our plan is to split the overloaded "channel" primitive into two: ----Topics: the open discovery primitive. Hashtag-style cast tags anyone can use, no gating. Built for broad, shared spaces and finding what's happening. ----Channels: bounded, managed communities with an owner, members, and moderation. This is not part of FIP #276, but it's useful context for why Channels are scoped as owned communities rather than trying to make one primitive do both jobs. > Will narrowcasting come back? It’s not included in the FIP, but also not excluded. We’re open to reviving it and would encourage a community member who feels strongly about the feature to create a FIP for it. (Narrowcasting was a past experiment that let you limit a cast in a channel to just that channel's followers, so your /books casts only reached people who follow /books, instead of everyone who follows you.) > Why prioritize this now given current activity levels? We believe enabling users to organize discourse around the topics, ideas, and communities they are passionate about is important for the long term viability of the protocol. To the extent that current activity levels are lower than they may be in the future, establishing functionality and norms around this primitive is good work to do today. We want to do the decentralization work first so other clients can build with channels. > Is this already built and decided? Were the PRs staged before the FIP was posted? No. We do have PRs written, but that is typical for FIPs. Nothing has been deployed. Everything is still in development and planning. > How do I give input? Comment on GitHub discussion #276! https://github.com/farcasterxyz/protocol/discussions/276

2 replies

8 recasts

26 reactions