Abstract

This document proposes transitioning the snapchain from POA (proof of authority) to a new
style Proof of Stake (PoS) consensus mechanism, modified from Berachain's Proof of Liquidity
model. The proposal specifically introduces development of a token for the snapchain, the introduction
of an on-protocol validator staking message that allows users to stake their token with validators,
as well as a number of other changes to the protocol to support this new consensus mechanism.

Motivation

During the Hypersnap Fork Meeting, a number of
proposals were discussed for the future of snapchain. In particular, one issue that was identified
as a key problem with the existing snapchain was the governance failures involved with the current
Proof of Authority consensus mechanism. Specifically, @CassOnMars and the Quilibrium team proposed
being added to the validator set, but have yet to be added. Meanwhile,
the Unooo team was fastracked to include their node.

Currently, it is unclear why one validator node was added when a previous proposal was ignored, but
what is certain is the current governance model for PoA introduces a centralization issue where
only one team has the ability to permit new validator nodes to be added to the network.

A new framework for validators and the snapchain is clearly necessary, and this proposal introduces
a possible solution by re-implementing the ideas from the Proof of Liquidity model proposed by the Berachain team, allowing a public validator set to be included via
an on-protocol staking mechanism. The goal should allow anyone with the Farcaster token and enough stake
to participate in the consensus of the chain, and will address a number of key issues including
allowing a public market for validator inclusion.

Rationale

"What Would The Token Do?"

A key top level issue with the current trade-offs by not including a token in the core protocol.
Previously, the Merkle team avoided the creation of a token for a number of reasons, likely
relating to the regulatory uncertainty, Venture Capital concerns, and community governance issues
for a relatively young protocol. While this is speculation and the Merkle team has not officially
stated their reasons for avoiding a token, there are a number of benefits that would solve core
issues with the system. Other Sections highlight benefits of including a token and designing
a staking flywheel, and a number of considerations are included in the Considerations section.

Spam-Reduction

An immediate benefit of including a token as a first class citizen of the protocol is the classical
spam reduction benefits. Early in the development of cryptocurrency networks, Adam Back proposed Hashcash
as a proof-of-work system to prevent email spam. Back forsaw a world where email was fundamentally
broken as a protocol since the generation of spam was slowly increasing. Today, with powerful
computers and the use of A.I., the general mechanism of adding friction to communication
networks in the form of PoW or some other economic system is necessary to prevent the
breakdown of the protocol.

Today, initial estimates utilizing Social Network Analytics
from myself, Geoff, and
Jordan suggest the current system is dominated by spam bot accounts.
Simple algorithms such as PageRank and graph segmentation on user interactions show many of the
accounts are part of clusters of spam groups utilizing AI to promote scam token projects.

Similar to the early days of cryptocurrency networks, the Farcaster protocol is currently
experiencing a breakdown in the protocol due to the ease of spam creation. Bitcoin extended this
by not only including a proof of work mechanism, but a token that was created to commoditize
the proof of work. The current state of the art in the Ethereum space is to utilize proof of stake,
and a burn mechanism where transactions include a small fee that is sent to a burn address.

On first pass, it is clear that Farcaster could benefit from a burn mechanism, where users are
required to pay a fee for all interactions. While this may seem aggresive, there are two points
which could allow this to be included in a way that doesn't harm the user experience.

1. On initial creation, validation of burn could be optional. Users who wish to pay a fee to burn
   tokens for their casts may do so, but it may not be required. Since the snapchain is currently
   sharded, it may be possible for validators to allow casts from users that are free and validate them
   at their discretion. This could give a new experimentation method for client teams who want to incentivize
   new users by taking on the storage and validation costs for users of their client. Also at the user level,
   ideally, users themselves can decide if they wish to burn tokens for their casts,
   which would also create a new signalling mechanism where client teams can prioritize cast with burned
   tokens over free casts at their discretion. More research into the tokenomics and cast economics could be
   done on an ideal implementation on first pass of this system.

2. Tipping to boost visibility could also be added. Specifically, the addition of a the optional
   burned cast fee, but additional fields for "tips" could be added that allow a user to tip specific
   entities on the system for interactions, such as validators and client teams. This allows the clients
   and validators to have an on-protocol method of generating revenue, and allows them to compete for users
   by offering better services and features on their systems, as well as turning mini-app clients into their
   own revenue generating markets to attract developers to build on their clients, as well as driving interactions
   to specific validators. This mechanism is motivated by implementations such as
   Hyperliquid's Builder Codes which
   enshrines extra data into the transaction that allows for builders to receive a portion of the fees. A
   tipping mechanism essentially offers clients and validators a way to receive income from signed user casts
   in a clean way that goes beyond builder codes. Tips should allow for multiple entities to receive tips,
   and should be implemented in a way that allows a cast to have n >= 0 tip recipients.

On-Protocol Staking

To implement staking, this proposal is motivated by Berachain's implementation of
"reward vaults" and "boosted validators".

A key note: validator sets should be chosen by the amount of tokens staked in the validators
staking contracts, allowing for a dynamic market mechanism for validator inclusion.

To implement this, this proposal suggest to design two specific new entities on the protocol or L2
that would allow for a validator staking flywheel:

1. Validator Staking Contracts. These contracts are specifically for the purpose of users staking their
   token for a specific validator. The validator then receives a time-based distribution to it's set of
   assigned reward vaults on a percentage basis of the total amount of tokens staked in the contract. For
   example, if there are two validators, one with 60% of the total tokens staked and another with 40%,
   each should receive the same amount of inflation rewards for that block that will be redirected to
   their respective reward vaults.
2. Reward Vaults. Reward vaults are the standardized mechanism by which actors in the system such as
   client teams, validators, and other entities can receive token distribution rewards. Validators should
   be able to have an enshrined on protocol method to set and redirect their inflation amounts to reward
   vaults and be able to set distribution percentages to each.

As an example:
A hypothetical validator A, and news media team B, wishes to create a client, join the network, and
incentivize users to drive to their client. The validator team and client team can have an off-chain
aggrement for 3 months to first, purchase enough tokens to seed their own validator staking contract.
Next, they can create 3 Reward Vaults: One for the Validator team, another for the client team, and a third
for ecosystem rewards. They could for the first 3 months take the ecosystem rewards vault and manually
distribute token distribution back to all users who join their validator staking contract to help
incentivize initial users to use their client, rewarding them for adding to the legitamacy of their client
and giving them valuable data. They may also redirect rewards to new mini-app developers in the future who
register onto their client and help add additional features to help drive users and interactions on their
client. They may in the future adjust these percentages to match their own community's needs and reflect
their own values for how to optimize client growth and drive casts back into their validator, where they
may have a hard revenue requirement where each cast has a minimum token burn to be included.

Other, client and validator teams can experiment with different reward structures allowing for a dynamic
market where users can decide for themselves which clients and validators to support.

Token-Distribution and Inflation

The initial token distribution event and implementation is beyond the scope of this proposal, but after
the initial distribution, the snapchain could implement a dynamic inflation model like that of standard
Proof of Stake chains. Ideally after some specified time period, tokens should be minted to reward
users locked into staking pools. The staking mechanism should be configured to point token distribution
to staking pool and redirect their rewards to staking pools. In the spirit of Berachain, the validators
can dynamically adjust the flow of their rewards to staking pools in a transparent, on protocol manner and
create their own governance relating to how they distribute tokens. Users always have the option to
"vote with their feet" if they disagree with the reward distribution of a validator and should be able to
remove stake and move to another validator if they so choose.

Supporting Mini-App Developers

As noted by mini-app developers, the current state of Farcaster's support of the mini-app ecosystem is
no longer tenable. Some key issues:

1. Merkle and Neynar stopped supporting mini-app developers, leaving a void in the ecosystem to subsidize
   capable and motivated teams to build within the farcaster ecosystem. It was also noted in many cases, that
   the receivers of the rewards were likely botting their rankings by generating fake users and subsidizing
   them with their own tokens to drive up rankings.
2. Base notably extended a competing mini-app ecosystem on The Base App. This fragmented ecosystem development
   since teams now had to maintain and develop for two separate ecosystems, and also force a selection of
   the Base chain over other L2s like Arbitrum.
3. The general Mini-App reward structure was not competitive to generate high quality and engaging applications.
   The set of rewards generally were less than $1K a month, which is not enticing for professional teams to
   build on the ecosystem and pay themselves, and likely not enough to cover base data and compute infrastructure costs.

As noted in the On-Protocol Staking section, the addition of an on-protocol reward vault allows developers
to receive an overall share of token distribution rewards across all validators, allowing for a more
equitable and sustainable reward system where teams can not only receive direct income by creating high
quality applications, but also receive token equity which can later be staked in the protocol to align
their incentives with the long term success of the protocol.

General Governnance

The ability of tokens allow for users to vote with their feet if they disagree at the client and validator
level, but additional logic could be added to allow for protocol level signaling and governance.

Specifically, additional code should be included for users in the validator staking to allow for a mechanism
where staked voters can signal approval or disapproval of proposals like protocol level changes, upgrades,
or new directions. This could be implemented in multiple ways but implementation details are not the focus
of this proposal.

Specification

A high level overview of the specification of this proposal is below:

Token Creation

Farcaster should implement a native token that directly interacts with the protocol. Standard ERC-20 functions
of the token should be included.

Token Utility on Casts

Users should be able to include two new fields on their casts an interactions that should be enshrined at
the protocol level:

1. Token fee - A fee paid by the user that is burned when their cast is included in the set of valid casts.
2. Token tipping - A list of token amounts and addresses to be sent by the cast author that goes directly
   to the specified addresses.

Staking Contracts

Two new contracts should be enshrined at the protocol level:

1. Staking Contract - A contract that allows users to stake their tokens in the protocol.
2. Reward Vault Contract - A contract that allows users to receive their token distribution rewards.

Token Distribution via Reward Vaults

The protocol should implement a logical on protocol reward distribution system and inflation schedule,
like other proof of stake chains that programmatically distributes rewards to Reward Vaults on a pro rata
basis.

Considerations

Whale Mechanics

Whales, or users with large amounts of tokens, could pose a threat to the integrity of the protocol. As mentioned
in the Hypersnap meeting, considerations for how the token should be distributed, and what powers
users have in the protocol should be carefully considered and researched. Ideally, the fork should
serve as a decentralized alternative to Farcaster, and attract multiple participants from the social
network, media, and crypto ecosystems. Selection of a model that rewards a small set of entities and
gives them disproportionate power should be avoided. As mentioned in the governance section, ideally
users should always have a choice to allow for signalling beyond the validator staking mechanism
to allow for a more equitable distribution of power.

Research should be conducted to determine the best way to implement this that allows for the system to
avoid being captured and gamed by a small set of entities, which is important for the long term
success of the protocol.

Snapchain or L2: Where Does the Token Live?

Throughout this proposal, I have used the term "Snapchain" to refer to Farcaster's chain. While this proposal
is intended to motivate discussion and debate, specific implementation details of where the token should actually
be generated is likely up for debate. For the snapchain itself, it is unclear if the system can support
a native token, specifically since the current implementation doesn't appear to enforce hard ordering.

It may make more sense for the token to be generated on an L2, but this would require additial messaging
logic between the L2 and the snapchain, as well as introduce a critical governance consideration of
where Farcaster's core token primative lives. It is assumed this should be debated over time and this document should not be seen as an endorsement of improving the snapchain to support native token functions, or specifically choosing an L2 for the token and protocol logic to be instantiated on.