Warning
We use tags for audited versions of code releases and the main branch is the working development branch. All PRs should be based against main branch.
-
Fork the repository:
- Click the "Fork" button at the top right of the repository page.
-
Clone your fork:
git clone https://github.com/<your-username>/delegation-framework.git
-
Create Working Branch:
git checkout -b feat/example-branch
A DeleGator Smart Account is a 4337-compatible Smart Account that implements delegation functionality. An end user will operate through a DeleGatorProxy which uses a chosen DeleGator implementation.
An end user controls a DeleGator Proxy that USES a DeleGator Implementation, which IMPLEMENTS DeleGatorCore and interacts with a DelegationManager.
A Delegation enables the ability to share the capability to invoke some onchain action entirely offchain in a secure manner. Caveats can be combined to create delegations with restricted functionality that users can extend, share or redeem.
A simple example is "Alice delegates the ability to use her USDC to Bob limiting the amount to 100 USDC".
A DeleGator is the contract an end user controls and uses to interact with other contracts onchain. A DeleGator is an EIP-1967 proxy contract that uses a DeleGator Implementation which defines the granular details of how the DeleGator works. Users are free to migrate their DeleGator Implementation as their needs change.
The DeleGator Core includes the Delegation execution and ERC-4337 functionality to make the Smart Account work.
Read more on "DeleGator Core" ->
A DeleGator Implementation contains the logic for a DeleGator Smart Account. Each DeleGator Implementation must include the required methods for a DeleGator Smart Account, namely the signature scheme to be used for verifying access to control the contract. A few examples are the MultiSigDeleGator and the HybridDeleGator.
Read more on "MultiSig DeleGator" ->
Read more on "Hybrid DeleGator" ->
The Delegation Manager includes the logic for validating and executing Delegations.
Read more on "Delegation Manager" ->
Caveats are used to add restrictions and rules for Delegations. By default, a Delegation allows the delegate to make any onchain action so caveats are strongly recommended. They are managed by Caveat Enforcer contracts.
Developers can build new Caveat Enforcers for their own use cases, and the possibilities are endless. Developers can optimize their Delegations by making extremely specific and granular caveats for their individual use cases.
There's several touchpoints where developers may be using or extending a DeleGator Smart Account.
- Developers can build custom DeleGator Implementations that use the DeleGator Core to create new ways for end users to control and manage their Smart Accounts.
- Developers can write any contract that meets the DeleGator Core Interface to create novel ways of delegating functionality.
- Developers can create custom Caveat Enforcers to refine the capabilities of a delegation for any use case they imagine.
- Developers can craft Delegations to then share onchain capabilities entirely offchain.
This repo uses Foundry.
forge buildforge test- Copy
.env.exampleto.envand populate the variables you plan to use if you plan to deploy any contracts.
source .env- Use Anvil to run a local fork of a blockchain to develop in an isolated environment.
anvil -f <your_rpc_url>- Deploy the necessary environment contracts.
NOTE: As this system matures, this step will no longer be required for public chains where the DeleGator is in use.
forge script script/DeployEnvironmentSetUp.s.sol --rpc-url <your_rpc_url> --private-key $PRIVATE_KEY --broadcastCurrently in Gated Alpha phase. Sign up to be an early partner here.
- We're building against Solidity v0.8.23 for the time being.
- Format on save using the Forge formatter.
Dan Finlay, Ryan McPeck, Dylan DesRosier, Aditya Sharma, Hanzel Anchia Mena, Idris Bowman, Jeff Smale, Kevin Bluer
