logoAcademy

How the ICM Registry works

Learn about the different functionality available in the Interchain Messaging Registry.

TeleporterRegistry keeps track of TeleporterMessenger contract versions. Cross-Avalanche L1 dApps can request the latest or a specific version of the TeleporterMessenger:

Internally the TeleporterRegistry maintains a mapping of TeleporterMessenger contract versions to their addresses.

Each registry's mapping of version to contract address is independent of registries on other blockchains, and chains can decide on their own registry mapping entries. So the contract of version 4 on one chain does not have to be equal to that version on another chain.

/lib/teleporter/contracts/src/Teleporter/upgrades/TeleporterRegistry.sol
 
contract TeleporterRegistry {
    // .... 
  
    // The latest protocol version. 0 means no protocol version has been added, and isn't a valid version.
    uint256 public latestVersion;
 
    // Mappings that keep track of the protocol version and corresponding contract address.
    mapping(uint256 version => address protocolAddress) private _versionToAddress;
    mapping(address protocolAddress => uint256 version) private _addressToVersion;
  
   // ...
}
 
In the TeleporterRegistry contract, the latestVersion state variable returns the highest version number that has been registered in the registry. The getLatestTeleporter function returns the ITeleporterMessenger that is registered with the corresponding version. Version zero is an invalid version, and is used to indicate that a TeleporterMessenger contract has not been registered yet.
 
```solidity title="/lib/teleporter/contracts/src/Teleporter/upgrades/TeleporterRegistry.sol"
contract TeleporterRegistry {
    // .... 
  
  	// Mappings that keep track of the protocol version and corresponding contract address.
    mapping(uint256 version => address protocolAddress) private _versionToAddress;
  
    // The latest protocol version. 0 means no protocol version has been added, and isn't a valid version.
    uint256 public latestVersion;
 
    function getLatestTeleporter() external view returns (ITeleporterMessenger) {
        return ITeleporterMessenger(getAddressFromVersion(latestVersion));
    }
 
	function getAddressFromVersion(uint256 version) public view returns (address) {
        require(version != 0, "TeleporterRegistry: zero version");
        address protocolAddress = _versionToAddress[version];
        require(protocolAddress != address(0), "TeleporterRegistry: version not found");
        return protocolAddress;
    }
  
    // ...
}

If a cross-Avalanche L1 dApps prefers a specific version, it can also call directly the getAddressFromVersion function:

/lib/teleporter/contracts/src/Teleporter/upgrades/TeleporterRegistry.sol
contract TeleporterRegistry {
  	// Mappings that keep track of the protocol version and corresponding contract address.
    mapping(uint256 version => address protocolAddress) private _versionToAddress;
  
    // .... 
  
	function getAddressFromVersion(uint256 version) public view returns (address) {
        require(version != 0, "TeleporterRegistry: zero version");
        address protocolAddress = _versionToAddress[version];
        require(protocolAddress != address(0), "TeleporterRegistry: version not found");
        return protocolAddress;
    }
  
    // ...
}

If you are interested in the entire implementation, check it out here.

Updated:

On this page

No Headings
Edit on Github