For the last months I've been working with @rev on a protocol with the goal of encouraging accountability using financial incentives.

We launched just a couple of weeks ago and a member of the community created a Commit with the task to review the protocol.

@kaprekar.eth posted a review here: https://mirror.xyz/kaprekar.eth/2PAz_s-Ld-WrDAXI1QXflN_3O_E_Q43GGZFLKKhWr5g

I will review the protocol from a technical perspective as a way to reason about the design choices we've made.

On the contract-side, verifying happens by calling what we call a verifier contract. Verifier contracts are external contracts with a function called verify that returns either true or false. Data can be passed from the commit creator and/or participant to the function and this data is then being used to evaluate a condition in the verify function.

When a commit is created, the creator can specify the address of the verifier and its initial data. Our app has abstracted this so by default the SignatureVerifier is selected with a trusted signer address as the data input.

Each participant then verifies by sending a signature to the contract that is verified in the SignatureVerifier.

We're also working on other types of verifiers like TokenVerifier that checks the participants' balance of a given token at the time of verification.

EASVerifier is another one that checks if the participant has a specific attestation based on a schemaUID and an attester address.

We're hoping the community will help us create and deploy their own verifiers to expand the ecosystem.

Some verifiers like the SignatureVerifier utilize trusted backend services. In our app, to generate a signature the participant needs to provide a code. This code is created by the commit creator and embedded in a QR and a link. The participant can scan this QR to have their signature generated and sent to the verify function.

We imagine and hope that people will build services in creative ways to verify participants. Some examples could be:

• Strava service that connects to the API to check the participants activity based on the creators parameters, for example run 10k.

• Check GitHub for commits or pull requests.

We also hope the community will build their own apps on the protocol for niche use-cases. An SDK has been built and the developer can provide a client config with a fee share. Any created, joined, or claimed commits that happens from this app will transfer a percentage of the funds to the provided client address.

What are you Committing to?

Check it out at: https://commit.wtf

For the last months I've been working with @rev on a protocol with the goal of encouraging accountability using financial incentives.

We launched just a couple of weeks ago and a member of the community created a Commit with the task to review the protocol.

@kaprekar.eth posted a review here: https://mirror.xyz/kaprekar.eth/2PAz_s-Ld-WrDAXI1QXflN_3O_E_Q43GGZFLKKhWr5g

I will review the protocol from a technical perspective as a way to reason about the design choices we've made.

On the contract-side, verifying happens by calling what we call a verifier contract. Verifier contracts are external contracts with a function called verify that returns either true or false. Data can be passed from the commit creator and/or participant to the function and this data is then being used to evaluate a condition in the verify function.

When a commit is created, the creator can specify the address of the verifier and its initial data. Our app has abstracted this so by default the SignatureVerifier is selected with a trusted signer address as the data input.

Each participant then verifies by sending a signature to the contract that is verified in the SignatureVerifier.

We're also working on other types of verifiers like TokenVerifier that checks the participants' balance of a given token at the time of verification.

EASVerifier is another one that checks if the participant has a specific attestation based on a schemaUID and an attester address.

We're hoping the community will help us create and deploy their own verifiers to expand the ecosystem.

Some verifiers like the SignatureVerifier utilize trusted backend services. In our app, to generate a signature the participant needs to provide a code. This code is created by the commit creator and embedded in a QR and a link. The participant can scan this QR to have their signature generated and sent to the verify function.

We imagine and hope that people will build services in creative ways to verify participants. Some examples could be:

• Strava service that connects to the API to check the participants activity based on the creators parameters, for example run 10k.

• Check GitHub for commits or pull requests.

We also hope the community will build their own apps on the protocol for niche use-cases. An SDK has been built and the developer can provide a client config with a fee share. Any created, joined, or claimed commits that happens from this app will transfer a percentage of the funds to the provided client address.

What are you Committing to?

Check it out at: https://commit.wtf