You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Looking at the code, it's clear that only an "owner" or an "updater" can change the state of the Oracle. Access is based on the comparison of caller's public key (account ID).
This means that the design has a single point of failure which can lead to number of problems:
if that key is lost or binary/process/machine that updates the prices goes offline - the Oracle stops updating.
if single key is compromised the Oracle can get updated with wrong prices, cause liquidations or other problems
Do you plan on using a multisignature account here?
The text was updated successfully, but these errors were encountered:
Hey,
this approach is chosen for flexibility, and the sender wallet can either be hosted by us or any customer who wants to self-custody the updater.
With a solution like Gnosis safe (or a simple updater smart contract) this can be extended to a multisig setup if needed.
Also, we are currently testing an approach (on EVM only so far) where our API generates a signature that is also submitted and checked on-chain for validity. In such a model no wallet owner check is needed for the update, as the update itself is signed.
However, this only works for Eth-style addresses at the moment (ECDSA) and we would need to extend the signature scheme for having it work in Aleph Zero as well.
Looking at the code, it's clear that only an "owner" or an "updater" can change the state of the Oracle. Access is based on the comparison of caller's public key (account ID).
This means that the design has a single point of failure which can lead to number of problems:
Do you plan on using a multisignature account here?
The text was updated successfully, but these errors were encountered: