Authenticators
Last updated
Was this helpful?
Last updated
Was this helpful?
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:
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 Signature
salt : 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 section for more information on the payload contents.
This can work in conjunction with a meta transaction relayer to allow proposal creation or vote costs to be sponsored by the DAO, providing a free end user experience.
Will authenticate a user by checking if the caller address corresponds to the author or voter address.
target: The destination space contract.
functionSelector: The function selector of the desired action.
The core use case for this authenticator is to allow smart contract accounts such as multi-sigs to use Snapshot X as they have no way to generate a signature and therefore cannot authenticate via signature verification.
Our modular approach here allows spaces to authenticate users via other authentication methods without any changes to the space contract.
data: The ABI encoded transaction payload for the action. Refer to the section for more information on the payload contents.
Please note, that if you wanted to add sybil resistance to your governance process, this should not be handled by Authenticators, but by or .