Welcome to SAKE FINANCE 
1 Like
Thank you for the information. Each detail is quite interesting. I would like to ask further about the current market conditions. It’s understood that liquidity in the crypto market has been decreasing compared to before. What opportunities or challenges does the team see in this regard? This might impact the project to some extent. =)
1 Like
Do you mind sharing some more economical data on protocol level?
Attached you can see the income statement i gathered from defillama. Is this data correct or do you have different internal numbers?
Granted these numbers are correct or at least have a low deviation, it becomes quite obvious that this state is not securing a selfsustaining protocol. Given revenenue usually != earnings. Whats the fixcosts you are facing to operate on a monthly basis, if you dont mind share this data?
Regarding TGE i defnitely share that the lack of informations you provided and clear path forward is slightly unsatisfying, but i also share your take of releasing another gov token wont help for the better. So i am excited to hear more about that as i think there are quite some things you can do to make the token useful and learn from mistakes the likes of $UNI for example did.
This changes nothing regarding my support for the protocol. Its just some questions that came to my mind. As i truely think you did a lot of things right, especially given the recent hack that also affected you in various ways.
1 Like
Good question
This (liquidity in the crypto market) might impact the project to some extent. =)
Quite the understatement.
The top opportunity that the team has been pushing on is the looping of LSTs and other yield bearing assets against their non yield bearing counterparts. This is a relatively low risk strategy that can be used easily to multiply the yield earned.
We’ve seen traction in a number of pairs
- SolvBTCJUP-SolvBTC
- xSolvBTC-SolvBTC
- wstASTR-ASTR
- nsASTR-ASTR (pre exploit)
- sSuperUSD-USDC
Notably lacking is ETH correlated pairs. We listed pufETH a while ago but have yet to see any significant traction on Soneium. wstETH didn’t have early traction but has has recently gained some momentum and could be a good candidate for this, possibly yaySTONE. More to be explored in this area.
One challenge that we face is in the issue of dex liquidity on Soneium. While many of the pools are sufficiently deep, we see that the top 10 deepest pools and 14 of the top 20 deepest pools are between correlated pairs.
Source https://dexscreener.com/soneium?rankBy=liquidity&order=desc
The problem with this is that dex liquidity impacts the ability of liquidators to effectively liquidate unhealthy positions, and correlated pairs are rarely liquidated in lending protocols. It’s the uncorrelated pairs that need to be liquidated during periods of high market volatility.
One positive note is that liquidation is permissionless and we have seen a number of third parties run liquidator bots, even beating our own in-house liquidator bot on many occasions. This is a net positive for the protocol as it helps to maintain its health. These other liquidators may be able to tap into other sources of liquidity, either their own funds or routes that we haven’t picked up on.
We could improve on this situation by swapping in pools on other chains, though at the moment this requires some additional engineering, upfront capital, and timing risk. Superchain interop will be a huge unlock in this regard, the theory being it allows for multichain atomic transactions such as liquidate on one chain and swap on another. Alas, we’re still waiting on this upgrade, so we’ll have to work with what we have.
Hope this answers your questions
3 Likes
Hi @PolkaWarrior,
Do you mind sharing some more economical data on protocol level?
Those numbers from defillama are correct for the most part. Minor note, revenue is collected in multiple tokens, which I believe defillama converts to USD at the given timestamp, though the relative value of our holdings fluxuates over time.
With that in mind, the analysis is still the same: the Sake protocol does not generate enough revenue to pay the salaries of a team of 8. We are looking into ways to boost these numbers, but to do so in a fair way and not gouge our users.
Luckily our infra costs are low and we have funding so we’ll continue building and operating for the foreseeable future. One goal is to make the protocol self-sustaining so we won’t need any more funding, though as the numbers show it will take some effort to get there.
Regarding TGE
That’s fair. There is demand from the community for a token, and we should put more time and thought into TGE. The team has been focused on building things that we believe are more value-adding than a token could be, but the power of a token can go a long way.
Do you have any tokens or token models that you particularly like or dislike? Free to discuss either here or in DMs.
my support for the protocol
3 Likes
Great breakdown, thanks for the clarity, Hysenberg. The yield loop with wstASTR-ASTR sounds especially promising.
Quick question → has the team considered dynamic rate models that adjust automatically with utilization changes, to smooth out sudden shifts in APY without manual reconfiguration?
2 Likes
Has the team considered other interest rate models? Yes.
Dynamic/stateful models? No.
The current codebase was designed for simple piecewise linear functions like this one here
The models we know work have one kink two segments. Switching to a similar model with a different kink/slopes can be done.
We’ve also discussed switching to a two kink three segment model. An example model would have a sharp increase at the beginning to (1% utilization, 5% borrow rate), a long flat plateau to (90% utilization, 10% borrow rate), then copy the same sharp increase to (100% utilization, 64% borrow rate).
The plateau region would serve a similar function
smooth out sudden shifts in APY without manual reconfiguration
in that even a large dx (supply/borrow/withdraw/repay) would still have a low dy on the borrow rate.
I believe a model like this would be more fair for everyone involved. With the current model at low utilizations there is negligible borrow rates, so early borrowers get exceptionally high APYs for looping and suppliers get very little. With this proposed model borrowers have to pay a reasonable rate even early on, still much lower than the wstASTR yield but ASTR suppliers aren’t left with nothing.
We’ve been in a bit of a supply/demand equilibrium recently and I haven’t heard any complaints so I don’t think the model needs changing at the moment, but this proposed model would make that equilibrium region wider and shallower, reducing the need for users to monitor their positions.
Whether or not we can support these different irm styles (two kink or dynamic) will take some more research and analysis. If we decide to make these changes they’ll be tested on our Minato deployment before we push it to Soneium mainnet.
Another issue at play here is the changes to the ASTR tokenomics. I’m not fully up to date with the discussion, but from what I can tell we should expect lower emissions at some point in the future. If this affects the wstASTR yield, we should flatten the irm to compensate. We’ll discuss this with our partners when the time comes.
Maybe a bit long winded but I hope that answers your question
3 Likes
Thank you for the details. The various details are quite interesting. I would like to ask about LST in the worst-case scenario where it loses its peg or cannot maintain its value. Does the team have any contingency plans for this situation?
1 Like
Thank you for the explanation, it’s much clearer now. Wishing you good luck, and looking forward to the next update.
1 Like
There are a number of safety controls we can apply should a negative event happen on any of the tokens in our pools.
- Pause the pool entirely, disabling any user actions
- Pause a reserve, disabling any actions on that asset in the pool
- Freeze a reserve, disabling any new supplies or borrows on that asset but allowing withdrawals, repayments, and liquidations
Along with some general purpose configuration options that can be used in conjunction during the recovery process
- Update the price feed
- Update the interest rate model
And in an extreme case, the pool is an upgradeable proxy and we can modify the implementation.
A number of these controls were showcased during the nsASTR exploit, which also highlighted the teams speed and ability to react.
So yes we have steps in place in order to minimize damage on the protocol and its users in case of an event like the ones you mentioned. We also have a general guideline of recovery plans although the details will vary case by case
5 Likes
That’s reassuring to hear. It sounds like there are multiple layers of safety mechanisms. Regarding the nsASTR exploit you mentioned, how quickly was the team able to respond? And which step proved most effective in that situation?
1 Like
One of our team members noticed suspicious behavior in the nsASTR dex pools soon after the start of the exploit. Within minutes the war room was assembled and the Astar pool was paused (the one containing nsASTR). We also paused the ASTR reserve in the main pool out of abundance of caution, though we unpaused it after the attack ended and we realized it wasn’t in danger.
It’s worth mentioning that we asked Neemo about the situation as soon as we discovered it, and in prioritizing user safety these actions were taken before we received a response. I can’t fault them on this point, they were busy in their own war room and likely received a hundred similar messages.
We chose to pause the entire Astar pool because that was the most surefire way to stop any damage. We chose to keep the pool paused following advice from Neemo regarding their original proposed recovery method. They eventually went away from this method, citing technical difficulty and uncertainty of the calculations. Ultimately this decision was good for us as we were able to recover the pool.
Regretably there was a long duration between the attack and the recovery by Neemo due to the uncertainty of the recovery method and the delays in their governance processes. This left us and the rest of the ecosystem in a holding pattern. If we knew from the get go what the final result would be, we would’ve unpaused the Astar pool sooner and left just the nsASTR reserve paused.
When the Neemo claim contract was ready, we
- Upgraded the pool implementation in order to zero out the interest accrued since the pause. This was done out of fairness for everyone involved. We then reverted to a previous implementation
- Created and set a new nsASTR-ASTR price feed to reflect the price cut following the exploit and partial recovery
- Temporarily set the interest rates to zero while users figured out the situation, then reenabled them a week later
- Unpaused the Astar pool but froze the nsASTR reserve. This allowed nsASTR to be repaid and withdrawn but not supplied or borrowed, while also allowing the rest of the pool to resume normal operation
- Provided a contract and interface for our users to easily withdraw from their positions and claim ASTR
TLDR the response was quick and Sake suffered no losses from the exploiter. We used every trick mentioned in the previous post, plus some creativity during recovery
6 Likes
Minutes to respond and pause is solid. Good call on zeroing out interest during the pause — that’s fair. Sounds like freezing nsASTR reserve while unpausing the rest was key to the recovery?
1 Like
Sounds like freezing nsASTR reserve while unpausing the rest was key to the recovery?
Yes, above all else that was key to the recovery
Thanks for the detailed breakdown. It’s good to see the quick pause and risk-containment steps, but the long recovery period and coordination delays clearly created uncertainty for everyone. Documenting these lessons for a more streamlined cross-protocol response next time would be helpful.
Sake is one of the projects I enjoy using.
In response to what you wrote, “Are there any tokens or token models you particularly like or dislike? Feel free to discuss them here or via DM.”
I can tell you that there are some DeFi projects I believe should definitely be role models if they plan to organize a TGE in the future. Three projects that are particularly successful in terms of tokens:
1-) Ekubo
2-) Jupiter
3-) Aave
Ekubo is a great, liquidity-focused project that emerged from the Starknet ecosystem and is supported by Uniswap. I believe it’s a small-scale project worth looking at for tokenomics, price movements, etc.
Jupiter, as you know, is Solana’s largest DeFi project, but its success isn’t just that—it’s the constantly updated new features, mobile apps, etc., and the $JUP token integrations in every product they develop. For this reason, definitely take a look at Jupiter too.
Finally, Aave—I assume you’re already familiar with this token 
I think it’s worth observing their token issuance rates, the successes they achieve, and the mistakes they make along the way to gain experience.
