# Integration
Learn how to integrate IBC to your application and send data packets to other chains.
This document outlines the required steps to integrate and configure the IBC module (opens new window) to your Cosmos SDK application and send fungible token transfers to other chains.
# Integrating the IBC module
Integrating the IBC module to your SDK-based application is straighforward. The general changes can be summarized in the following steps:
- Add required modules to the
module.BasicManager
- Define additional
Keeper
fields for the new modules on theApp
type - Add the module's
StoreKeys
and initialize theirKeepers
- Set up corresponding routers and routes for the
ibc
andevidence
modules - Add the modules to the module
Manager
- Add modules to
Begin/EndBlockers
andInitGenesis
- Update the module
SimulationManager
to enable simulations
# Module BasicManager
and ModuleAccount
permissions
The first step is to add the following modules to the BasicManager
: x/capability
, x/ibc
,
x/evidence
and x/ibc-transfer
. After that, we need to grant Minter
and Burner
permissions to
the ibc-transfer
ModuleAccount
to mint and burn relayed tokens.
# Application fields
Then, we need to register the Keepers
as follows:
# Configure the Keepers
During initialization, besides initializing the IBC Keepers
(for the x/ibc
, and
x/ibc-transfer
modules), we need to grant specific capabilities through the capability module
ScopedKeepers
so that we can authenticate the object-capability permissions for each of the IBC
channels.
# Register Routers
IBC needs to know which module is bound to which port so that it can route packets to the
appropriate module and call the appropriate callbacks. The port to module name mapping is handled by
IBC's port Keeper
. However, the mapping from module name to the relevant callbacks is accomplished
by the port
Router
(opens new window) on the
IBC module.
Adding the module routes allows the IBC handler to call the appropriate callback when processing a channel handshake or a packet.
The second Router
that is required is the evidence module router. This router handles genenal
evidence submission and routes the business logic to each registered evidence handler. In the case
of IBC, it is required to submit evidence for light client
misbehaviour (opens new window)
in order to freeze a client and prevent further data packets from being sent/received.
Currently, a Router
is static so it must be initialized and set correctly on app initialization.
Once the Router
has been set, no new routes can be added.
# Module Managers
In order to use IBC, we need to add the new modules to the module Manager
and to the SimulationManager
in case your application supports simulations.
# Application ABCI Ordering
One addition from IBC is the concept of HistoricalEntries
which are stored on the staking module.
Each entry contains the historical information for the Header
and ValidatorSet
of this chain which is stored
at each height during the BeginBlock
call. The historical info is required to introspect the
past historical info at any given height in order to verify the light client ConsensusState
during the
connection handhake.
The IBC module also has
BeginBlock
(opens new window) logic as
well. This is optional as it is only required if your application uses the localhost
client (opens new window) to connect two
different modules from the same chain.
Only register the ibc module to the SetOrderBeginBlockers
if your application will use the
localhost (aka loopback) client.
IMPORTANT: The capability module must be declared first in SetOrderInitGenesis
That's it! You have now wired up the IBC module and are now able to send fungible tokens across
different chains. If you want to have a broader view of the changes take a look into the SDK's
SimApp
(opens new window).
# Next
Learn about how to create custom IBC modules for your application