accounts_modules

Overview

Returns all Move modules published under an account. Each module includes its compiled bytecode and the ABI (Application Binary Interface) describing the module's structs, functions, and type parameters. This endpoint is fundamental for on-chain contract discovery, ABI-driven integrations, and upgrade auditing.

Operational note: On Dwellir shared Aptos fullnodes, this route depends on indexer-backed helpers. If the upstream indexer reader is unavailable, requests can fail with internal_error. For production discovery workflows, keep a GraphQL fallback ready for large crawls and historical backfills.

Endpoint

GET /v1/accounts/{address}/modules

Aptos-Specific Notes

Move modules are published to the address of the deploying account and become part of that account's on-chain state.
Use this endpoint for ABI discovery, upgrade auditing, and verifying deployed contract interfaces.
The 0x1 address contains all Aptos framework modules (coin, account, staking, governance, etc.).
Module bytecode is the compiled Move output; decompilation is possible but not lossless.

Code Examples

Bash

# List all modules under the Aptos framework
curl -X GET "https://api-aptos-mainnet.n.dwellir.com/YOUR_API_KEY/v1/accounts/0x1/modules" \
  -H "Accept: application/json"

# List modules at a specific historical version
curl -X GET "https://api-aptos-mainnet.n.dwellir.com/YOUR_API_KEY/v1/accounts/0x1/modules?ledger_version=50000000" \
  -H "Accept: application/json"

Use Cases

ABI Discovery: Dynamically discover the interface of any deployed contract without prior knowledge. Build generic tools that can interact with any Move module by reading its ABI at runtime.
Upgrade Auditing: Compare modules at different ledger_version values to detect what changed in a contract upgrade, including new functions, modified parameters, or structural changes.
Contract Verification: Verify that deployed bytecode matches expected source code by compiling locally and comparing bytecode hashes.
SDK Generation: Auto-generate type-safe client libraries from on-chain ABIs, ensuring your integration stays in sync with the deployed contract.
Security Analysis: Inspect exposed functions, their visibility levels, and parameter types to assess the attack surface of a smart contract before interacting with it.
Protocol Integration: Before integrating with a DeFi protocol or NFT marketplace, fetch its modules to understand available entry points, required arguments, and return types.

Best Practices

Large Accounts: Framework addresses like 0x1 publish dozens of modules. Use pagination (limit and start) to control response size, or fetch a single module by name using the accounts_module endpoint. If the shared indexer path is unavailable, fall back to GraphQL for complete catalog exports.

Bytecode Size: Bytecode strings can be large (10KB-500KB per module). If you only need the ABI, parse the abi field and discard bytecode to reduce memory usage.

Historical Versions: When auditing upgrades, query at the version before and after the upgrade transaction to see exactly what changed. Find the upgrade transaction version from the account's transaction history.

Type Parameters: Generic type parameters in functions and structs use positional references (T0, T1). Map these to the generic_type_params array for constraint information.

Friend Modules: The friends list shows which other modules have privileged access. This is important for security audits -- friend functions can bypass normal visibility restrictions.

Caching: Module bytecode changes only when the module is upgraded. Cache aggressively and invalidate when you detect an upgrade transaction for the account.

Performance Considerations

Fetching all modules for an account can be slow for addresses with many deployments. The 0x1 framework address has 50+ modules, resulting in responses of 1-5MB and response times of 200-500ms.

For single-module lookups, use GET /v1/accounts/{address}/module/{module_name} instead, which returns in 50-100ms with a much smaller payload.

Bytecode dominates response size. If you only need the ABI (function signatures, struct definitions), consider fetching the full response once and caching the ABIs separately.

/v1/accounts/{address}/module/{module_name} - Get a single module by name
/v1/accounts/{address}/resources - Get account resources (runtime state of modules)
/v1/accounts/{address} - Get account info including authentication key
/v1/view - Call view functions discovered through module ABIs

On this page