Protocol should be owned by a MultiSig

[ghost]

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

[ghost]

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

[mr-rooftop]

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

[tomazmm]

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]

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]

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.