feat: init Lazer Aptos contract #2381
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
3 Skipped Deployments
|
tejasbadadare
changed the title
…d getters for private struct fields, improve tests
|
I will handle governance actions in the next PR to keep this one from getting too unwieldy (initializing using the Wormhole deployer, setting up a governance module that owns the lazer SignerCapability, and handling governance instructions such as contract upgrades) |
| /// Allows the designated admin to claim their capability | ||
| public entry fun claim_admin_capability(account: &signer) acquires PendingAdminCapability { | ||
| let pending = borrow_global<PendingAdminCapability>(@pyth_lazer); | ||
| assert!(signer::address_of(account) == pending.admin, ENO_PERMISSIONS); |
There was a problem hiding this comment.
we need to invalidate the admin capability right? otherwise it seems we can mint infinite capabilities.
more for my edification: could the @pyth get admincapability itself in initialize and then later transfer it to someone else :?
There was a problem hiding this comment.
we need to invalidate the admin capability right? otherwise it seems we can mint infinite capabilities.
multiple claim attempts by the admin will fail, since there can only be a single resource of a given type under an account, and since the capabilities don't have copy there shouldn't be a way to distribute copies of the capability. i thought about explicitly destroying the PendingAdminCapability after it has been claimed, but thought it might be misleading since move already guarantees it can't be double-claimed.
But, on second thought, leaving it in global state is kinda confusing, and may invite people to try to use it. I'll destroy it after it's been claimed
more for my edification: could the @pyth get admincapability itself in initialize and then later transfer it to someone else :?
and get rid of PendingAdminCapability? yeah i think that would work, but i was following the wormhole deployer's pattern of a pending capability. i'll dig into this.
There was a problem hiding this comment.
I looked it up and it seems that in Aptos a non-contract cannot pass it's owned objects to the functions and therefore i don't think they can transfer an object. I'm not sure but i saw this pattern a lot that there's an entrypoint for signer everywhere and then objects are collected (like what you do now) which partially defeats the purpose of this language construct 🤷 SUI handles it properly though.
First pass at the Aptos Lazer contract. Keeps the same API as the Solana and EVM contracts.
Uses Ed25519 signatures as recommended by Aptos docs.
Deployed to devnet here.
Example transaction of initializing the contract here.