feat(docs): gov and campaigns (#72)

* chore(docs): add unifi as link and calendar

* feat(docs): add campaigns info

* feat(docs): add season 1

* chore(docs): minor updates

* feat(docs): add gov params

* feat(docs): add gov calendar

* feat(docs): add s2

* chore(docs): update guide

* fix(docs): fixes

docs/campaigns-season-1.md

@@ -0,0 +1,31 @@
+---
+title: Season 1
+slug: /campaigns/season-1
+---
+
+# Season 1
+
+Puffer’s Season 1 demonstrated our commitment to Ethereum’s decentralization and user empowerment. This inaugural campaign preceded our TGE, anchored by the Crunchy Carrot Quest, distributed rewards to bolster decentralization, enhance protocol collaboration, and onboard more participants to the Ethereum ecosystem through Puffer.
+
+## Crunchy Carrot Quest
+
+The Crunchy Carrot Quest was our flagship incentive campaign in Season 1. By distributing Puffer Points across a carefully curated set of protocol partners, we encouraged activity in key areas of Ethereum’s infrastructure while rewarding meaningful contributions to decentralization. Participants could earn points through activities like restaking via EigenLayer, liquidity provisioning and engaging with partner protocols.
+
+We announced that 7.5% of $PUFFER tokens are to be allocated to the Crunchy Carrot Quest participants, available immediately to reward early Puffer supporters. 50% is available on day 1 and for larger depositors, the rest is vested over 6 months for equal opportunity for all of our community. For more information, refer to the [PUFFER tokenomics](governance-token.md) article.
+
+Claims will end on Janaury 14, 2025. If you have not yet made your claims, please do so at the official [Puffer Claims](https://claims.puffer.fi/) page.
+
+## Partner Collaboration
+
+Season 1 worked with a diverse range of DeFi protocols, creating synergies that benefited the broader Ethereum network. Some highlights included:
+
+- Boosting decentralization: By incentivizing staking outside of dominant pools, we successfully reduced stETH’s market dominance by 2.38%, strengthening Ethereum’s network resilience.
+- Cross-protocol engagement: Participants earned rewards by providing liquidity, participating in governance, or integrating with partner protocols, driving the decentralization of Ethereum.
+
+## Point Distribution Framework
+
+Puffer Points were distributed dynamically across partner protocols based on their contributions to network decentralization and user activity. This structure ensured rewards aligned with ecosystem priorities while giving participants a diverse set of opportunities to earn with the Puffer ecosystem.
+
+## Empowering Validators at Scale
+
+Season 1 wasn’t just about distributing points; it was about redefining who could participate in Ethereum’s infrastructure. Puffer’s Validator Tickets initiative lowered bond requirements to just 2 ETH, enabling more individuals to become validators and dramatically expanding Ethereum’s decentralization. Over 9,000 validators joined our network through this campaign, marking a significant milestone in Ethereum’s history.

docs/campaigns-season-2.md

@@ -0,0 +1,28 @@
+---
+title: Season 2
+slug: /campaigns/season-2
+---
+
+# Season 2
+
+Welcome to Puffer Season 2 — a transformative step in our mission to decentralize Ethereum’s infrastructure while rewarding the Puffer community for the active participation in the ecosystem. This campaign introduces tokenized, on-chain incentives, enabling a seamless transition from off-chain calculations to an on-chain rewards system, directed by the community.
+
+Season 2 represents a major evolution in our reward distribution mechanism, with CARROT as the official ERC-20 token for our tokenized Puffer Points. These tokens not only offer utility but also align incentives with our long-term vision.
+
+## Key Features of Season 2
+
+### On-Chain Incentives with CARROT
+
+Season 2 transitions Puffer Points to on-chain incentives, leveraging CARROT as the token that powers our ecosystem. CARROT tokens are distributed weekly to protocol participants based on vePUFFER votes. The token is designed to enhance transparency, fairness, and efficiency in rewards allocation.
+
+### Empowering Decentralized Governance
+
+Season 2 enables $PUFFER holders to lock their tokens to receive vePUFFER, granting voting power in the governance process. vePUFFER holders decide how CARROT incentives are allocated, creating a community-driven ecosystem that reflects the collective will of the community.
+
+### Permissionless Proposals
+
+Protocol projects, liquidity providers, and contributors can now submit proposals to participate in Puffer’s incentive campaigns. With incentive gauges, projects can compete for CARROT allocations, further decentralizing and diversifying Puffer’s ecosystem.
+
+## Stay tuned!
+
+More information will follow soon.

docs/governance-calendar.md

@@ -0,0 +1,60 @@
+---
+title: Governance Calendar
+slug: /governance/calendar
+---
+
+# Governance Calendar
+
+## Overview
+
+The Puffer Governance Calendar is your one-stop resource for staying updated on key dates and events in Puffer’s governance processes. From proposal submission deadlines to voting cycles, our calendar ensures that all participants — be it vePUFFER holders, or proposal creators — remain informed and engaged.
+
+This calendar is embedded directly below for your convenience, and it is also accessible via the [Puffer DAO Hub](https://vote.puffer.fi/). You can choose to import the calendar by importing the following iCal link to any calendar application that you use.
+
+```
+https://calendar.google.com/calendar/ical/c_494d83a09d16868a70acdfb137ef9e3aff678c9fd688700cccd07bfc806a0422%40group.calendar.google.com/public/basic.ics
+```
+
+Adding the calendar to your personal tools is highly encouraged if you would like to participate in governance of the Puffer ecosystem.
+
+<iframe src="https://calendar.google.com/calendar/embed?src=c_494d83a09d16868a70acdfb137ef9e3aff678c9fd688700cccd07bfc806a0422%40group.calendar.google.com&ctz=Asia%2FSingapore" width="100%" height="800" frameborder="0" scrolling="no"></iframe>
+
+## Key Events on the Governance Calendar
+
+### vePUFFER Staking Cutoff
+
+The vePUFFER staking cutoff marks the deadline for staking PUFFER tokens to receive vePUFFER voting power for the upcoming voting epoch.
+
+This cutoff aligns with the existing [vePUFFER parameters](./governance-token.md#vepuffer-parameters) i.e. every vePUFFER stake must be at least three (3) days old when the upcoming voting epoch begins at designated Thursdays at 00:00:00 UTC.
+
+Staking before this cutoff, currently set to the Sunday 23:59:59 UTC before every voting epoch ensures voting power is activated when the voting epoch starts.
+
+### Voting Eochs
+
+The voting epoch is when vePUFFER holders can cast their votes on governance proposals and incentive gauges. These are critical moments for shaping the Puffer ecosystem, as decisions on incentive gauges, funding allocations, protocol upgrades, and key initiatives are determined during these periods.
+
+Voting epochs currently lasts for seven (7) days as per existing [vePUFFER parameters](./governance-token.md#vepuffer-parameters) and are clearly marked on the calendar. They typically occur on a bi-weekly basis.
+
+### Rewards Epochs
+
+Rewards epochs dictate the distribution of incentives based on the outcomes of governance voting. These rewards epochs typically follow each voting epoch, with some operational buffer period, ensuring that rewards allocations to liquidity pools, validators, or other protocol participants are executed transparently and efficiently. Users can expect reward distributions to align with the incentive gauges voting results during the preceding voting epoch.
+
+Rewards epochs currently lasts for fourteen (14) days as per existing [vePUFFER parameters](./governance-token.md#vepuffer-parameters) and are clearly marked on the calendar. They typically occur right after the previous rewards epoch ends (and likewise, the preceding voting epoch as well), with some operational buffer period.
+
+### Governance Announcements
+
+Important updates, such as parameter adjustments, governance outcomes, and new initiatives, are noted on the calendar. These announcements ensure transparency and keep the community informed of all significant developments in the Puffer ecosystem.
+
+## Outside the Governance Calendar
+
+While the calendar is comprehensive, the following governance-related events occur on an ongoing basis and may not always align with specific calendar dates.
+
+<img src="/img/governance-workflow-model.webp" height="500" alt="Puffer"></img>
+
+### Proposal Submission
+
+Proposals can be submitted **at any time** via the [Puffer Governance Forum](https://governance.puffer.fi/). Once submitted, they will undergo the [discussion and review process](./governance-understanding-governance.md) before being included in the next voting epoch.
+
+### Discussion Periods
+
+Every submitted proposal undergoes a **minimum five-day discussion period**, during which community members provide feedback and suggest improvements. This period ensures that proposals are well-informed and refined before proceeding to a review. There is no definite start and end date for every proposal, given that proposals can be created at any point in time, hence a minimum time is imposed so that there is sufficient time for consideration.

docs/governance-token.md

@@ -3,7 +3,7 @@ title: PUFFER Token
 slug: /governance/token
 ---
 
-# PUFFER Token
+# The PUFFER Token
 
 The PUFFER token is the native governance token of the Puffer Protocol and UniFi ecosystem.
 
@@ -59,20 +59,26 @@ vePUFFER builds on learnings from protocols like Curve and Prisma, but introduce
 vePUFFER is used for voting within the ecosystem. To start participating in governance, users will stake PUFFER to mint a vePUFFER NFT which will begin accruing voting power on a weekly cadence. After the warmup period, they will be able to begin voting. This mechanism empowers users to actively shape the future of the Puffer ecosystem through voting rights, kickstarting true decentralization and community-led governance within the Puffer ecosystem.
 
 ### vePUFFER Parameters
-The following parameters are the initial vePUFFER parameters. They can be changed by the PUFFER community through future governance proposals.
+The following parameters are the initial vePUFFER parameters. They can be changed by the Puffer community through future governance proposals.
 
 | Category | Name | Description | Value |
 |----------|------|-------------|--------|
 | Voting Power Curve | Max Multiplier | Maximum boost on initial deposit that will be reached if a user leaves staked tokens as vePUFFER indefinitely. | 2x |
 | Voting Power Curve | Max Duration | The time it takes to reach the max multiplier following a linear increasing curve. | 2 years |
-| Voting Power Curve | Warmup Period | Minimum time that must have elapsed after staking in which a user can vote. | 3 days |
+| Voting Power | Warmup Period | Minimum time that must have elapsed after staking in which a user can vote i.e. the vePUFFER becomes active. | 3 days |
+| Voting Power | Cutoff Time | Cutoff time for staking so that the vePUFFER becomes active by the voting epoch. If you stake after the cutoff time, your vePUFFER will not be active. | Sundays at 23:59:59 UTC |
+| Voting Epoch | Epoch Period | Epoch period for voting is the period in which a voting period is active for. | 7 days |
+| Voting Epoch | Start Time | Start time for all voting, including proposals and gauges, and all vePUFFER must be at least 3 days old at this time for it to become active. | Thursdays at 00:00:00 UTC |
 | Exit Queue | Cooldown | Cooldown is the period between the user entering the exit queue and being able to withdraw the underlying tokens. They do not have voting power at this time as their NFT is held in the staking contract. | 1 month |
-| Exit Queue | Min Lock | Min amount of time a staker must hold before they can begin the exit process. | 1 Month |
+| Exit Queue | Min Lock | Min amount of time a staker must hold before they can begin the exit process. | 1 month |
 | Exit Queue | Exit Fee Percent | Tax paid in the underlying token on exit. | 0% |
 | Escrow | Minimum Deposit | Number of PUFFER tokens a user must deposit as a minimum. | 70 PUFFER |
 
+
 ## PUFFER Allocations
 
+<img src="/img/governance-puffer-tokenomics.webp" height="350" alt="The $PUFFER tokenomics overview"></img>
+
 The PUFFER token has a maximum total supply of 1,000,000,000. As of writing, there is currently an initial circulating supply of 102,300,000 (10.23%) PUFFER tokens.
 
 In the table below, we have a breakdown of how the PUFFER tokens are allocated across the Puffer ecosystem.

docs/governance-understanding-governance.md

@@ -3,7 +3,9 @@ title: Understanding Governance
 slug: /governance/understanding-governance
 ---
 
-# Governance Workflow
+# Understanding Governance
+
+In this article, we describe how governance works, and how proposals move along the pipeline, from the initial creation phase, to discussion and review by the community and the Puffer team, and finally, to the voting phase.
 
 <img src="/img/governance-workflow-model.webp" height="500" alt="Puffer"></img>
 
@@ -38,7 +40,7 @@ The Puffer Governance Review Committee plays a critical role in assessing propos
 
 The minimum two-day review process ensures only quality proposals advance to the voting stage. The committee will:
 
-- Finalize and prepare aproved proposals for voting.
+- Finalize and prepare approved proposals for voting.
 - Request additional refinement from proposals authors, feedback included if required.
 - Archive any rejected proposals with documented reasons for transparency.
 

docs/governance-voting.md

@@ -101,8 +101,8 @@ You can change your vote at any point in time before the voting epoch ends.
 
 :::
 
-Once you are satisifed with your choices, click on **Submit votes** to submit your vote by way of signing a gasless transaction. This will not cost you any ETH at this point. You will then be shown the following notification if your vote has been registered.
+Once you are satisfied with your choices, click on **Submit votes** to submit your vote by way of signing a gasless transaction. This will not cost you any ETH as we use Snapshot voting currently. You will then be shown the following notification if your vote has been registered.
 
 <img src="/img/governance-gauges-vote-successful.png" height="150" alt="Gauges vote successful"></img>
 
-Voting results will be tallied after the conclusion of every voting epoch. The rewards will be distributed through [Puffer DeFi](https://defi.puffer.fi), and only if you are a participant of the eligible pools.
+Voting results will be tallied after the conclusion of every voting epoch. The rewards will be distributed through [Puffer DeFi](https://defi.puffer.fi), and only if you are a participant of the eligible gauges.

docs/registration.md

@@ -51,7 +51,7 @@ cargo run --bin coral-cli validator keygen --guardian-threshold 1 --module-name
 
 ---
 #### Fetching the registration payload
-If you ran the Coral-CLI on a remote server you can fetch the registration payload by substituing your information in the following command:
+If you ran the Coral-CLI on a remote server you can fetch the registration payload by substituting your information in the following command:
 ```
 scp [email protected]:/path/to/coral/registration.json ~/my/local/computer/registration.json
 ```

docs/slash.md

@@ -51,7 +51,7 @@ In the case of an inactivity leak, a validator will lose increasingly more ETH a
 
 > ### Inactivity Risk
 >
-> The PoS validator set will only eject inactive validators after their effective balance falls below 16 ETH. In a stake pool, an inactive node could lose $16 - B$ ETH of Staker capital at the cost of only $B$ ETH to themself. Without a means to perform automatic ejections, protocols have set their bonds to $B=16$ ETH to protect Stakers from losing capital.
+> The PoS validator set will only eject inactive validators after their effective balance falls below 16 ETH. In a stake pool, an inactive node could lose $16 - B$ ETH of Staker capital at the cost of only $B$ ETH to themselves. Without a means to perform automatic ejections, protocols have set their bonds to $B=16$ ETH to protect Stakers from losing capital.
 
 > Currently, the only way to withdraw a validator is by signing a VoluntaryExit message (VEM) with the validator key. In a permissioned pool where nodes are trusted, the problem of getting them to sign a VEM is easy; however, the node may go offline or refuse to sign the VEM in a permissionless pool.
 

sidebars.js

@@ -49,6 +49,11 @@ const sidebars = {
       label: "Deployments",
       items: ["deployed-contracts", "multisig"],
     },
+    {
+      type: "link",
+      label: "UniFi",
+      href: 'https://docs-unifi.puffer.fi/',
+    },
     {
       type: "category",
       label: "UniFi AVS",
@@ -57,7 +62,12 @@ const sidebars = {
     {
       type: "category",
       label: "Governance",
-      items: ["governance-mission", "governance-understanding-governance", "governance-token", "governance-roadmap", "governance-voting"]
+      items: ["governance-mission", "governance-understanding-governance", "governance-calendar", "governance-token", "governance-voting", "governance-roadmap"]
+    },
+    {
+      type: "category",
+      label: "Campaigns",
+      items: ["campaigns-season-1", "campaigns-season-2"]
     },
     {
       type: "category",