-
Notifications
You must be signed in to change notification settings - Fork 260
feat(devtools-aptos): add Aptos devtools packages for OmniGraph support #1922
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: feat/devtools-sui-examples
Are you sure you want to change the base?
Conversation
Add three new packages for Aptos devtools: - @layerzerolabs/devtools-aptos: Core Aptos utilities (connection, signer, OmniSDK) - @layerzerolabs/protocol-devtools-aptos: EndpointV2 and ULN302 SDKs - @layerzerolabs/ua-devtools-aptos: OFT SDK implementing IOApp interface These packages enable lz:oapp:wire support for Aptos OFTs following the OmniGraph pattern used by Sui and Starknet.
PR SummaryIntroduces first-class Aptos support across devtools and SDKs following the OmniGraph pattern.
Written by Cursor Bugbot for commit 9fd740c. Configure here. |
|
Review the following changes in direct dependencies. Learn more about Socket for GitHub.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cursor Bugbot has reviewed your changes and found 4 potential issues.
| // Simple encoding - in practice this would use proper BCS encoding | ||
| const encoder = new TextEncoder() | ||
| return encoder.encode(JSON.stringify(config)) | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Uint8Array corrupted during JSON serialization
High Severity
The encodeExecutorConfig and encodeUlnConfig methods return Uint8Array, but these values are placed in objects that get passed through JSON.stringify. When a Uint8Array is JSON-serialized, it becomes an object with numeric string keys (e.g., {"0":1,"1":2}) rather than an array. When the signer later parses this JSON, it receives a malformed object instead of the expected byte array, causing transactions to fail or behave incorrectly. Other places in the codebase (like setPeer and setEnforcedOptions) correctly use Array.from() to convert Uint8Array before serialization.
Additional Locations (2)
| types: ['u32', 'u16', 'u8'], | ||
| }), | ||
| description: `Setting enforced options for eid ${opt.eid}, msgType ${opt.option.msgType} (1 of ${enforcedOptions.length})`, | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
setEnforcedOptions silently ignores all but first option
High Severity
When setEnforcedOptions receives multiple OAppEnforcedOptionParam entries, only the first option is processed and returned as a transaction. All subsequent options are silently ignored. The IOApp interface contract and other SDK implementations (EVM, Solana) expect all provided options to be handled. This causes configurations to be partially applied without any indication to the caller that options were dropped.
| point: this.point, | ||
| data: '0x', | ||
| description: 'Library registration not required on Aptos', | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Invalid JSON in transaction data causes signer crash
High Severity
Several methods return transactions with data: '0x' (e.g., registerLibrary, setDefaultUlnConfig, setDefaultExecutorConfig, and setEnforcedOptions when the array is empty). However, the AptosSigner.sign and signAndSend methods call JSON.parse(transaction.data) on line 75/115 of the signer. Since '0x' is not valid JSON, this throws a SyntaxError, crashing the signer when attempting to process these "no-op" transactions.
Additional Locations (2)
| address: this.endpointAddress ?? this.point.address, | ||
| }, | ||
| this.connectionFactory | ||
| ) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Endpoint SDK created with wrong contract address
High Severity
In getEndpointSDK(), when endpointAddress is not provided to the OFT constructor, the code falls back to this.point.address (the OFT contract address). This address is then used by EndpointV2 to construct function calls like ${endpointAddress}::endpoint::get_default_receive_library. Since endpoint functions don't exist on the OFT contract, all endpoint-related calls will fail. The createOFTFactory never provides an endpoint address, so all OFTs created through the factory have this bug.
Additional Locations (1)
🧪 E2E Test StatusE2E tests are non-blocking and validate real blockchain interactions. Failures may occur due to network issues, RPC rate limits, or external service downtime. Test Runs (Newest First):
|
Summary
This PR adds three new packages for Aptos devtools to enable
lz:oapp:wiresupport for Aptos OFTs:@layerzerolabs/devtools-aptos: Core Aptos utilities (connection factory, signer with sequence number tracking, OmniSDK base)@layerzerolabs/protocol-devtools-aptos: EndpointV2 and ULN302 SDKs implementing IEndpointV2 and IUln302 interfaces@layerzerolabs/ua-devtools-aptos: OFT SDK implementing the IOApp interface (setPeer, getPeer, hasPeer, getEndpointSDK, setDelegate)These packages follow the OmniGraph pattern established by Sui and Starknet devtools packages.
Changes
packages/devtools-aptos/with connection factory, signer implementation, and OmniSDKpackages/protocol-devtools-aptos/with EndpointV2 and ULN302 SDKspackages/ua-devtools-aptos/with OFT SDK and factoryRelated PRs
Test Plan