How does Atlas ensure all Solidity callsites are migrated?

Atlas combines `lsp`'s `findReferences` with `grep` to identify every callsite of a deprecated Solidity symbol, including dynamic or string-based usages. It then creates a `todowrite` entry for each, ensuring comprehensive tracking and preventing any callsite from being missed.

What Solidity tools does Atlas integrate with?

Atlas integrates deeply with the Foundry toolchain. It runs `forge test` for verification, understands libraries installed by `forge soldeer`, applies `forge fmt` for consistent formatting, and can run `forge snapshot` to show gas deltas.

Is Atlas safe for production Solidity codebases?

Yes, Atlas is designed with multiple safety layers. Every tool call is permission-gated, requiring explicit approval. It drafts plans in a read-only agent, presents unified diffs for approval before writing, and snapshots changes as git patches for easy rollback.

Can Atlas handle complex Solidity refactors beyond simple API migrations?

Atlas's core capabilities, such as AST-based indexing, semantic search, and precise patching, make it suitable for a range of complex Solidity refactors. It can assist with tasks like adding reentrancy guards or converting `require` strings to custom errors, always within the context of your Foundry project.

How does Atlas prevent errors during Solidity API migration?

Atlas prevents errors by using `apply_patch` which fails if the expected code context is not found, avoiding misapplications. It also runs `forge test` immediately after each change, ensuring that any introduced regressions are caught and addressed before marking a task complete.

Does Atlas require my Solidity code to be sent to third-party servers?

No, Atlas can build its code index with local Ollama embeddings, keeping your Solidity code entirely off third-party servers. This ensures the privacy and security of your smart contract intellectual property.

How does Atlas manage changes to `foundry.toml` or other configuration files?

Atlas operates within a Foundry project, understanding its structure including `foundry.toml` and `src/` directories. While its primary focus is code migration, its `grep` tool can identify references in configuration files, and `apply_patch` can modify them under explicit approval, just like Solidity source files.

Migrate a deprecated API across every callsite in Solidity with Atlas in 2026

Atlas enables Solidity developers to systematically migrate deprecated APIs across an entire codebase, ensuring no callsite is missed and every change is verified. By integrating directly with your Foundry project and leveraging tools like `forge test`, `soldeer`, and `forge fmt`, Atlas provides a robust, terminal-native solution for complex refactoring jobs, delivering a unified diff for approval before any file is written.

How does Atlas find all deprecated Solidity function calls?

Atlas enumerates every callsite of a deprecated Solidity symbol using a hybrid approach, combining the `lsp` tool's `findReferences` with `grep` for comprehensive coverage. This ensures that even dynamic or string-based usages, which might be missed by a language server alone, are identified, providing a 100% complete list for migration.

When migrating a deprecated function or module in a Solidity codebase, the first critical step is to identify every single location where it is called. Atlas achieves this by leveraging its `lsp` tool, which queries the language server to find all direct references to the deprecated symbol. This is particularly effective in a Foundry project, where the language server understands the contract structure, storage layout, and modifier usage. However, Solidity development can sometimes involve dynamic calls or string literals that reference function names, which a static LSP analysis might overlook. To address this, Atlas cross-checks the `lsp` results with its `grep` tool, performing a keyword search across the entire codebase. This dual-pronged approach guarantees that Atlas builds a complete and accurate list of all callsites, from explicit function calls in `src/` files to potential string-based references in configuration or test files within `test/`. This thorough enumeration is crucial for a migration workflow that "punishes half-measures," ensuring that no deprecated callsite is silently skipped, which could lead to runtime errors or security vulnerabilities in a production smart contract.

How does Atlas track Solidity API migration progress?

Atlas transforms the enumerated list of deprecated Solidity callsites into actionable, trackable work items using its `todowrite` tool. This ensures that partial progress is always visible, and no single callsite is overlooked during the migration process, providing a clear roadmap for refactoring 100s of lines of code.

After identifying every callsite of a deprecated Solidity API, Atlas converts this comprehensive list into a structured set of tasks. The `todowrite` tool creates an individual entry for each callsite, effectively breaking down a large, complex migration into manageable, atomic units of work. This granular tracking is vital for large Solidity codebases, especially within a Foundry project where many contracts might depend on a single deprecated library or function. Each `todowrite` entry represents a specific migration task, allowing developers to see exactly which callsites have been addressed and which still require attention. This prevents the common pitfall of losing track of progress or inadvertently skipping a callsite, which could leave a codebase in an inconsistent or vulnerable state. As each callsite is successfully migrated and its associated tests pass, Atlas marks the corresponding `todowrite` entry as complete, providing a transparent and auditable record of the entire migration process. This systematic approach ensures that the job of moving an entire codebase off a deprecated function onto its replacement is executed with precision and full visibility.

How does Atlas safely migrate Solidity code changes?

Atlas performs each Solidity callsite migration using its `apply_patch` tool, which is designed for context-anchored, precise modifications. This tool seeks the exact hunk's context and old lines, failing explicitly with "Failed to find expected lines" rather than misapplying to a drifted file, ensuring 0 unintended changes to your smart contracts.

The actual migration of each deprecated Solidity callsite is handled by Atlas's `apply_patch` tool, which prioritizes safety and precision. Unlike simple find-and-replace operations, `apply_patch` does not guess. It requires a specific context and the exact `old_lines` of the code hunk it intends to modify. If the expected lines or their surrounding context have changed since the patch was generated,perhaps due to concurrent development or a previous, related refactor,`apply_patch` will explicitly fail, reporting "Failed to find expected lines." This robust mechanism prevents the tool from introducing unintended changes or applying patches to incorrect locations within your Solidity contracts, which is paramount in an environment where every diff has a gas cost and an attack surface. Before writing any changes, Atlas computes a unified diff for every file edit and surfaces it for approval, allowing the developer to review the exact modifications. This ensures that changes to `src/` files, including contract logic, storage layouts, and modifier implementations, are thoroughly vetted. Furthermore, Atlas snapshots file changes as git patches, providing an additional layer of safety by allowing edits to be easily diffed and rolled back if necessary, maintaining the integrity of your Foundry project's version control.

How does Atlas verify Solidity code after migration?

After each Solidity file is modified during a migration, Atlas immediately runs the affected tests using the `bash` tool to execute `forge test`. This critical step ensures that the changes have not introduced regressions or broken existing functionality, providing instant feedback and maintaining a high level of code quality throughout the 2026 migration process.

Verifying the correctness of migrated Solidity code is a non-negotiable step, especially in a Foundry project where smart contract integrity is paramount. Atlas integrates this verification directly into the migration workflow. After `apply_patch` modifies a Solidity file in `src/`, Atlas uses its `bash` tool to execute `forge test` for the affected contracts. This immediate feedback loop is crucial: if the tests fail, Atlas knows the migration for that specific callsite was unsuccessful or introduced a bug, and the `todowrite` entry is not marked as complete. This ensures that only correctly migrated and fully functional code is committed. Beyond functional correctness, Atlas also supports `forge snapshot` to help developers understand the gas delta introduced by the changes before approval. This allows for informed decisions regarding potential gas cost increases or optimizations. Finally, Atlas can run `forge fmt` on the diff, ensuring that all migrated code adheres to the project's formatting standards, maintaining consistency across the codebase. This comprehensive verification process, from unit tests to gas analysis and formatting, ensures that the Solidity codebase remains robust and secure throughout the entire migration.

What are the safety features for Solidity API migrations with Atlas?

Atlas incorporates multiple safety features to protect Solidity codebases during API migrations, including permission-gated tool calls and a read-only plan agent. Every Atlas tool call is permission-gated against allow, ask, and deny rules, ensuring that no action is taken without explicit developer consent, preventing 100% of unauthorized modifications.

Migrating critical Solidity smart contracts requires an uncompromising approach to safety. Atlas is built with several layers of protection to ensure that developers maintain full control and visibility throughout the process. Firstly, every Atlas tool call, including `lsp`, `grep`, `todowrite`, `apply_patch`, and `bash`, is permission-gated. This means that before any tool executes, it checks against `allow`, `ask`, and `deny` rules, requiring explicit developer approval for potentially impactful operations. This prevents Atlas from making unauthorized changes to your `src/` files or executing commands like `forge test` without consent. Secondly, Atlas drafts a plan in a read-only plan agent and asks for approval before switching to a build agent that can make modifications. This "plan-then-execute" model provides a crucial review point, allowing developers to understand the intended actions before any code is touched. Thirdly, as mentioned, Atlas computes a unified diff for every file edit and surfaces it for approval before writing, giving developers a final chance to inspect and approve changes to their Solidity code. Atlas also reads git branches, status, and diffs, and can stage and create commits on your behalf, integrating direct with your existing version control workflow. This comprehensive suite of safety features ensures that even complex migrations in a Foundry project are performed with maximum control and minimal risk.

Step by step

011: Enumerate all deprecated Solidity callsites: Use Atlas's `lsp` tool to `findReferences` for the deprecated symbol in your Foundry project, then cross-check with `grep` to catch any dynamic or string-based usages across `src/` and `test/` directories.
022: Create trackable work items: Instruct Atlas to use its `todowrite` tool to generate one entry for each identified Solidity callsite, ensuring every migration task is visible and nothing is silently skipped.
033: Migrate each Solidity callsite: For each `todowrite` entry, have Atlas use `apply_patch` to migrate the callsite. Review the unified diff presented by Atlas for changes to your `src/` files and approve the modification.
044: Verify and complete: After each file modification, Atlas will use its `bash` tool to run `forge test` for the affected Solidity contracts. Only once tests pass, mark the `todowrite` entry as complete.
055: Final confirmation and cleanup: Once all `todowrite` entries are complete, use Atlas's `grep` tool to perform a final search for the deprecated Solidity symbol, confirming zero remaining hits. Then, instruct Atlas to delete the old implementation from your `src/` directory.

Frequently asked questions

How does Atlas ensure all Solidity callsites are migrated?: Atlas combines `lsp`'s `findReferences` with `grep` to identify every callsite of a deprecated Solidity symbol, including dynamic or string-based usages. It then creates a `todowrite` entry for each, ensuring comprehensive tracking and preventing any callsite from being missed.
What Solidity tools does Atlas integrate with?: Atlas integrates deeply with the Foundry toolchain. It runs `forge test` for verification, understands libraries installed by `forge soldeer`, applies `forge fmt` for consistent formatting, and can run `forge snapshot` to show gas deltas.
Is Atlas safe for production Solidity codebases?: Yes, Atlas is designed with multiple safety layers. Every tool call is permission-gated, requiring explicit approval. It drafts plans in a read-only agent, presents unified diffs for approval before writing, and snapshots changes as git patches for easy rollback.
Can Atlas handle complex Solidity refactors beyond simple API migrations?: Atlas's core capabilities, such as AST-based indexing, semantic search, and precise patching, make it suitable for a range of complex Solidity refactors. It can assist with tasks like adding reentrancy guards or converting `require` strings to custom errors, always within the context of your Foundry project.
How does Atlas prevent errors during Solidity API migration?: Atlas prevents errors by using `apply_patch` which fails if the expected code context is not found, avoiding misapplications. It also runs `forge test` immediately after each change, ensuring that any introduced regressions are caught and addressed before marking a task complete.
Does Atlas require my Solidity code to be sent to third-party servers?: No, Atlas can build its code index with local Ollama embeddings, keeping your Solidity code entirely off third-party servers. This ensures the privacy and security of your smart contract intellectual property.
How does Atlas manage changes to `foundry.toml` or other configuration files?: Atlas operates within a Foundry project, understanding its structure including `foundry.toml` and `src/` directories. While its primary focus is code migration, its `grep` tool can identify references in configuration files, and `apply_patch` can modify them under explicit approval, just like Solidity source files.

Try Atlas in your terminal

The terminal-native AI coding agent. Free core, single binary.

Install Atlas

Related guides

Migrate a Deprecated API Across Every Callsite with Atlas (2026 Workflow)

How to migrate a deprecated API across every callsite with Atlas in 2026: the lsp tool's findReferences enumerates callers, todowrite tracks them, apply_patch migrates each one.

Review a Pull Request in Solidity with Atlas in 2026

Atlas helps Solidity developers in 2026 review pull requests by providing deep context, running `forge test`, and checking for vulnerabilities. Catch subtle bugs in your smart contracts and ensure robust code quality.

Research a Third-Party API for Solidity Integration with Atlas in 2026

Streamline Solidity API integrations in 2026 with Atlas. Research external APIs, fetch documentation, and verify against Foundry's `forge test` and `forge fmt` standards.

Diagnose a Hanging or Long-Running Command in Solidity with Atlas in 2026

Solidity developers in 2026 can use Atlas to diagnose whether a `forge test` or `forge soldeer install` command is genuinely slow or silently blocked on input, and get it unstuck.

Onboard to an Unfamiliar Solidity Codebase with Atlas in 2026

Solidity developers in 2026 can rapidly build a mental model of any unfamiliar codebase using Atlas. Leverage semantic search, AST indexing, and Foundry toolchain integration with forge test, soldeer, and forge fmt.

Rename a symbol across the repo in Solidity with Atlas in 2026

Rename Solidity functions, classes, or constants across your entire repository with Atlas. Leverage precise LSP references and `forge test` verification for safe, accurate refactoring in 2026.

Debug a single failing test in Solidity with Atlas in 2026

In 2026, Atlas helps Solidity developers debug single failing forge test cases within Foundry projects. Pinpoint issues, trace call graphs, and fix smart contract code with AI-driven precision and safety.

Audit a Solidity Repo with Parallel Subagents in Atlas, 2026

Sweep your Solidity repository for common problems using Atlas's parallel subagents. Identify issues in Foundry projects without blowing your context window, ensuring secure smart contracts.

Browse this resource hub