Authenticators are the contracts in charge of authenticating users to create proposals and cast votes. All proposal creation, proposal update, and vote transactions must be sent to the relevant DAO’s space contract via an authenticator. DAOs are free to write their own custom authenticators that suit their own needs however we provide the following approaches:Documentation Index
Fetch the complete documentation index at: https://docs.snapshot.box/llms.txt
Use this file to discover all available pages before exploring further.
Ethereum signature authenticator
Will authenticate a user based on a message signed by an Ethereum private key. Users create an EIP712 signature for the transaction which is checked for validity in this contract.v,r,s: ECDSA Signaturesalt: The salt used in the signature to prevention replays (only required for proposal creation and updating).target: The destination space contract.functionSelector: The function selector of the desired action.data: The ABI encoded transaction payload for the action. Refer to the Space actions section for more information on the payload contents.
Ethereum transaction authenticator
Will authenticate a user by checking if the caller address corresponds to theauthor or voter address.
target: The destination space contract.functionSelector: The function selector of the desired action.data: The ABI encoded transaction payload for the action. Refer to the Space actions section for more information on the payload contents.
And more!
Our modular approach here allows spaces to authenticate users via other authentication methods without any changes to the space contract.Please note, that if you wanted to add sybil resistance to your governance process, this should not be handled by Authenticators, but by Proposal validations or Voting strategies.