Comment on page
Building xApps
Each cross-chain application must implement its own messaging interface. By convention, we call the contracts that implement this protocol the application's Router contracts. These Router contracts must:
- Maintain a permissioned set of the contract(s) on remote chains from which it will accept messages via Nomad — this could be a single owner of the application on one chain; it could be a registry of other applications implementing the same rules on various chains
- Maintain a permissioned registry of connections via the
XappConnectionManagercontract (see Connection Management). - Encode messages in a standardized format, so they can be decoded by the Router contract on the destination chain
- Handle messages from remote Router contracts
- Dispatch messages to remote Router contracts
By implementing these pieces of functionality within a Router contract and deploying it across multiple chains, we create a working xApp using a common language and set of rules. Applications of this kind may use Nomad message passing channels as the cross-chain courier for sending and receiving messages between chains.
The router implements the
XappConnectionClient abstract contract. This contract provides convenience functions for working with a XAppConnectionManager.The XCM is the primary permissioning point for channels. It provides functions by which
- xApp administrators can enroll or unenroll
Replicacontracts for inbound messages - xApp administrators can enroll or unenroll a
Homecontract for outbound messages - xApp administrators can permission or de-permission watchers
- watchers can unenroll
Replicacontracts
When deploying a xApp
Router, the xApp administrators must select an existing XappConnectionManager, or deploy their own. The address of the XappConnectionManager must be passed to the router's initialization method.
Last modified 1yr ago