Optimism Builder's Dollar Hackathon Spec

[RonTuretzky]

(Optimism Builder's Dollar Referred to as OBD here after)

Overview

1 2 3 4 5 thanks to the efforts of @diterra-code @tbsoc @0xBeau (?)

The goals of this spec are to provide a reasonable workload for the Funding The Commons hackathon , provide a deliverable solution that will be forward compatible, but may still require manual maintenance and upgrades in the future.

The goal is to allow Optimism Foundation projects which have passed the application process successfully to be eligible for receiving yield from the OBD. This is conditional on them receiving a minimum number of vouches from accredited Optimism ecosystem members.

Background

Please refer to these docs for background on $BREAD v2 ,and yield distribution
Please refer to this file for background on $BREAD v1. The Optimism foundation utilizes EAS to identify projects , project applications and more. The OBD mechanism will utilize these attestations in order to integrate the optimism eco-system into the mechanism.

On Chain

---

classDiagram

	class OBDYieldDistributor{
	        OptimismBuildersDollar OBD
mapping(address => bool) eligibleVoter
mapping(address => uint256) projectToExpiry
uint256 SEASON_DURATION
uint256 currentSeasonExpiry
                mapping(bytes32 => bool) eligibleProject 
                mapping(bytes32 => address ) projectToAddress
                IEAS optimismEAS
                address [] optimismFoundationAttestors 
                address [] currentProjects 
		uint256 minRequiredVouches
		uint256 public PRECISION
		uint256 public cycleLength
		uint256 public lastClaimedBlockNumber
		uint256 public previousCycleStartingBlock
                vouch(bytes32 projectApprovalAttestation)
                declareVoucher(bytes32 identityAttestation)
		distributeYield()
		isReadyToDistribute()
	}

	class OwnableUpgradeable{
		 +owner()
		 OnlyOwner()

        }
	class OptimismBuildersDollar{
		setYieldClaimer()
	}
	class BreadV1{
		
	}
	class RemovedBreadV1Features{
		+claimRewards()
	}
	OptimismBuildersDollar --> BreadV1
	OptimismBuildersDollar --> RemovedBreadV1Features

Loading

Yield source

By utilizing $BREAD v1 , we can easily utilize AAVE yield as the source.
Amendments to the contract would include:

• Updating the claimYield, claimRewards functions to comply with the $BREAD v2 interface
• Adding a yieldClaimer role and modifier
• Update the project to foundry and rewrite tests

Project Selection

This section refers to the $BREAD equivalent of member projects , how they are selected, added , removed and managed.
We will utilize the following schemas in order to integrate the approved projects into the yield distribution.

Approved Projects

classDiagram
    class ApprovedProject {
	    + schemaUID: 0x3d1afc69090e3133e65385364bd88f230d8df3e5e2c660fdc9206c0ce3e2e012
 +name : string
+organization : string
+description: string
+url : string
+event: string
    }

Loading

Given a Approved Projects attestation produced by the expected Issuer (the Optimism foundations address) which has an approved status and a "Grantee" name, we can programmatically infer that this project is approved by the Optimism foundation. We can then use the to address to later allow the project submitter to claim the funds.

So when a project is vouched for the first time, the frontend should submit the ApprovedProject attestation, and the contract should do a full verification flow. Further vouches can omit the verification part, as the project should already be considered eligible by the contract.

sequenceDiagram
    participant User as Voucher
    participant Frontend
    participant OBD as Yield Distributor Contract
	User ->> Frontend: Choose a project to vouch for and initiate process
    Frontend ->> Frontend: Retrieve ApprovedProject attestation ID 
    User ->> OBD : Initiate transaction 
    alt Project is not included in Yield Distributor Contract
        OBD ->> OBD: Check attestor and status 
        alt If attestor is Optimism foundation and status is true
        OBD ->> OBD: Mark project as eligible for recieving vouches
        end
    end
	OBD->> OBD: Add vouch to project 

Loading

Voucher Selection

The following schema is used by the optimism foundation in order to create identities for those eligible to vote

```mermaid 
sequenceDiagram
    participant V as Voucher
    participant Frontend
    participant c as Yield Distributor Contract
    Frontend ->> Frontend: fetch Optimism foundation attestation 
    alt Initiator is sanctioned voting address by optimism foundation
        c -->> c: Allow voter vouch and whitelist
    else Not sanctioned by optimism foundation
        c ->> c: Revert 
    end

When a project has reached the minimum amount of vouches, it should be eligible for receiving future yield.

Yield Distribution

The yield is distributed equally between all projects. Gelato should be used to automate the yield distribution.

---

Off-Chain

The frontend will be static, and should require no manual adjustments from the development team to be accurate over time.

Project Indexing

Using the EAS GraphQL API all the projects and their details can be loaded onto the page. For example, this query

query FilteredAttestation {
  schema(where: { id: "0x3d1afc69090e3133e65385364bd88f230d8df3e5e2c660fdc9206c0ce3e2e012" }) {
    attestations(where: { 
      AND: [
        { decodedDataJson: { contains: "Approved" } },
        { decodedDataJson: { contains: "Grantee" } },
        { attester: { equals: "0xA1c40eA4a5ac3bCB2878386AF5377B7c96d42462" } },

      ]    }) {
      decodedDataJson
      attester
    }
  }
}

Will fetch all projects. Try here
This query will fetch project metadata

By combining these queries and filtering, we can display all the projects and their metadata, as well as provide the necessary objects for vouchers to prove that the projects are legitimate when vouching.

Project Component

The project component should include the following (fetched from the project metadata URI)

• Organization
• Description
• Charmverse URL
• The vouching component

Farcaster component

This component should allow to use the farcaster custody address to declare a voting address, which will be used in the rest of the flows.

Vouching Component

flowchart

s[Account connects] --> fi[Attempt to fetch farcasterID and find attestation]

fi --> |Custody address not already used to declare vouching address| f[Link to page explaining why account can't vote]

fi --> |Connected account is a valid identity| vi[Fetch ApprovedProjected AttestationID]
  

vi -->|Project already vouched for| txi[Submit vouch transaction with ApprovedProject attestaion ID]

Loading