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
🤔 There are some different layers where the validation can happen
Frontent
Provider contracts
Consumer contracts
Consumer chain - contains this logic already
IMHO: for fast feedback and best UX the validation should happen as close to the user as possible. The frontend has already the "problem" where it get's the validator data to display it. Adding a quick check there would be low effort.
The check on the consumer chain is mandatory for safety and built into the staking module already. Nevertheless bringing this closer to the provider can be beneficial to remove complexity in the contracts.
Checking for valid addresses in the entrypoint of the consumer contracts should be still within reasonable gas costs. The contract could either check with the chain data on every request or maintain a persistent accept list. That would add more complexity there though.
Validating on the provider side requires some data replication. Probably the simplest thing would be a bech32 check to reject random strings. A full validator set comes with some cost to maintain it proper. Options are push or pulling the data via IBC.
To sumarize:
IMHO: Relying on frontend validation and basic bech32 address validation in the vault contract feel like a quick and effective solution. Unless there are other requirements to keep a valset copy on the provider side, there is only small effort on the consumer edge contract that handles the IBC part and has access to the chain data.
Better error handling in this case. Both in the virtual staking contract and the whole Rust logic (handling said errors)
Also, share more info to the provider chain to prevent this in the first place. Let's think more.
The text was updated successfully, but these errors were encountered: