Security Ideas and Thoughts on Improving Security Response Time

Feedback, Suggestions & Questions
#1

Any thoughts on electing a Balanced security council or sorts? I’m thinking a 3-4 member council that can operate monitoring bots and make an emergency stop transaction to freeze Balanced smart contracts for 24 hours. To unfreeze contracts, the Balanced DAO would have to vote on the unfreeze transaction. The monitoring systems should also not be open sourced as we wouldn’t want exploiters to know what we’re monitoring for.

As an example, if one member operates bots that monitor the rate of LP withdrawals and detects a sudden huge withdrawal, that member should have the authority to submit a transaction to immediately freeze Balanced. The existing system of notifying a team member to freeze contracts is too slow. Even a Discord notification system is too slow. By the time someone logs on to submit a transaction, 50+ transactions could have already occurred. On a blockchain like ICON with 2s block times, preventative measures should be immediate.

Another thought I had is whether it would make sense to implement max LP withdrawals per day. This might be unappealing to some as can be perceived as “centralized”, but I think it’s a good tradeoff to have especially when considering the team does have the authority to blacklist wallets anyway (this indicates the system is not 100% permission-less). And if it’s not 100% permission-less, I think it’s okay to accept that and implement safety measures. I say this because the Balanced DAO fund is able to cover the cost of this exploit, but this also means if this were to happen again, we wouldn’t have enough money to make users whole.

5 Likes
Balanced exploit post-mortem | June 2023
#2

Hey @bwhli - thanks for posting this and agree with both of these measures. I have been thinking in the same direction.

After the Omm exploit, an emergency shutdown whitelist was created for trusted community members that have the authority to disable Balanced contracts (thank god this was implemented recently!), so some of the development necessary has already been accomplished. The only contract that can’t be disabled is governance, which allows the DAO to remove/add accounts to the whitelist even if one of them becomes compromised.

As a next step, we should get the monitoring system going. I’m already in discussion with Ken as well as Rob from sudoblock about monitoring services and what we should monitor for. I’ll get a private chatroom going where we can add all relevant folks to decide what’s best to monitor for.

To your other point about putting caps on withdrawal amounts, I also think this is a good idea. Let’s do both. My original thought was to set hard limits on the amount of tokens that can be withdrawn, then have the DAO vote to enable more withdraws when approaching the cap, but your suggestion is a bit more flexible. Let’s iron out the specifics on this thread and go from there. Curious what others think as well.

2 Likes
#3

I sympathize with the bwhli opinion, and share my personal thoughts.

  1. When a transaction exceeds a certain amount, the swapped funds are stored in the treasury or DAO wallet for 1 to 3 hours and then transferred to the trader.
    (Usually exchange bitcoin transfer also takes this much time.)

  2. [Prevention of small amounts of repetitive work] When the same work is repeated 3 to 7 times, the work is delayed by 10 minutes, or it is entrusted to a third wallet like No. 1, and the user suffers from a slight delay.

PS.
case 1. It seems that it would be good to apply it to the ICON Bridge as well.

1 Like
#4

Very interesting topic.
Just to shine some light on what we have. After the OMM hack we create a emergency shutoff which gives people access to close down all our contracts. But with a time constraint so it can’t be spammed and abused to much. And as Benny mentioned voting and executing votes are still possible which makes it possible to remove people from the list. There was also a blacklist function implemented which makes it possible to ban a address from interacting with all balanced contracts.
However this list is still quite empty and we for sure want to add competent balanced members to it. Preferably some automatic ones along with monitoring software as u suggest @bwhli

One thing to keep in mind when designing solutions like these they should be on a completely different layer, be very stupid and simple such that the limits should be easily verifiable and does not introduce extra complexity into the main logic. Which could end up making it more unsafe.

While focusing on LP withdrawals now makes sense it is probably not where our next hack will be and we should focus on wider solutions to protect all user funds.

Some example approaches:
1: Per token rate limited withdraws from contracts
We only allow x tokens per day, hour, 10 min (some interval) to be withdrawn from our contracts. Where each contract can have their own limits.
This way we put the security layer in our tokens.
Downside is that it is hard to for example limit the dex since volumes can be quite high at times.

2: Per account rate limits.
For each token a non whitelisted contract/address is only allowed to process a certain amount of volume per time. Otherwise gets a short lock on the assets. Similar to what @SimSul suggests. If a User transfers a to large amount to its wallet it get locked for some time period.
However this would most likely only hurt users and hackers would split into multiple small wallets, only making in slightly more annoying to attack

2 Likes
#5

I like these ideas, what about actually making everyone prove identity for a traceable address to be used on Balanced?

We are in the middle of a mess right now and could be a perfect time to become even more compliant as a DAO. Have this hiccup make us stronger. People can have the option to leave if they are not willing to share their identity.

We need to think about future compliance before trying to reinvent the DAO wheel with novel ideas as this thing could get shut down if authorities require verification and Balanced has no set policy.

People sharing identities before being able to access Balanced would make us much more secure, and we don’t have room for error after this.

Yes, we will lose some people, who for whatever reason won’t share their identity, but we will also gain some from the added trust of an identity secured DAO.

I think many DAO’s that are much larger than use have required ID verification years after being open, Compound on ETH comes to my mind.

#6

Generally speaking, I’m against KYC for Balanced. Which layer are you recommending KYC for – contracts or frontend? To implement proper KYC, it would have to be on the contract level, and this would likely destroy Balanced’s potential as a multi-chain DEX.

Can you share more about how Compound does KYC? I’m fairly certain I’ve used Compound in the past and don’t recall going through any KYC procedures. Do they implement on the frontend or contracts?

1 Like
#7

Yeah, you may be right. I read about the Compound founder mentioning KYC on his Twitter page, and some of his users being upset, maybe it was not implemented for users. I never looked into it.

On another note…

There are new “soft ID” verification like Polygon ID is creating for DAPPS to use on connected applications, where the ID is stored securely with the user but can be verified by DAPPS, Maybe a connection like that is worth while. I’m sure we can connect to the verification somehow. This is worth a hard look for a connection.

https://twitter.com/0xPolygonID

Steps we need to take to gain users back…

We have been the “front line” application, along with OMM, that is subject to a “battlefield” of hackers. The “hackers” have partially won against us and we have to request help for more funding so our DAPPS don’t get totally destroyed, they need help. OMM and Balanced need more, a lot more financial assistance from ICON in the form of grants. We are their “front line” applications and to this point we have been underfunded and easy pickings for these attackers. If ICONs main DAPPs can’t handle security properly, who would trust ICON to connect blockchains. I would be willing to interpret there is immense interchange of employing the same programmers, developers that are creating these new XCALL features… they most likely helped create Balanced and OMM in some way behind the scenes. I interpret “ICON Foundation” to be in the “command center” limiting their risk of attacks and hacks. I also interpret Balanced and OMM are the underfunded front line workers getting destroyed.

I think our first step is to ask for a security grant from ICON to get audited by the same companies as Compound and Binance Smart Chain. We have no trust in FYEO’s ability at this point. We need a legitimate audit to earn trust for the platform and since Balanced is the heartbeat of all of ICON DAPPs it is money well spent.

Here is who compound was audited by…. Why did we not choose one of these companies to begin with?

Options could be TrailofBits, or OpenZellen for an ICON grant funded audit, if we are serious about becoming a legit DAO we need legit audits by the big boys that do them for the top DAO’s.

Talk about being a cross chain DAO is silly at this point, we need to focus on security over the next year, not about leading “dangerous cross chain DAO” missions. We have no armor for these missions, we need to head back to “ICON Headquarters” and get “real assistance” against future hackers.

Brian, I do agree with the options you mentioned as well for security. I just think we need a total security reset, we need to spend months working on safety, there is no need to rush.

I am one of the biggest fans and users of Balanced:). I have nothing but respect for Scott, the Balanced workers, their dedication and work ethic is unbelievable. I think the ICON Foundation has some of the best intentions of any organization in this space in crypto, which is why I trust ICON. My hope is for them to get behind OMM and Balanced in these times, which they are, to an extent, but we need much, much, much more.

Another successful attack on Balanced means all of ICON Sub Token projects are worthless, years of coding to make an incredible cross chain DEX app to showcase ICON’s ability, gone. Users funds will be gone as we have depleted our DAO with this hack.
*** The biggest headache would be this…. All of Balanced users would stampede and cry to the ICON Foundation for years on end if they lost their money due to a breach as OMM and Balanced were airdropped tokens to the community by teams and individuals that are highly, highly connected to ICON. Same workers, programmers, leaders, different DAPP name…. OMM and Balanced. This happened all over the place with mid cap coins as a way to grow projects. They had to do this because we are not big like an ETH. No one would start or invest in OMM or Balanced if they were not not highly interconnected with ICON. *** This was genius thinking by the ICON Foundation by creating OMM and Balanced using most of the same people but in the same time limiting the risk from ICON and $ICX to offer and sell new tokens with new use cases to the community. I bought OMM and Balanced when we were $30 million and $50 million market cap tokens. I know the history I believed in the growth story and still do.

  1. A security grant from ICON seems to be in the best interest of everyone, not just Balanced

  2. A replenishment of the DAO grant should come in second as we have earned that with all the services we provide to everyone in ICON.

Once we have completed steps one and two we can start to consider being on the “front lines” again, we always need to make sure our users are protected before trying to accomplish new technological advances.

In addition to a connection with a Polygon ID type service, wait, wait a second here, couldn’t the ICON Foundation create a DAPP ID service that is encrypted for privacy for use on DAPPS like Polygon ID has done. Remember, ICON was in all of the news making ID services through their blockchain during Covid. Why not create a WEB 3 ID system that can help secure its DAPPS and cross chain efforts.

Also, as a DAO we can limit each ICON address to a trust scores. A high trust score wallet can have a $10k daily withdrawal limit that has been active on Balanced for over a year. Mid level trust score wallets can have a $500 withdrawal limit for newer, limited use. Recently created accounts will have the lowest trust score and a $250 withdrawal limit. Then we also only allow 25 new ICON Balanced addresses per day to limit an attacker to using multiple wallets. We aren’t getting more than that in new users daily so that should not be an issue.

#8

Getting back to tangible next steps related to this discussion, my latest line of thinking is a relatively basic solution.

Implement a Floor in Balanced-related token contracts for holdings of the DEX and Loans. For example, the bnUSD contract could have a floor for the DEX. If a transaction would have the bnUSD holdings of the DEX drop below the floor, it would throw an error something like “Floor has been reached, DAO Vote required”.

This requires more active management by the DAO, but is a great way to protect balances and manually set maximum losses. We can set the floors to be ~60% of the value held by the DEX, meaning the maximum loss at any time would be 40%.

It would be frustrating during major price swings, still open to other ideas, but something that could be implemented on sICX, BALN and bnUSD relatively easily. It’s also something that needs to be actively managed as people trade, supply, withdraw, prices increase/decrease, etc.

@bwhli @Andell curious your thoughts on this.

#9

I agree this is a simple solution that is on a complete other layer than our contract logic which is good.
But another thing we should worry about is silent hacking. It’s not a given that we would have noticed this hack for a long while if the hacker did it very slowly.
But hard limits should be pretty good for this since before we approve the vote we should check if the amount missing is valid.

#10

It seems like the ICX pair is currently giving an error code. The other pairs I tried worked but trading to ICX did not work today, which gives me an idea.

Since hackers normally transfer as much as possible to ICX why don’t we limit transfers in balanced to ICX to two million a day. Meaning hackers would be limited in converting to ICX.

Just a thought.

1 Like
#11

Also, as a Staker, I think now is a good time for 100 percent of the fees to go to our DAO. This obviously will help support the rebuilding effort of our DAO funds and Balanced Stakers are getting enough of an APY from directing their BBALN through Governance:)

Also, it will definitely help the BALN token to not be looked on as a security. There is no reason at all for us Stakers to receive fees with our APY from directing our vote. We need to limit the risk of being viewed as a security and build our DAO back up:)

#12

I’m not sure on others but ideally we want Balanced to be as open as possible. Limiting ICX transactions to 2 million a day would potentially open other issues or just be circumnavigated by multiple wallets.

Ultimately, we are limited by the amount of ICX in the sICX-ICX lp pool / queue.

I am all for the idea of this, building back up our DAO POL would be a priority along with all the cross-chain prep.

As previously mentioned from Scott I believe, Balanced can survive and grow on the fees from sICX/bnUSD pool alone should the pool get big enough.

I imagine that it would also look good to users from other ecosystems if they could easily swap or leverage their network token for ICX without much slippage.

#13

This occurred to me as well in relation to withdrawal limits on out token contracts, the ICX/sICX pool adds sICX to the dex. So a limit on sICX for the dex would not be much of a protection.
But a safer rate limitation on that pool might be an option.

#14

@Andell @benny_options I like the floors for collateral and LP withdrawals, but I would suggest to make the limits dynamic. Let’s say we allow 20% withdrawals, protecting 80% of the value. Instead of the governance vote to decrease the limit when needed, the contracts would have a system in place, ensuring that no more than 20% could be withdrawn every 48 hours or so. This should give us enough time to recognise potential exploits, protecting significant percentage of value locked and alleviate additional governance.

Liquidation risks should have to be accounted for somehow, though. Perhaps disabling liquidation calls when the collateral withdrawal limit is reached or something along those lines.

For the LPs, it might make sense to implement this just for the larger ones. 20% withdrawable liquidity (from the pool total, not per user liquidity) feels like no single user should be prevented from getting all of their funds out of the pool during the standard times.

Also, in addition to what Brian suggested, what do you think about those elected members to be allowed to define emergency votes? Those would be available to vote on for much shorter time. I know it’s not ideal but having a day as the shortest voting period is too slow for emergencies.

1 Like
#15

This has been quite a buzz lately, and is something id want to implement eventually:

But is still in its finalization process. But should achieve similar to what you suggest. And i agree that static limits are not optimal. However, they are simple and the development effort is minimal. But some simple rate limits might also be and option and quite easy to implement.

Not sure about emergency votes, i think it is fine if they are able to shutdown balanced in the event of a hack, and we can take our time to restart. I don’t see and even where a quick vote would help much, especially if everything is frozen.

2 Likes
#16

@Andell the way I’m thinking about this, I feel like it could be negligibly more complicated than a hard-coded floor. We would have a floor variable that simply checks the current holdings of the contract (e.g. sICX held by Loans), then multiplies it by a governance controlled, hard-coded percentage (e.g. 80%). The final check would be the amount of time since the last floor update. Perhaps that’s where the complexity is introduced.

Something like:

  • If timeSinceFloorUpdate > 5 days, floor = sICX.balanceOf(Loans) * 80%
  • Else, floor = floor

I’m still open to the very simple hard-coded floor variable, but want to at least consider this option.

1 Like
#17

Okey let’s consider a simple % based solution like proposed by @hetfly

We have 2 variables controlled by governance per contract.
Floor Percentage - The percentage of a token that is allowed to be withdrawn from a contract
Time delay - The delay to adjust the floor back to the correct percentage.

On each withdraw we calculate the floor and ensure that floor < balance
FloorRemovedPerTime = (Balance*Floor Percentage )/Time delay
TimePassed = currentTime - lastUpdate
Floor = Floor - TimePassed*FloorRemovedPerTime
Floor = Max(Floor, Balance*(1-Floor Percentage ))
lastUpdate = currentTime

This allows us to use a self regulating solution which should need less hands on. Also automatically adopts during times where the balances increase a lot.

As an example consider loans:
Lets say loans have a balance of 1 Million sICX.
We configure a floor percentage of 10% and a time delay of 48 hours.
This means floor starts at 900K.
If now someone withdraws 50K sICX, the floor will still be at 900K and over the next 48 hours will decay to 855K linearly.

2 Likes
BIP 44: Loans floor limit
#18

Alright sounds good - I think this strikes a good balance between simplicity and manageability. Let’s go with this for DEX, Loans and Stability Fund.

What do you have in mind for parameters @Andell ?

#19

I also like the direction of these ideas of limiting risk.

Things to remember…

Balanced and OMM have both been hacked.

Our code that created OMM and Balanced has not been superior to other hacked DAO’s.

We are not getting reimbursed by ICON or any insurance policy. We are currently open to dangerous bridges that can be used to siphon funds.

So these ideas are good to limit risk. We already lost 1.1 million in a bear market that easily could have grown to 10 million in the bull market, but it is gone.

Also, is the silly narrative that we can be a leading cross chain DAO. We will most likely get hacked testing out ICONs new bridges unless we limit our forward thinking, like it is limited in this discussion. I love this discussion and love the direction of the discussion. We have to remember our code is not audited by large auditor. More of a small start up, cost effective auditor. They missed a simple mistake in the code. We need a legit audit company to verify the smart contracts of balanced before we should think cross chain.

As I’ve said in the past Balanced can grow just being the bank of ICON. Just being there to support SICX/BNUSD transactions and other ICX sub tokens.

We have gained no new users by diluting BALN and buying BTC, we will not gain new users trying ICONs new bridges because we have already been hacked and then the hacked funds already have moved quickly using the existing bridges.

We need to take baby steps, let ICX grow over the coming years, limit our cross chain risk. Most importantly build trust back to our DAO.

The cross chain narrative needs to proceed, but with extreme caution, limiting each future cross chain decision to withstand a hack. Every decision needs to be thought of as, what if this smart contract is hacked, what happens.

With all this said, Balanced has a world class team, ICON is world class, and Balanced can be world class with patience and baby steps.

Keep up the great work you all, I’m very impressed and happy to be involved.

Remember, Balanced is by far the most valuable APP to ICON.

If we get hit with another hack trying to rush code, using code that has not been audited by a reputable company, then using that code cross chain , if we get hacked, all of ICONs defi ecosystem is ruined.

Balanced is too valuable to the ICON ecosystem to be risky in future endeavors.

Every sub token in ICON becomes worthless if Balanced goes under. IMO, ICON will step up and massively support Balanced because we bring so much value to the ICON ecosystem. Time will tell:)

#20

Also some important questions…

  1. Our stats page says we have around 300k BNUSD and 265k BALN. I thought we froze 2.1 million ICX? What is the timeline to transfer that amount to the DAO fund? Or it may already be in there but it does not show up in the stats page…

We should just keep the 2.1 million in ICX as ICX until it ICX reaches a dollar then we can talk about utilization.

Also, OMM opened up a donations opportunity after their hack. Maybe we can do the same and Foundation and others can build Balanced back up if they choose to help out.