Created the website-docs repo

.gitignore

@@ -0,0 +1,20 @@
+# Dependencies
+/node_modules
+
+# Production
+/build
+
+# Generated files
+.docusaurus
+.cache-loader
+
+# Misc
+.DS_Store
+.env.local
+.env.development.local
+.env.test.local
+.env.production.local
+
+npm-debug.log*
+yarn-debug.log*
+yarn-error.log*

README.md

@@ -0,0 +1,41 @@
+# Website
+
+This website is built using [Docusaurus 2](https://docusaurus.io/), a modern static website generator.
+
+### Installation
+
+```
+$ yarn
+```
+
+### Local Development
+
+```
+$ yarn start
+```
+
+This command starts a local development server and opens up a browser window. Most changes are reflected live without having to restart the server.
+
+### Build
+
+```
+$ yarn build
+```
+
+This command generates static content into the `build` directory and can be served using any static contents hosting service.
+
+### Deployment
+
+Using SSH:
+
+```
+$ USE_SSH=true yarn deploy
+```
+
+Not using SSH:
+
+```
+$ GIT_USER=<Your GitHub username> yarn deploy
+```
+
+If you are using GitHub pages for hosting, this command is a convenient way to build the website and push to the `gh-pages` branch.

babel.config.js

@@ -0,0 +1,3 @@
+module.exports = {
+  presets: [require.resolve('@docusaurus/core/lib/babel/preset')],
+};

docs/arch/_catagory_.json

@@ -0,0 +1,4 @@
+{
+    "label": "Puffer Pool Architecture",
+    "position": 4
+  }

docs/arch/board.md

@@ -0,0 +1,17 @@
+---
+sidebar_position: 6
+title: Joining the Pool
+---
+
+- Stakers swap ≥ 0.01 ETH for pufETH.
+
+- NoOp running Secure-Signer saves a fresh validator key to its encrypted and persistent enclave
+  memory.
+- NoOp performs Remote Attestation, committing to the validator key.
+- NoOp submits attestation evidence and 2 ETH to permissionless NoOp onboarding contract.
+- Onboarding contract verifies the key was generated by Secure-Signer, pairs the NoOp with 30
+  Staker ETH, and registers the Puffer Pod in the beacon deposit contract.
+- pufETH is minted for the 2 ETH NoOp bond but is locked.
+- The NoOp performs validator duties on behalf of the Pod, earning consensus and execution
+  rewards.
+- Secure-Signer prevents the NoOp from accidentally signing slashable material.

docs/arch/ejection.md

@@ -0,0 +1,15 @@
+---
+sidebar_position: 4
+title: Ejections
+---
+
+The yield of the Puffer Pool relies on the performance of the Node Operators (NoOps). If a NoOp goes offline, they will
+lose approximately as much ETH as they would have made if they were online and performing their
+duties. The penalized ETH comes from the NoOp’s collateral, protecting Stakers ETH; however, going
+offline hurts the pool in potential rewards.
+
+To further incentivize good performance, the pool has a
+mechanism to penalize NoOps who go offline. Anyone can trigger an ejection if a Pod’s balance drops
+below 31.99 ETH (after ≈ 4.5 days of inactivity). The ejector is rewarded 0.1 ETH from the NoOp’s
+collateral, and the Pod is withdrawn from the validator set. Ejections will distribute the NoOp’s
+accrued LSD token rewards to the pool to further motivate performance.

docs/arch/governance.md

@@ -0,0 +1,11 @@
+---
+sidebar_position: 5
+title: Governance
+---
+
+PUFI is the governance token for the Puffer DAO and is used to vote on the Puffer Pool ecosystem’s
+direction in the form of grants (e.g., for research, code optimizations, developer tools, etc) and for
+voting on protocol updates to the LSD smart contract (e.g., updates to remote attestation contract,
+fees, etc). The DAO is responsible for managing the treasury that accumulates protocol fees. Since
+Puffer is permissionless, the DAO is not responsible for whitelisting or selecting NoOps which may
+lead to cartelization.

docs/arch/overview.md

@@ -0,0 +1,17 @@
+---
+sidebar_position: 2
+title: Overview
+---
+
+In the Puffer Pool, **Puffer Pods** are made up of one NoOp and multiple Stakers. The NoOp must
+provide a 2 ETH bond and is then paired with Stakers, who contribute chunks of 30 ETH in increments
+of 0.01 ETH. The Pod registers a validator key, generated by the NoOp’s Secure-Signer, and joins the
+validator queue. Stakers mint Puffer's pufETH LSD (one-to-one with their staked ETH), while the NoOp mints
+locked pufETH for their bonded ETH.
+The NoOp operates Secure-Signer with MEV-Boost enforcement, splitting any execution rewards
+based on the Smoothing Factor. Some ETH is immediately rewarded to the proposing NoOp, while
+the rest is socialized across the Puffer Pool and Treasury. The consensus rewards are distributed to the
+Pool with a small fee going to the Treasury to fuel protocol development. The ETH from consensus
+rewards will automatically accrue on a weekly basis following the [Shanghai](https://notes.ethereum.org/@launchpad/withdrawals-faq) update.
+
+![pufferarch](img/arch.jpg)

docs/arch/smoothing.md

@@ -0,0 +1,18 @@
+---
+sidebar_position: 3
+title: MEV Smooothing
+---
+
+In-protocol MEV smoothing has been proposed with the goal of reducing the variance of [MEV distribution](https://ethresear.ch/t/committee-driven-mev-smoothing/10408)
+to as close to uniform as possible but remains in the research phase. Secure-Signer can
+be extended to enforce that NoOps use MEV-Boost and a portion of the execution rewards are distributed
+back to the pool. We refer to the lever that controls the socialization of execution rewards as
+the Smoothing Factor (S, where 0 ≤ S ≤ 1.). A smoothing factor of S = 1.0 will socialize all execution
+rewards to the stake pool, while a smoothing factor of S = 0.0 will return all execution rewards to the
+NoOp that proposed the block.
+
+We believe that implementing MEV smoothing is crucial for solo validators to have a fair opportunity
+to compete in the Puffer Pool, especially in the presence of wealthy institutional Stakers that have
+control over many validator keys. Additionally, MEV smoothing contributes to censorship resistance
+as solo validators can participate with non-dominant MEV strategies while still earning competitive
+revenue.

docs/background/_catagory_.json

@@ -0,0 +1,5 @@
+{
+    "label": "Background",
+    "position": 2
+  }
+

docs/background/mev.md

@@ -0,0 +1,16 @@
+---
+sidebar_position: 3
+title: MEV
+---
+
+[MEV](https://ethereum.org/en/developers/docs/mev/) provides for an unfair user experience, can introduce consensus instability via block re-organizations,
+and serves a cartelizing force as MEV extraction benefits from economies of scale. MEV exhibits
+a tragedy of the commons, where despite its negative externalities, partaking in MEV provides a
+competitive advantage over abstaining. Thus to remain competitive, validators will extract MEV,
+but ultimately larger staking operations will perform the best.
+
+For example, a pool with 10 times
+more validators will have 10 times the opportunities to extract MEV and optimize this [process](https://ethresear.ch/t/proposer-block-builder-separation-friendly-fee-market-designs/9725/6).
+Additionally, some MEV strategies require proposing consecutive blocks, which is statistically unlikely
+unless you control many validators ($k/Ni$ , where k is the validators controlled out of N and i the number
+of consecutive blocks).

docs/background/mevboost.md

@@ -0,0 +1,24 @@
+---
+sidebar_position: 4
+title: MEV-Boost
+---
+
+To mitigate the effects of economies of scale, [Proposer-Builder Separation (PBS)](https://ethresear.ch/t/proposer-block-builder-separation-friendly-fee-market-designs/9725/6) was proposed
+and implementations like [MEV-Boost](https://github.com/flashbots/mev-boost) were built to help democratize access to MEV opportunities
+to all validators. MEV-Boost is a middleware software that interacts with consensus clients, exposing
+validators to a marketplace of MEV-optimized blocks. Builders bid to have their blocks proposed by
+validators in exchange for the block rewards. By decoupling block building from proposing, validators
+are no longer required to specialize in MEV extraction to remain competitive, lowering the barrier
+of entry and promoting decentralization. For example, efficient MEV extraction requires compute
+requirements beyond what is expected for validators, barring entry for many solo validators.
+
+Block builders benefit from economies of scale and are prone to cartelization, but do not pose the same threat
+to Ethereum since validators ultimately control the blockspace.
+
+Secure-Signer is compatible with MEV-Boost. The NoOp’s consensus client transfers block headers
+from the MEV-Boost middleware to Secure-Signer, which will only sign it if the header’s slot is
+strictly greater than the last slot signed by Secure-Signer. This combination empowers any NoOp with
+slash-resistance and access to MEV-competitive blocks. The Puffer Pool further increases financial opportunities
+by exposing the NoOp to the pufETH LSD and leveraged staking.
+
+![MEV-Boost](img/mevboost.jpg)

docs/background/slash.md

@@ -0,0 +1,26 @@
+---
+sidebar_position: 2
+title: Slashing in Ethereum PoS
+---
+
+# What are slahable offenses in Ethereum Proof of Stake (PoS)
+
+Slashing occurs when a validator equivocates or sends conflicting messages within the validator network.
+There are three ways this can happen:
+
+- By proposing and signing two different blocks for the [same Slot](https://ethereum.org/en/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/)
+- By attesting to a block that ”surrounds” another one [(effectively changing history)](https://ethereum.org/en/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/)
+- By ”double voting” by attesting to two candidates for the [same block](https://ethereum.org/en/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/)
+
+Common causes of slashing occur when a Validator Key is shared across multiple Consensus Clients,
+causing conflicting signatures. While this may occur accidentally, the network cannot differentiate this
+behavior from an attack on the consensus protocol.
+Slashing can be avoided by remaining consistent with previously signed blocks and attestations.
+In practice, this is done by maintaining a history of previously signed material within the consensus
+client or externally in a [Remote-Signer](https://github.com/ConsenSys/web3signer). Whenever the consensus client presents the remote-signer
+with new blocks or attestations, the remote-signer first checks its previously signed material for any
+conflicts before signing. While this technique reduces the risk of slashing events, there are instances in
+which the remote-signer is vulnerable. For example, a validator may be slashed if its validator key is
+shared amongst multiple remote-signers. Additionally, a slash may happen if the validator’s previously
+signed material is accidentally or maliciously corrupted.
+Checkout [Secure-Signer](tech/securesigner.md) to findout how Puffer prevents slashing.

docs/intro.md

@@ -0,0 +1,22 @@
+---
+sidebar_position: 1
+slug: /
+---
+
+# Puffer introduction
+
+Puffer is a slash-free and permissionless liquid staking protocol that facilitates at-home staking via a low bond
+requirement of 2 ETH. The Puffer team presents Secure-Signer, a remote-signing tool compatible
+with all consensus clients that prevents slashable offenses through trusted hardware. Requiring
+the use of Secure-Signer within the Puffer Pool eliminates the risk of slashing, either by accident
+or due to bugs in the consensus client.
+
+## Why reducing the bond matters
+
+Ever since Ethereum switched to proof of stake (PoS), anyone with enough ETH capital can participate as a validator, but the high capital requirement favors institutions. As a result, the validator set tends towards centralization.
+Liquid staking derivatives (LSDs) have recently accelerated this, resulting in a validator set composed of just a few entities with unprecedented control over Ethereum blockspace ([more on risks of LSDs](https://notes.ethereum.org/@djrtwo/risks-of-lsd)).
+Puffer reduces the bond by 16 times for the node operators (NoOps) to help reduce the barrier of entry for more participants, therefore further decentralizing the Ethereum.
+
+## How can we reduce the bond requirement
+
+As a NoOp's bond decreases, the risk of slashing also increases because NoOp bond gets lower compared to staker's funds. Secure-Signer eliminates the risk of accidental slashing which allows the NoOp's bond to decrease significantly. To know more about what a bond and a slashlable offenses are, check out the [background section](background/slash.md).

docs/tech/_catagory_.json

@@ -0,0 +1,5 @@
+{
+    "label": "Puffer Pool Technology",
+    "position": 3
+  }
+

docs/tech/securesigner.md

@@ -0,0 +1,25 @@
+---
+sidebar_position: 2
+title: Secure-Signer
+---
+
+Puffer’s Secure-Signer prevents these vulnerabilities through the use of Enclaves. To prevent possible
+slashes through double-signing, the Secure-Signer generates and safeguards the BLS validator key
+inside its encrypted and tamper-proof memory. This key can only be accessed during runtime and
+remains encrypted at rest, making it inaccessible to the NoOp unless used to sign block proposals or
+attestations. Since each key is bound to a Secure-Signer instance, it is not at risk of being used across
+multiple validator clients. This protects a validator’s locked ETH in the event that the NoOp is hacked
+and their validator key is leaked and used in an intentional slashing event, a possibility on all existing
+staking platforms.
+Beyond safeguarding the validator key, Secure-Signer prevents slashing by maintaining an integrityprotected
+and prunable database of previously signed material adhering to [EIP-3076](https://eips.ethereum.org/EIPS/eip-3076). Whenever
+the consensus client passes Secure-Signer blocks or attestations, validator key signatures are contingent
+on the following assertions holding:
+
+- proposal check: slot > previous slot
+- attestation check: source epoch ≥ previous source epoch
+- attestation check: target epoch > previous target epoch
+
+These assertions are enforced through the enclave and hold even if the NoOp’s operating system
+is compromised, significantly reducing NoOp risk and allowing the Puffer Pool to lower the bond
+requirement safely.

docusaurus.config.js

@@ -0,0 +1,65 @@
+/** @type {import('@docusaurus/types').DocusaurusConfig} */
+
+const math = require("remark-math");
+const katex = require("rehype-katex");
+
+module.exports = {
+  title: "Puffer Docs",
+  tagline: "Documentation for the Puffer Protocol",
+  url: "https://pufferFinance.github.io",
+  baseUrl: "/",
+  onBrokenLinks: "throw",
+  onBrokenMarkdownLinks: "warn",
+  favicon: "img/favicon.png",
+  organizationName: "pufferfinance",
+  projectName: "doctest",
+  themeConfig: {
+    prism: {
+      additionalLanguages: ["solidity"],
+    },
+    navbar: {
+      title: "Puffer Docs",
+      logo: {
+        alt: "Puffer Logo",
+        src: "img/Logo Mark.svg",
+      },
+      items: [
+        {
+          href: "https://github.com/PufferFinance",
+          label: "GitHub",
+          position: "right",
+        },
+      ],
+    },
+  },
+  presets: [
+    [
+      "@docusaurus/preset-classic",
+      {
+        docs: {
+          routeBasePath: "/",
+          sidebarPath: require.resolve("./sidebars.js"),
+          // Please change this to your repo.
+          editUrl: "https://github.com/PufferFinance/doc-test",
+          remarkPlugins: [math],
+          rehypePlugins: [katex],
+        },
+      },
+    ],
+  ],
+  stylesheets: [
+    {
+      href: "https://cdn.jsdelivr.net/npm/[email protected]/dist/katex.min.css",
+      type: "text/css",
+      integrity:
+        "sha384-odtC+0UGzzFL/6PNoE8rX/SPcQDXBJ+uRepguP4QkPCm2LBxH3FA3y+fKSiJ+AmM",
+      crossorigin: "anonymous",
+    },
+  ],
+  plugins: [
+    [
+      require.resolve("@easyops-cn/docusaurus-search-local", "@rehype-katex"),
+      { indexBlog: false, docsRouteBasePath: "/", indexPages: true },
+    ],
+  ],
+};