[Feat] Integrate Bytecode Verification Status Display by apenzk · Pull Request #115 · movementlabsxyz/explorer

apenzk · 2026-01-05T15:55:04Z

Integrate Bytecode Verification Status Display

Target Branch: main

Related Issues

Closes #114

Dependencies

Depends on movementlabsxyz/aptos-core#272

Summary

This PR integrates the new bytecode verification API endpoint into the explorer UI. The explorer now queries the node's verification status and displays source code with appropriate warnings. Source code is always shown (if available), with warnings displayed when verification fails, is disabled, or unavailable.

Changes

Core Features

Verification Status Query: New React hook useGetModuleVerificationStatus to query node verification status
Conditional Display: Source code is always displayed (if available), with warnings shown based on verification status:
- Shows code normally if verified: true (matching source/bytecode) ✓
- Shows code with error alert if verified: false (SUSPICIOUS - bytecode mismatch)
- Shows code with warning alert if HTTP 422 (can't verify due to unsupported dependencies)
- Shows code with info alert if verification is disabled (HTTP 503) or unavailable (HTTP 404)
User Feedback: Clear warnings with appropriate severity levels:
- Loading state: "Verifying source code..."
- Error (red) - Mismatch: "The deployer provided source code but it does not match the deployed bytecode..."
- Warning (yellow) - Can't verify: "This contract cannot be verified because it uses dependencies that are not part of the standard Aptos framework..."
- Info (blue) - Disabled/Unavailable: "Source code verification is not available on this node..."

Implementation Details

API Client (src/api/client.ts):
- Added SERVICE_UNAVAILABLE and COMPILATION_ERROR error types
- Added getModuleVerificationStatus function
- Added ModuleVerificationStatusResponse interface
- Updated error handling to catch HTTP 503 and HTTP 422
React Hook (src/api/hooks/useGetModuleVerificationStatus.ts): New file
- React Query hook for fetching verification status
- Proper error handling and retry logic
- Skips retry for expected errors (404, 422, 503)
Code Display Component (src/pages/Account/Components/CodeSnippet.tsx):
- Added verification status query
- Always displays source code if available (maintains previous behavior)
- Shows alerts with appropriate severity:
  - Error: Verification fails (verified: false) - mismatched source/bytecode (SUSPICIOUS)
  - Warning: Compilation error (HTTP 422) - can't verify, uses unsupported dependencies
  - Info: Verification disabled (HTTP 503) or unavailable (HTTP 404)
- Loading state during verification
- Removed old disclaimer about unverified code
Module Views:
- src/pages/Account/Tabs/ModulesTab/ViewCode.tsx: Passes address and moduleName to Code component
- src/pages/Account/Tabs/ModulesTab/Contract.tsx: Passes address and moduleName to Code component
Constants (src/constants.tsx):
- Updated local network URL to standard port 8080

Testing

Manual testing was performed using the test setup at analysis-explorer-vulnerability on local devnet:

Scenario	Expected Behavior
Matching source code	Displays code without warning ✓
Mismatched source code	Displays code with error alert (red)
Unsupported dependencies (HTTP 422)	Displays code with warning alert (yellow)
Verification disabled (HTTP 503)	Displays code with info alert (blue)
No source code (HTTP 404)	Displays code with info alert (blue)

Update explorer to query node's bytecode verification endpoint and only display source code when verification succeeds. Changes: - Add getModuleVerificationStatus API client function - Add useGetModuleVerificationStatus React hook for querying verification status - Update Code component to query verification before displaying source - Only display source code if verification status is true (verified_success) - Handle errors: 404 (no source), 503 (verification disabled), false (verification failure) - Update ViewCode and Contract components to pass address/moduleName to Code component - Add SERVICE_UNAVAILABLE error type for 503 responses Display logic: - Loading: shows "Verifying source code..." message - Verified (true): displays source code with syntax highlighting - Not verified (false/error): does not display source code

vercel · 2026-01-05T15:55:10Z

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Review	Updated (UTC)
explorer	Ready	Preview, Comment	Jan 21, 2026 11:45am

netlify · 2026-01-05T15:55:11Z

✅ Deploy Preview for rococo-selkie-abda2e ready!

Name	Link
🔨 Latest commit	`5ab5c34`
🔍 Latest deploy log	https://app.netlify.com/projects/rococo-selkie-abda2e/deploys/6970bbf16967ac000868eb1d
😎 Deploy Preview	https://deploy-preview-115--rococo-selkie-abda2e.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify project configuration.

rubujubi · 2026-01-05T18:03:28Z

Not sure if this change is intentional, flagging it in case it affects other existing workflows

thx for pointing this out.

The new value for local network URL matches aptos-core's default REST API port. (defined in aptos-core/config/src/config/api_config.rs as DEFAULT_PORT: u16 = 8080).

i did not understand the reason why it should be 30731

Iirc it was 30731 with the old process-compose but yes 8080 should be correct default now... think @musitdev would know with greater certainty.

andygolay

@apenzk looking good, suggested a couple additions / edits.

andygolay · 2026-01-11T07:24:51Z

+        <Stack spacing={1}>
+          {hasVerificationFailure && (
+            <Alert severity="warning">
+              The deployer provided source code but it does not match the deployed bytecode. The displayed code may not accurately represent what is actually running on-chain.


Suggested change

The deployer provided source code but it does not match the deployed bytecode. The displayed code may not accurately represent what is actually running on-chain.

The deployer provided source code but it does not match the deployed bytecode. The displayed code does not accurately represent what is actually running on-chain.

i was going for the less strong word, because i would assume if there is a differing comment it would also fail? which can be construed as not being different with respect to code... is this wrong?

andygolay · 2026-01-11T07:33:11Z

        </Box>
+      ) : shouldShowCode ? (
+        <Stack spacing={1}>
+          {hasVerificationFailure && (


Add message when verification is successful:

Suggested change

{hasVerificationFailure && (

{isVerified && (

<Alert severity="success">

Source code verified: the displayed code matches the deployed bytecode.

</Alert>

)}

{hasVerificationFailure && (

andygolay · 2026-01-11T07:39:17Z

Iirc it was 30731 with the old process-compose but yes 8080 should be correct default now... think @musitdev would know with greater certainty.

andygolay · 2026-01-11T07:42:16Z

@@ -18,7 +18,7 @@ export const bardockTestnetUrl =
    testnet: "",
    "bardock testnet": bardockTestnetUrl,
  devnet: "",


@apenzk could you clean up the indentation:

Line 16: export has extra leading spaces

Line 20: devnet is missing indentation

apenzk · 2026-01-14T12:22:22Z

@andygolay i have added

a new type of error message for the case where it cannot be compiled, see the Testing section in the PR description.
added support for contracts being updated

I also added two cases in analysis-explorer-vulnerability to test correct behavior

Primata · 2026-01-14T18:24:00Z

@apenzk @andygolay don't we always want the latest version meaning that we always want to return the latest upgrade number? I would say we should drop the version number and cache only if the latest version is verified. So once it finds on cache and it doesn't find the latest version, it deletes from cache to free up some space (10k registries isn't that much).

Are we able to optimize finding the iteration over the Vec somehow?

- getModuleVerificationStatus and useGetModuleVerificationStatus accept upgradeNumber - API called with ?upgrade_number= when set - Contract and ViewCode pass upgrade_number from selected package to Code/verification hook - CodeSnippet accepts upgradeNumber and forwards to useGetModuleVerificationStatus

apenzk · 2026-01-21T11:46:25Z

@apenzk @andygolay don't we always want the latest version meaning that we always want to return the latest upgrade number? I would say we should drop the version number and cache only if the latest version is verified. So once it finds on cache and it doesn't find the latest version, it deletes from cache to free up some space (10k registries isn't that much).

@Primata I now dropped ledger_version from the verification_status endpoint and use upgrade_number instead. ledger_version was the wrong variable to use. The endpoint always uses now latest state and reads upgrade_number from PackageRegistry. If the client sends upgrade_number and it doesn't match the current one, we return 404 and don't serve from cache. Cache key now: (address, module_name, upgrade_number).

Why we must use upgrade_number at all:

(address, module_name) isn't enough—the same module can exist in multiple package versions due to the asynchronous nature of requests.
Example without upgarde_number: Explorer requests the contract and gets it at upgrade_number 1; the deployer later upgrades to 2 before the explorer requests the verification it shows the wrong badge.
Example with upgrade_number: Explorer sends 1, we see current is 2, return 404 and ask to refresh; after refresh they get upgrade 2 and we verify that. So we always tie the verification to the version the user is looking at.
PackageRegistry only has latest, so we always verify at latest and use upgrade_number to get the correct response for the verification

commits:

Are we able to optimize finding the iteration over the Vec somehow?

if 10k is an issue i would say we can reduce to 1000 or 100 even.

apenzk added 4 commits January 5, 2026 09:32

display code always but show a warning

7a693c6

fix(explorer): update local network URL to standard port 8080

1ccf2e9

change code display behavior

bcdf6c5

apenzk mentioned this pull request Jan 5, 2026

[Feat] Add On-Demand Bytecode Verification API movementlabsxyz/aptos-core#272

Open

21 tasks

apenzk requested review from Primata, andygolay and rubujubi January 5, 2026 16:20

rubujubi reviewed Jan 5, 2026

View reviewed changes

andygolay requested changes Jan 11, 2026

View reviewed changes

Handle HTTP 422 compilation errors with distinct warning

e504661

vercel bot deployed to Preview January 14, 2026 12:13 View deployment

Add success alert when source code verification passes

324c5ff

vercel bot deployed to Preview January 14, 2026 12:19 View deployment

Fix indentation in networks object

e535e16

apenzk requested a review from andygolay January 14, 2026 12:20

vercel bot deployed to Preview January 14, 2026 12:21 View deployment

vercel bot deployed to Preview January 21, 2026 11:45 View deployment

	The deployer provided source code but it does not match the deployed bytecode. The displayed code may not accurately represent what is actually running on-chain.
	The deployer provided source code but it does not match the deployed bytecode. The displayed code does not accurately represent what is actually running on-chain.

-          {hasVerificationFailure && (
+          {isVerified && (
+            <Alert severity="success">
+              Source code verified: the displayed code matches the deployed bytecode.
+            </Alert>
+          )}
+          {hasVerificationFailure && (

Conversation

apenzk commented Jan 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Integrate Bytecode Verification Status Display

Related Issues

Dependencies

Summary

Changes

Core Features

Implementation Details

Testing

Uh oh!

vercel bot commented Jan 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

netlify bot commented Jan 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

✅ Deploy Preview for rococo-selkie-abda2e ready!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

apenzk Jan 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

andygolay left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

apenzk Jan 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

apenzk commented Jan 14, 2026

Uh oh!

Primata commented Jan 14, 2026

Uh oh!

apenzk commented Jan 21, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

apenzk commented Jan 5, 2026 •

edited

Loading

vercel bot commented Jan 5, 2026 •

edited

Loading

netlify bot commented Jan 5, 2026 •

edited

Loading

apenzk Jan 5, 2026 •

edited

Loading

apenzk Jan 14, 2026 •

edited

Loading