- Lucas discusses the MakerDAO conduits, which are part of the MakerDAO allocation system.
- Conduits allow different sub DAOs to mint DAI and allocate them to different strategies.
- The first conduit discussed is for deploying funds into SparkLend.
- The second conduit discussed is for deploying funds into RWAs (Real World Assets).
- The conduits are designed to encourage the community to come up with different ideas and strategies for deploying DAI and earning a safe yield in DeFi.
- The SparkLend conduit involves an operator calling the deposit function to supply DAI into Spark, which mints A-tokens held within the conduit.
- The conduit uses a data structure to track shares for each asset mapped to each sub DAO.
- The RWA conduit and its functions are briefly mentioned.
- Lucas mentions that the conduit code does not have to adhere to MakerDAO terminology and aims to be approachable for new developers.

- The video discusses two types of conduits: SparkLend and RWA.
- The SparkLend conduit allows for the withdrawal of a maximum amount of funds, taking into account available liquidity and specified limits.
- The RWA conduit deals with real-world asset implementation and involves a trusted arranger who pulls funds from the conduit and deploys them into a yield-bearing strategy.
- The goal is to simplify the process for arrangers and meet the needs of sub-DAOs.
- The video also mentions the implementation of a safe ERC20 library and an upgradable proxy by the speaker's team.

- The code is contained within sections and allows for easy navigation.
- The data structure is more sophisticated than Sparklines, with different categories such as deposits, requested funds, withdrawable funds, and withdrawals.
- Deposits are continuously increasing values, while requested funds increase when a request is made and decrease when fulfilled.
- Withdrawable funds increase when funds are returned and decrease when withdrawn.
- The available funds are calculated based on the aggregate balance minus total withdrawal funds.
- There is a broker allow list to ensure valid destinations for funds.
- Transfers do not update state as it is difficult to determine which funds belong to which subDAO.
- The focus is on the subDAO's deposits, requests, and withdrawals for financial calculations.
- Funds can be requested with additional information conveyed through a string.
- Fund requests can be canceled if necessary.
- Funds can be returned, with state changes reflecting the balance update.
- The system allows for flexibility in returning less or more than requested funds.
- Returning more than requested can account for accrued yield since the request was made.

- The speaker discusses the process of depositing, withdrawing, and requesting funds in a smart contract.
- They mention the importance of understanding these processes before discussing tests and variances.
- They also mention a file pattern used in the Maker approach for setting values.
- The speaker emphasizes the importance of boundary condition testing and aligning assertions in tests.
- They mention their preference for clean and easy-to-understand tests to identify issues easily.
- Finally, they discuss the concept of invariance and how it applies to the smart contract's handler design.

- The video discusses the use of invariants in a smart contract system.
- Invariants are useful for revealing incorrect assumptions and ensuring the system operates as intended.
- The video explains a pattern for randomly selecting assets, brokers, and ilks in the system.
- The presenter suggests combining invariants into one function to improve efficiency.
- Several example invariants are discussed, including checking balances, tracking funds, and verifying inflows and outflows.
- The presenter emphasizes the importance of redundancy in creating invariants.
- Bounded invariants are mentioned, which are designed to prevent reverts in the system.

- The speaker recommends using bounded and unbounded invariants to ensure successful calls and avoid unexpected reverts in smart contracts.
- Bounded invariants track and limit the amount of a certain value, while unbounded invariants allow for unlimited amounts.
- Running both bounded and unbounded invariants in testing can reveal potential errors and violations of invariants.
- The speaker suggests creating a general variance function in unit tests to assert invariants at each step of the development cycle.
- The speaker's repositories have undergone multiple audits and the next steps include integration testing and further hardening of the contracts.
- The speaker can be reached on Twitter (@LucasManual_ETH) and GitHub (Lucas-manual).

- Lucas discusses MakerDAO conduits, which are part of the allocation system.
- Conduits allow sub DAOs to mint DAI and allocate them to different strategies.
- The SparkLend and RWA conduits are discussed, with details on their functions and operations.
- The code is designed to be approachable for new developers and includes features like a safe ERC20 library and upgradable proxy.
- The data structure of the conduits is explained, including categories like deposits, requested funds, and withdrawable funds.
- The process of depositing, withdrawing, and requesting funds is described.
- The importance of understanding these processes and conducting tests is emphasized.
- Invariants are discussed as a tool for ensuring the system operates as intended and revealing incorrect assumptions.
- Bounded and unbounded invariants are explained, along with their role in preventing reverts and tracking values.
- The importance of redundancy in creating invariants is highlighted.
- The next steps for the project include integration testing and further contract hardening.

MakerDAO Endgame - Lucas Manuel: https://www.youtube.com/watch?v=82XgM8RsUeA
github: https://github.com/makerdao/dss-conduits
lucas manuel: https://twitter.com/lucasmanuel_eth

Okay, welcome to the bytecode where we look at small contracts with the people who wrote them.

I'm Hirosh Shafu and today's episode is with Lucas who's going to walk us through the MakerDAO conduits.

Yeah, so yeah, today I'm going to walk us through 2 different conduits, which are part of the MakerDAO allocation system, which will be part of endgame.

I guess I can give you maybe like a link that you can put in the notes later, but I gave a presentation about what MakerDAO Endgame is and all the different components.

This is gonna be definitely way more technical, but that gives a good broad overview of what the allocation system will do and why we're doing this.

But at a high level, just to give like an intro of what a conduit is, essentially what Maker is gonna be moving towards in the future is having different sub DAOs have permissions to mint DAI and allocate them to different strategies.

So this can be lending DAI into Spark so that we get decentralized collateral backing DAI, deploying into Coinbase custody to earn some yield with high liquidity or deploying into RWAs.

We want to expand the offerings as much as possible.

And this is what's exciting about Conduits, actually, that we're trying to introduce a lot more in hackathons is we want to encourage the community to come up with different ideas for conduits, different strategies for maker to deploy die and earn a safe, steady, scalable yield in DeFi.

So I'm going to go over 2 different conduits today that we have been working on.

The first is going to be a conduit to deploy funds into SparkLend.

And the second is going to be the RWA conduit.

So SparkLend conduit, essentially how it works is you have an operator that calls deposit.

So this is someone acting on behalf of the subdao.

And we have 2 central sort of registries and maker that do lookups for ACL and for the appropriate buffer.

What a buffer is, is basically it's just like a pot that holds die on behalf of a sub-DAO.

The important thing though is that we pull die from the buffer into the conduit, supply that into Spark.

Spark will then mint A-tokens and those will be held within the conduit.

So you can think of a conduit as essentially like a position manager for multiple sub DAOs to deploy funds into Spark.

So if I look at this, we look at the data structure here.

You have shares that are being tracked for each asset mapped to each ilk, which is the subDAO identifier that Maker uses to the amount of shares that subDAO owns within the conduit.

Because the thing is, the conduit's gonna be holding an aggregated balance of a tokens for multiple assets, for multiple sub does.

So what this storage setup is doing is breaking that down so that we're tracking each sub does individual balance.

And so you can see here you have shares and total shares, which is like very analogous to balance of and total supply in ERC-20, same idea, right?

Yeah, this is the aggregate amount of shares for a given asset.

Because the idea is this is built to deploy a DAI, but we also want to be able to support potentially, you know, USDC or different stable coins, different, We want to make this generic to support as many assets as we can.

So this ilk off modifier calls out to the roles contract.

This is a very generic, highly configurable, centralized, you know, central contract that basically says like, can this sub DAO call this contract with this signature?

Maker is famous for using weird terminology.

So yeah, all it is is a bytes 32 identifier for us.

You'll notice though that this conduit, and this is something that we want to kind of make known as like conduits don't have to adhere to the maker terminology in the code.

So we don't want that to be a barrier of entry for new participants, new developers.

Like I'm using pretty plain language in my deposit function.

So we want this to be very, very approachable

for new developers, because I know that the

maker terminology can be something to learn.

So, but yeah, I'm going to go over this relatively quickly.

Cause I want to get into the, The DSS conduits as well, but essentially what this is doing, right.

We have a sub Dow identifier and asset and an amount.

We make sure that the sender is allowed to call this function on behalf of the sub DAO.

We make sure that the assets been enabled by governance.

And then we do a lookup to get the buffer for this ilk.

And then we convert the amount to shares.

And you can see here, we're kind of using 4626 terminology.

It's an internal function, but to be, to make it feel familiar, cause it's doing the same thing as what 4626 is doing essentially, converting the amount into shares using Spark's normalized income, which is essentially the, you know, exchange rate, effective exchange rate for converting between assets and shares.

So you're doing a rate of here, taking the amount, dividing by the exchange rate, and then you get the amount of shares.

So since we're doing this atomically, we know that this will equal the amount that we're, and this has been highly tested, but the amount that we're gonna receive as the balance of the scale, I should say, sorry, the scale balance of A tokens.

Because the A tokens are continuously scaling.

So the balance of returns, the amount that's continuously accruing, but the scale balance of is the constant underlying shares.

This is, this basically A4626 with the difference.

The main difference that I see is you using ILK instead of message.sender, right?

Well, from an interface, yeah, essentially.

Because it is fulfilling the same purpose as a 4626, really.

It's like with additional logic, it's basically saying like, okay, we need to deposit some funds and we need to track value accrual.

Yeah, like we have getTotalDeposits and getDeposits, which are essentially convert to assets.

But it's not exactly the same, but yeah, it's a good, good call out.

So yeah, we take the shares for the asset and the elk.

We add new shares, same with total shares.

So just tracking that state as we deposit.

And then we're transferring the, asset from the source into this contract, the amount.

So we're taking, for example, die out of the buffer, pulling it into this contract.

And then we're immediately turning around and supplying that into Spark.

And then we receive the tokens, after that's done.

So the maxWithdraw function, whoops, is, sorry, maxWithdraw is returning the minimum between an ilk's underlying assets for a given asset.

So it's converting the shares, all of the shares that a given ILK has for a given asset into the like underlying value.

And then it's also taking the available liquidity in SparkLend and taking the minimum of those 2 values.

So the minimum of those 2 values is the maximum amount that can be withdrawn by a given ilk for a given asset.

So you're taking, and these are 2 standard functions by the way, for conduits.

You got max deposit and max withdraw so yeah you're getting the amount and then you're saying okay oh and sorry you're taking the minimum between the max withdraw and the max amount specified so you're saying for this ill for this asset this is the maximum amount that I want to withdraw.

It might be less than that, but this is like the max that I want because it might get constrained and we return the constrained amount here.

So this function essentially tries to withdraw, you know, as much as you can up to the specified amount.

So you get the amount and then you say, okay, what are my shares?

And you're taking the minimum between the shares of that asset for that ilk or the rounded shares for the amount.

You were rounding up to be conservative here, And then you're reducing the shares in the state by this withdrawal shares.

And this is important because it's important to round up here because we want to be conservative when we're dealing with our own state to make sure that, yeah, there's no bad rounding essentially.

And then, yeah, we're getting our destination to send the funds back to.

So you can see it's basically the reverse in this situation where we're calling withdraw from the pool, we're burning the 8 tokens that were held in the conduit, and then we're getting the underlying asset back and then we're transferring that to the buffer.

So that is like in a nutshell how conduits that atomically deploy funds into deep, any basically any conduit that deals with like direct DeFi protocols will be able to do this atomic deposit and withdraw where they're deploying into like some yield bearing on chain strategy and then withdrawing from it.

I'll just do a quick little plug as well for, we made our own safe ERC20 implementation.

ERC20 helpers is this little repo that we made that just has like 3 things, like a mock ERC 20, like a mintable ERC 20, the ERC 20 interface, and the safe ERC 20 library, which is just like a very minimal implementation of the safe ERC20 library.

So yeah, if people are curious to check this out, that's in our GitHub.

Any specific reason why you guys re-implemented that?

I just don't like importing, personally, I just don't like importing external dependencies that are bloated for what we need and just have like a lot of code.

Like this is implemented in like 70 lines.

It's like very tight and like concentrated to what we want to do.

So, yeah, as long as it's not too complex or...we always have a discussion of whether or not it's worth doing But that's something that I believe in is like, you know, making the minimal possible implementation.

We also implemented our own upgradable proxy, which is like, you know, you can see here it's like very small.

And it has the maker standard rely-deny syntax for tracking off.

I hear that more often recently about external dependencies and it's kind of a tradeoff because obviously when you write your own code you need to re-audit that and stuff like that.

Well, it's, like I was saying earlier, like it's, it's, it's a, it's a decision, right?

Because we did audit these, both of these.

But it was, it was easy to audit because it was so small.

Like I said, we can just throw another 70 line contract in this audit.

I'm going to move on to the RWA Conduit, unless you have any other questions.

So, this is a similar kind of contract in the way that it adheres to the same standard interface of a conduit.

But it's a little more sophisticated because this conduit is dealing with real-world asset implementation.

So, Maker has a pretty large real-world asset deployment currently.

So, what we're aiming to do is to move all of those real-world asset deployments to use this structure.

Because by using smart contracts to track all these positions, all these fund requests and all these returns, which I'll get into more later, it really improves the visibility of all of these funds moving and just adds a lot more rich, like on chain data for dashboards and this kind of stuff.

So this is the initial implementation of this, As different use cases come up, as things get more solidified over time, we're going to continuously iterate and improve on these things.

This is what's called the arranger conduit.

It's called the arranger conduit because using the arranger model that maker uses for RWAs.

And so the major difference between this and the SparkLem conduit is that you have funds getting deposited and held in the conduit.

And the arranger, who is a trusted actor that is working on behalf of Maker to deploy funds into treasuries or whatever it might be, will pull the funds and deploy them.

Instead of an atomic deposit and immediately earn yield, you're depositing.

And then the arranger can come in and see this aggregated pool of funds that multiple sub does have deposited, pull that out and, and deploy it into a yield bearing strategy.

So the goals of this are to be maximally simple for arrangers, because all that they want to do is come in and pull in deploy funds.

And also, you know, fill fulfill all the needs of all the sub-DAOs.

Okay so the arranger is some sort of trusted third entity that acts on behalf of the of maker basically?

Yes yeah there's like you know very hardened legal agreements and structures that are put in place that ensure that these entities are, you know, behaving as expected.

And yeah, that's, that's essentially the model is that they're they're pulling the funds and deploying them.

So by the way, just this is something that us solidity nerds Twitter battle over sometimes is section labels.

going to take this moment to show my my style of section labels.

I've been through like 5 different iterations of section labels and I do think that this is the 1 for me, I love.

So, cause people try to center them sometimes and they're always like slightly off center I find.

Or they don't have a constant length and they're centered.

of, well not final, but the latest is this version.

So essentially you can see here I have a line guide and it's at 100 characters.

And so these are all constant lengths and they're left justified.

So they're always, you know, they never look out of place.

And you'll see, right, they act as like a little box.

So everything within a section is contained, like nothing goes past the line of the section label.

You can see here all of the code is contained within the length of the section label.

I just find it really nice to be able to navigate code.

So yeah, this, the data structure here you can see is similar, but more sophisticated than the Sparklines.

So you got deposits, requested funds, withdrawable funds, and withdrawals.

So deposits is a continuously increasing value that's saying like what are the aggregate cumulative deposits for a given ilk for a given asset or sorry this is the this is the total version this is the balance of version so I'm just gonna go over each 1 because now you know the balance of total supply analogy here.

So you got the total deposits continuously occurring.

You've got the requested funds, which is I'll go into in more detail, but essentially, In order for a sub now to get funds back from the arranger, they have to request.

Funds on chain so that the arranger knows, okay, they need $10 million.

So this is the total requested funds that increases when they request and decreases when that request is fulfilled.

So this increases when the funds are returned and then decreases when they're withdrawn.

So when funds are returned for a subdebt after they request, they're withdrawable, and then they withdraw them, that goes down.

And then this is total withdrawals, which is similar to total deposits, just a continuously increasing cumulative withdrawal amount.

So deposit is pretty, you know, similar and to the, to the last condo.

So you got your deposits, you're looking up your buffer, and then you're pulling funds into the contract for the buffer.

Just pulling die, for example, into the conduit and holding it there and tracking the individual sub does position amongst the aggregate balance of die.

And then you've got, I'll just go in kind of the order of operations for these actually.

So then you got draw funds, which is the arranger is coming in and saying, okay, I want to take this amount or sorry, this asset, I want to send it to this destination.

So I'm going to make sure that the amount is less than the available funds.

So the available funds here is the aggregate balance of that asset minus the total withdrawal funds for that asset, because you have encumbered, you have an encumbered portion of the balance that's earmarked for withdrawals for a sub-dow.

So if you have $10 million of a balance, but you have $2 million that you've returned for a given sub doubt to withdraw.

You can't withdraw 10 million cause you're, you're dipping into the withdrawable funds of that sub doubt.

So that's what available funds is doing here is it's making sure that the arranger can only deploy the funds that they should be able to deploy essentially.

So that's really important and then yeah we have a broker allow list for the destination and the asset we just make sure that they're a valid destination to send these phones to.

And you'll notice here that there is no state that gets updated when this happens.

And the reason for that, we kind of tried to figure this out, but the reason that you can't really decrement a given subdao's deposits is because this is drawing on the aggregated balance of the whole conduit.

So you don't actually know per se which funds belong to who, unless you wanted to do a more elaborate data scheme, but we figured that it wasn't actually necessary to do that.

Like you could loop through and do some, something like that, but it wasn't actually needed in the end.

So that's why there's no state updates here.

It's, it's pulled in and you don't have the information which amount belongs to which subDAO or something.

Yeah, but you do have the information of like the relevant information, which is like the subDAO's deposits that they've put in And then the amount that they've like, what we actually care about at the end of the day is how much a sub dows put in, how much they've requested and how much they've been able to withdraw.

And then from that, we can do all of the financial calculations that we need.

Again, we want to move towards more like, you know, on-chain RWA strategies, so we can have even richer data sets.

But this is the, this is where we're starting with.

And yeah, this, this allows for maximum flexibility for all RWA implementations currently.

So you draw the funds and then the next step is you request the funds.

So fund request, you push to the fund request array.

And it's essentially just this struct that says, I've requested this amount.

And this is an arbitrary string for the info that you can pass along, which is like essentially predefined, information that you can convey to an arranger as a sub Dow, according to like legal agreements that you can say.

Like who knows, maybe you want to liquidate 10 million dollars, but you have a pretty relaxed time preference.

So you you're okay if it takes like 2 days for example, or because you want to maximize the yield or you have like a very you know quick time preference where you need the funds right now and so you you would request that and you would get some slippage probably because you have to liquidate very fast, but that's okay.

So you can convey this very arbitrary, flexible information through this string.

So this is all emitted on chain so that the arranger has all the information they need.

If you're a subDAO that, you know, didn't want to actually go through with that fund request, you can remove it.

And then here is the next 1, which is you can return the funds.

This is a quick thing I'll just go over is like, the funds are going to be sent from a different location than the arranger is going to be calling the funds from, so we're using a push pattern here.

So, funds will be sent into the contract and then return funds is called to change the state to correspond to the balance update.

So, for a brief period of time, available funds increases, but then it decreases because the withdrawal funds increases to catch up to that amount.

So your withdrawal funds and total withdrawal funds increases, your requested funds and your total requested funds goes down by the amount requested.

This is key because if you request, like, I don't know, if you request a million dollars and you get, 1.2 million, then your requested funds should go down by a million.

And if you get 800,000, it still goes down by a million.

So it's actually the state update for the requested funds, regardless of what happens, is always removed by the full amount of the request, not by the resulting returned funds.

And then the withdrawable funds is increased by the amount that was returned, because that's the amount that's actually available for the sub-DOW to withdraw.

And so, yeah, we wanted to make this maximally flexible to, you know, adhere to any situation that might arise.

So you can return less than was requested or more than was requested as an arranger, depending on the situation.

And we'll just, we'll deal with that data accordingly.

And no matter what, it's a one-to-one return.

So if you return funds, that fund request is like completed and removed, no matter what happens.

Lucas, why would you return more than requested?

If you, you know, if there was yield that has accrued since the request was made, it's like a quick example.

There's different situations that could happen, but that's like 1 of them.

And yeah, that's just what we wanted to be able to handle.

And then the last thing is the withdrawal.

And so the withdrawal, pretty straightforward.

You're reducing, you're adding to the withdrawals, the cumulative withdrawals, and then you are sending the funds to the buffer.

So that's like a complete cycle of depositing, drawing funds, deploying the yield strategy, requesting funds, getting the funds returned, and then withdrawing.

So this was all a really necessary preamble to the tests cause I want to get into some like variance and stuff like that.

So it was, it's important to understand also just generally but I think it's going to be a lot more meaningful to go over these tests now with this knowledge.

The file pattern I think is interesting on 9.69.

Oh yeah, This is a standard maker approach.

It's, you know, It's essentially like a setter that can just handle setting any value based on the keys.

So you just have 1 file function and all your settables, and then you have it like keyed on what you want to set.

See all shafu transcripts on Youtube

The Bytecode #18 - Lucas Manuel - dss-conduits