Part of this code was inspired by https://github.com/makerdao/rwa-toolkit/blob/master/src/urns/RwaUrn.sol mainly authored by livnev and https://github.com/dapphub/ds-roles/blob/master/src/roles.sol authored by DappHub. Since it should belong to the MakerDAO community the Copyright from our additions has been transferred to Dai Foundation.
The system is comprised of several layers:
The allocation system includes several actor types:
AllocatorBuffer and funnel contracts.
AllocatorRoles contract to perform specified actions on the
AllocatorVault, funnels and conduits.
Each AllocatorDAO has a unique
ilk (collateral type) with one VAT vault set up for it.
ilks have a shared simple oracle that just returns a fixed price of 1:1 (which multiplied by a huge amount of collateral makes sure the max debt ceiling can indeed be reached). In case it is necessary a governance spell could also increase it further.
Single contract per
ilk, which operators can use to:
draw) NST from the vault to the AllocatorBuffer.
wipe) NST from the AllocatorBuffer.
A simple contract for the AllocatorDAO to hold funds in.
AllocatorVault pushes and pulls NST to/from the
AllocatorBuffer, it can manage other tokens as well.
A global permissions registry, inspired by ds-roles.
AllocatorVaults, funnels and conduits in a per-action resolution.
A registry where each AllocatorDAO’s
AllocatorBuffer address is listed.
A module that pulls tokens from the
AllocatorBuffer and sends them to be swapped at a callee contract. The resulting funds are sent back to the
It enforces that:
Contracts that perform the actual swap and send the resulting funds to the Swapper (to be forwarded to the AllocatorBuffer).
SwapperCalleeUniV3, where swaps in Uniswap V3 can be triggered.
A primitive for depositing liquidity to Uniswap V3 in a fixed range.
As the Swapper, it includes rate limit protection and is designed so facilitators and automation contracts can use it.
An automation contract sample, which can be used by the AllocatorDAOs to
wipe from/to the
An automation contract, which can be used by the AllocatorDAOs to set up recurring swaps of stable tokens (e.g NST to USDC).
Swapper primitive in the
Swapper primitive will rate-limit the automation contract.
An automation contract sample, which can be used by the AllocatorDAOs to set up recurring deposits or withdraws.
DepositorUniV3 primitive in the
Depositor primitive will rate-limit the automation contract.
An automation contract sample, which can be used by the AllocatorDAOs to move funds between their
AllocatorBuffer and the conduits in an automated manner.
AllocatorBuffer to/form the conduits,
this can be useful for optimizing yield by moving funds to the destination conduit just in time for them to get processed
(in case the destination conduit has an agreed upon rate limiting).
An interface which each Conduit should implement.
line) of their respective
cap amount of funds per
era interval for a specific configuration. This includes not being able to move funds directly to any unknown address that the AllocatorDAO Proxy did not approve.
cap amount of funds per
era (as for a funnel operator) but is additionally constrainted by
amt1) amount of funds per
hop for a specific configuration. Moreover, a keeper's execution must guarantee a minimum amount of output tokens, defined by
req1) for a specific configuration.
uint32 is suitable for storing timestamps or time intervals in the funnels, as the current version of the Allocation System is expected to be deprecated long before 2106.
uint96 is suitable for storing token amounts in the funnels, as amounts in the scale of 70B are not expected to be used. This implies that the Allocation System does not support tokens with extremely low prices.
limit.era is zero the full cap amount can be swapped for multiple times in the same transaction because
limit.due will be reset upon re-entry. However, this is consistent with the intended behavior, as in that case zero cooldown is explicitly defined.
configs[src][dst] is changed. Failing to do so may result in the swap call reverting or in taking on more slippage than intended (up to a limit controlled by
configs[gem0][gem1][fee][tickLower][tickUpper] is changed. Failing to do so may result in the deposit/withdraw call reverting or in taking on more slippage than intended (up to a limit controlled by