2 posts tagged with "foundry"

Foundry is one of the most popular toolchains for Ethereum smart contract development. Built in Rust, Foundry provides everything needed to build, test, and deploy smart contracts. At the center of this workflow is Forge, Foundry’s scripting and deployment tool. Forge scripts are written in Solidity itself, allowing developers to deploy contracts and interact with them.

However, one key step that developers miss in their workflows is to name their contracts right after the deployment is done. This is where our new Enscribe plugin comes in.

The key idea behind Enscribe is simple: naming should be automated and baked into the deployment scripts. Using Enscribe, a Forge script can register or update an ENS name for a deployed contract, optimally only set forward resolution (ENS → address), and set reverse resolution (address → ENS). Because this logic runs in Solidity, it integrates naturally with Foundry’s scripting environment.

Let’s see how developers can set names for their contract with Enscribe and Forge working together.

1. Create a new project:

   forge init counter
   cd counter
   

2. Install the Enscribe plugin:

   forge install enscribexyz/enscribe
   

3. Install openzeppelin:

   forge install OpenZeppelin/openzeppelin-contracts
   

4. Create remapping.txt in the root dir and add the following to it to simplify imports:

   enscribe/=lib/enscribe/src/
   @openzeppelin/contracts/=lib/openzeppelin-contracts/contracts/
   

5. Make Counter implement Ownable:

   import "@openzeppelin/contracts/access/Ownable.sol";  
   
   contract Counter is Ownable {      
       constructor(uint256 initialCount) Ownable(msg.sender) {
           number = initialCount      
       }
   }
   

6. Edit our deployment script Counter.s.sol to set a primary name for the contract once deployed:

   import {Ens} from "enscribe/Ens.sol";  
   import {Script, console} from "forge-std/Script.sol";
   import {Counter} from "../src/Counter.sol";
   
   contract CounterScript is Script {
       Counter public counter;  
   
       function setUp() public {}
   
       function run() public {
           vm.startBroadcast();  
   
           counter = new Counter(0);
           Ens.setName(block.chainid, address(counter), "v1.counter.abhi.eth");
           
           vm.stopBroadcast();
       }
   }
   

7. Run the script to deploy the contract on Sepolia and set the name at deployment!

   forge script script/Counter.s.sol:CounterScript --chain-id 11155111 --rpc-url $SEPOLIA_RPC_URL --broadcast --private-key $PRIVATE_KEY
   

You can now view the deployed contract in Enscribe app:

This simplification means that teams can use Enscribe to name their releases. For example, we not only named our contract but versioned it too with v1.counter.abhi.eth.

By making contract naming easier and part of the deployment workflow with Foundry, Enscribe encourages better UX and improves safety and usability across the Ethereum ecosystem.

In a world where users increasingly should see human-readable names instead of hex addresses in wallets and explorers, Enscribe helps ensure that smart contracts are just as legible as the accounts that interact with them.

Give it a try.

Happy naming! 🚀

Foundry and Alloy are foundational tools in the smart contract development stack, and we want smart contract naming to be integrated into all core developer workflows.

Foundry is referred to as the smart contract development toolchain while Alloy, used by Foundry as a dependency, provides a range of functionality for interfacing with any Ethereum-based blockchain.

Before Alloy, there was ethers-rs, which became deprecated in favour of Alloy. It had a small ENS utility crate support that was added in Foundry. The Enscribe team recently migrated this ENS crate over to Alloy from Foundry.

By extending Alloy and Foundry with ENS-focused tools, we're making it easier for developers to use these tools and enabling them to easily name their smart contracts. With the recent merge of PR #2676 in the Alloy codebase, reverse resolution, a critical part of smart contracts naming, just got simpler.

This update introduces support for retrieving the ENS Reverse Registrar address using the ENS Registry. That’s the key contract responsible for mapping an Ethereum hex address back to a name like v0.app.enscribe.xyz.

Why Reverse Resolution Matters​

Forward resolution (e.g., alice.eth → 0xabc...) is familiar. But reverse resolution (0xabc... → alice.eth) is what allows user-interfaces to show names instead of raw addresses.

Under the hood, reverse resolution works by:

• namehashing the address (as addr.reverse),
• querying the ENS registry for the resolver, and then
• calling name(node) on the resolver.

This PR makes that logic easily accessible via the EnsRegistry::owner method, allowing you to fetch the reverse registrar address directly using the ENS registry..

Simple Integration​

With this change, any Alloy-based app or library can now perform Reverse Registrar discovery. Here’s the high-level call pattern in Rust:

let provider = ProviderBuilder::new()
    .connect_http("https://reth-ethereum.ithaca.xyz/rpc".parse().unwrap());

let rr = provider.get_reverse_registrar().await?;
assert_eq!(rr.address(), address!("0xa58E81fe9b61B5c3fE2AFD33CF304c454AbFc7Cb"));

Once you have that address, you can construct a ReverseRegistrarInstance and query names from addresses or just interact with the ReverseRegistrar contract however you like.

On the Road to Contract Naming Support in Foundry​

This PR is a small but crucial step toward full ENS tooling support in the Alloy and Foundry ecosystem. By baking in access to one of the core ENS smart contracts like the Reverse Registrar, we make it one step closer to naming your smart contracts with Foundry.

Happy naming! 🚀