Summary: Deploy Dullahan and enable Paladin to collect fees
Context:
Paladin’s initial venture was a vote marketplace for governance tokens like stkAAVE. Its auto-compounding capabilities enabled it to attract over 60,000 stkAave in 2022.
Capitalizing on Aave’s new tokenomics enabled by the launch of GHO, we have reworked our vault to create Dullahan.
Vote lending will be ceased on Dullahan as its sole aim is to promote the adoption of GHO while also incentivizing stkAAVE participation via a representative system. The governance power in Dullahan will instead be managed by an appointed delegate from the Paladin ecosystem. Their goal will be to advocate for Dullahan depositors, AAVE and Paladin. See PGM-36 for more info.
Rationale:
Paladin has built a brand with the Aave community, an expertise around the AAVE token and has a specific vision for Dullahan: building the prime venue for non-AAVE holders to borrow GHO while enabling stkAAVE holders to maximize their potential yield.This is possible because Dullahan can allow GHO borrowers to access discounted minting power from its depositors. Those depositors will be able to enjoy auto-compounding of safety module returns and the passive fees earned from GHO borrowing.
Users can zap into the vault with AAVE, which is immediately staked, or directly with stkAAVE. Borrowers will continue to interact with AAVE V3 market but through a Dullahan interface that manages their borrowed discount rate.
Dullahan’s audit has been sponsored by AAVE Grants.
The Paladin protocol will be earning stkAAVE and GHO as fees starting from the moment Dullahan is deployed.
Means:
Deploying the smart contracts and directing revenue streams to Paladin Treasury Contracts;
Technical implementation:
The Dullahan system is composed of 3 main components:
The Vault, holding the stkAAVE and claiming rewards from the Aave Safety Module to stake in more stkAAVE. When depositing in the Vault, the user will receive dstkAAVE token, which is a rebasing token representing the share of the user in the Vault in a way that 1 dstkAAVE is always equal 1 stkAAVE.
The Staking contract, where dstkAAVE can be staked to receive the rewards from renting stkAAVE for GHO discount (rewards are in GHO). Users that chose not to stake (to LP in a pool for example) will forfeit those rewards to other stakers.
The Pod Manager, handling the main logic allowing users to create Pods (contract interfacing Aave V3 to supply and borrow GHO) and pull stkAAVE from the Vault into Pods to apply the discount on GHO interest rate. Renting fees are applied to Pod based on the amount of stkAAVE rented, and those renting fees are only payable using GHO (fees are always paid before the debt is repaid in Pods). Pods also handle logic allowing the held stkAAVE to claim the Safety Module rewards and stake them into more stkAAVE.
Looking forward to seeing the results of Dullahan being deployed. With Dullahan we will be meeting an essential need for compounded safety module returns, hand in hand with fees generated from GHO borrowing.
Love the fact that the dstkAAVE token becomes a rebasing token, with a 1 to 1 ratio :
This could greatly simplify the set up of a efficient AAVE / dstkAAVE pool, with a controlled deviation from actual value, compared to the AAVE / palstkAAVE pool.
Like a Uni v3 (v4?) pool with a custom assets ratio, managed by Arrakis or equivalent. Wdyt ?
Thanks for putting this proposal, quite hyped about this release, it was teased for a long time ! Hopefully it should be good in a few weeks max
Can you confirm that SM rewards are still accumulated by LPs ?
Also, doesn’t feels right to prevent LPs to earn fees from the new Dullahan feature, maybe there is a way to create an proof of deposit when staking in the reward contact, which would be the one deposited in LPs (for example “StkdStkAAVE”) so that LPs could also claim rewards from the staking contract ?
Agree, it can make sense to also consider Maverick for this type of pool, however if there is a way to wrap dstkAAVE in the reward contract, I don’t think this one would be rebasing too, so we’d have the same issue for LPs.
On the subject of dstkAAVE :
Yes the rebasing token was chosen so 1 dstkAAVE always equals 1 stkAAVE (and so 1 AVVE as long as there is no slashing). This would allow pools on some DEX where the rebasing factor will allow for easy exit for holders into AAVE.
But on some other DEX, such as Balancer, that does not handle well rebasing tokens (take stETH for example), this would require some light wrapper to be integrated in a pool (same logic as wstETH).
On the subject of Staking :
The design choice of not streaming GHO rewards to dstkAAVE directly was mainly to prevent those rewards to be lost when a holder would deposit the dstkAAVE in a Pool, because the AAVE rewards are re-staked easily, but in the case of GHO it would have been accruing to the address holding, so in that case to the Pool contract, which would mean the rewards would be lost, as the pool would not be able to claim it. Instead, the idea is if there is a need, some type of Boosted Pool that stake the dstkAAVe while not used would be a better alternative to consider further down the line.
The current Staker design does not issue shares when staking, as this system is not aimed to be used as an LP token, but rather integrated in other product as a yield source. If there is a need for such share, a wrapper around the contract could be later deployed (imagine it the same way Convex did for staked cvxCRV lately). But in the same logic as dstkAAVE, keep in mind that such share token deposited in a Pool not able to claim the rewards will accrue it instead of the user LPing, and effectively lose the rewards.
The solution seems similar to what I described above no ? Creating a wrapper thatt is not 1:1 for LPs.
There is clearly a need for this from the start imo, I get that a migration could be done later, but why deploy a contrat not issuing shares when it’s clearly not what the community think is best, and do a migration later, instead of implementing this change before deploying and while GHO is still not live ?
I don’t understand why rewards would not be claimable with a wrapper/underlying receipt token. The dstkAAVE would remain staked on the rewards contract, allowing to claim the yield from Dullahan, and the receipt token like “StkdstkAAVE” or “PaldstkAAVE” would not be 1:1 and could be deposited in LPs
Please read this before including everyone in your opinion. At some point we have to decide if we want a wrapper compatible with an LP strategy or if we want a composable wrapper that farms (but won’t be able to be used efficiently as LP)
Yes, and as I said, it’s the only choice for LPing.
The reason there is no share emitted when staking is to prevent from a situation where users think this share can be used as any token and start LPing with it, and lose their yield by doing so.
Because the way rewards work in the Staking module, they are accrued by the address depositing. If there is a share token, it would accrue for the address holding them instead. So if you LP with your share, the pool contract will accrue rewards from all the LPing users, with no way for them to retrieve it.
And before anyone asks, no there is not another logic possible to accrue rewards to address that would not be gamed or potentially exploited.
We think it’s best for now to do without the shares for the Staking module, so only dstkAAVE and a possible wdstkAAVE are used to LP, and when the way the protocol works is clear for amm users and won’t lead to situation were they lose their rewards, we can (if necessary) see for a share token for the Staking module.
After some discussions with Koga to understand the issue, it seems the blocker comes from the Staking Module design and the way Dullahan protocol fees are distributed if got it right.
Considering that Dullahan is already coded & audited, and since the contracts are not upgradable, I guess the only way to change that would be a V2 deployment ?
In the meantime, can we explore this possibility ? How would be managed the rewards in this scenario ? Also why not prepare it for the launch if technically possible ?
Well, I think that the proposed setup is great.
I just wish Mangrove could be deployed on Mainnet !
Imagine : no more need for LPing in traditional AMMs, just programmable liquidity, perfect for this kind of situation.
dStkAAVE would be liquidity to be swap at a 1:1 price AND could be staked while unused.
No more need for pool management or arbitrage, which would be great for the end user and the protocol.
Just like Koga said. Maybe some solution will appear in the near future, who knows.
This is actually doable with a Balancer Boosted Pool
At the moment there is no v2 planned, but if someone wants to upgrade the protocol, they are free to do it. Most of it can be solved with a Boosted Pool and better liquidity management strategies, so we (Mithras Labs) would rather leave these choices and opportunities to other community members.
It is being worked on, can’t tell if it will be ready for launch.
