Axelar aleo review

[anstylian]

Description

Todos

• Unit tests
• Manual tests
• Documentation
• Connect epics/issues

Convention Checklist

• Each contract should have a client mod for others to interact with it.
• Derive macros
  • EnsurePermissions: Contract permission control
  • IntoContractError: Conversion from custom contract errors to axelar_wasm_std::error::ContractError
  • IntoEvent: Event serialization
  • migrate_from_version: Contract version management in the migrate function
• The state mod and msg mod should use separate data structures so that internal state changes do not break the contract interface. Check out the interchain-token-service for reference.
  • msg.rs should never use any type from the state.rs
  • Shared types must be defined in a separate exported mod. If those types have already been defined somewhere else, then they should get re-exported in the exported mod

Steps to Test

Expected Behaviour

Notes

[anstylian]

@tilacog how to handle this? including a crate from a private repo

[anstylian]

ping @tilacog

[tilacog]

We can either try to publish just the aleo-parser to crates.io, if that's doable; or create a new public repo for it.

I prefer the first option because it's easier to maintain. That crate is very self-contained and don't expose our contract logic, so it should be safe to do so.

We might need to check that with @asmie first.

[anstylian]

@tilacog the contract log is not encrypted when your contract is deployed on testnet, so there is nothing to protect when it comes to contract logic

[tilacog]

@asmie mentioned we can give access for this repo to eigergo/axelar-aleo using GitHub tokens/secrets.

This seems like the cleanest approach to me, because wouldn’t have to deal with new repositories or crate publishing.

[anstylian]

check this, or document

[anstylian]

Add a test for Aleo address