search

block42-blockchain-company / liquid-icx

Secure the ICON network, earn staking rewards while staying liquid. 🧽💧
https://licx.finance
GNU General Public License v3.0
3 stars 1 forks source link

Protocol should be owned by a MultiSig #34

Open ghost opened 4 years ago

ghost commented 4 years ago

Explore the option to use ICONations MultiSig as the contract owner: https://github.com/iconation/MultiSigWallet

ghost commented 4 years ago

In case a contract can not deploy another contract; the ICON network needs to implement a setter for the contract owner.

mr-rooftop commented 4 years ago

What advantage does this pose in your opinion? Less possibility of key theft? And who should be the mutlisig signers in your opinion?

tomazmm commented 4 years ago

This would remove us as a contract/project "overpowered" owner. I think we really should not be the only one responsible to invoke some "critical" functions ( min_value_to_get_value, iteration_limit, updating contract, etc. ). A multi-sig wallet could/would make an LICX more community-driven project, what is our main goal from the start of the project.

Spl3en commented 3 years ago

Even though I approve the initial idea, right now deploying a SCORE from another SCORE isn't supported in the ICON Protocol. Consequently, the multisig contract cannot deploy the LICX contract, which makes OP's suggestion harder to implement.

As an alternate solution, you could implement a shared ownership mecanism in the LICX contract which communicates with a multisig contract to reproduce the same effect, but you'll need to implement it.

mr-rooftop commented 3 years ago

Thanks for the input @Spl3en! Good suggestions with the ownership. That's exactly what we did in Bridge, so it would be defnitely possible.

However, I feel like the only really critical function is updating the SCORE. As this can't be transferred to another SCORE, I don't see a reason to implement this behaviour atm.

The "onlyOwner" functions are setIterationLimit(), setMinValueToGetRewards(), and setCap(). The first function is critical in terms of correct SCORE functionality (iteration limit in SCORE), and the last two influence the user experience. None of those functions are important for the "safety of funds".

Therefore I suggest to possibly update the SCORE with such functionality in the future when we see a real need for it.