Post-Deployment Integration

After organisation deployment is completed, additional post-deployment configuration may be required for interoperability infrastructure and minting permissions.

This configuration process enables Lucid’s interoperability infrastructure to interact with deployed token systems and Asset Controller contracts.

The post-deployment integration flow primarily focuses on:

• permission management
• minting rights configuration
• interoperability controller access
• role assignment verification

AccessControl Infrastructure

Lucid uses OpenZeppelin’s AccessControl framework for managing operational permissions across deployed infrastructure.

AccessControl is used to:

• assign operational roles
• manage mint permissions
• coordinate interoperability access
• secure contract interactions
• restrict privileged functions

Additional information about AccessControl can be found in the OpenZeppelin documentation.

Message Controller Permissions

After deployment, the Message Controller contract may require permission to interact with the organisation’s Asset Controller infrastructure.

This permission allows interoperability infrastructure to:

• coordinate mint operations
• execute cross-chain asset settlement
• interact with interoperability routing systems
• manage bridge-based mint and burn flows

The Message Controller must be granted the appropriate operational role before interoperability functionality becomes fully active.

grantRole() Configuration

Minting permissions are assigned using the:

grantRole(bytes32 role, address account)

function from OpenZeppelin’s AccessControl framework.

Parameters:

Parameter	Purpose
role	The permission role hash
account	The address receiving the permission

The granted role determines which privileged operations the assigned address can execute.

Role Hash Configuration

Each deployed token infrastructure defines specific role hashes during deployment.

These role hashes determine:

• mint permissions
• interoperability permissions
• operational access rights

The correct role hash must be supplied when assigning permissions to the Message Controller contract.

Example:

grantRole(0x<role-hash>, 0x<message-controller-address>)

Replace:

• <role-hash> with the appropriate permission role
• <message-controller-address> with the deployed Message Controller address

Asset Controller Integration

The Asset Controller manages:

• mint permissions
• interoperability coordination
• bridge-integrated token operations
• mint and burn infrastructure

The Message Controller must be authorised on the same chain as the deployed Asset Controller infrastructure.

This integration enables:

• cross-chain mint coordination
• interoperability-aware token settlement
• bridge-agnostic asset transfers

Role Verification

After assigning permissions, organisations should verify that the role assignment completed successfully.

Verification is performed using:

hasRole(bytes32 role, address account)

The function should return:

true

if the role assignment was successful.

This verification step ensures:

• interoperability permissions were configured correctly
• operational access is active
• mint infrastructure is functional

Security Considerations

Permission assignment controls critical interoperability infrastructure and should be handled carefully.

Important considerations:

• verify all contract addresses before assigning permissions
• confirm role hashes match the intended operational role
• ensure permissions are granted on the correct chain
• avoid assigning privileged roles to unintended addresses

Incorrect role assignment may:

• disable interoperability functionality
• expose privileged operations
• affect mint and burn coordination

Interoperability Activation

Once:

• roles are assigned
• permissions are verified
• interoperability infrastructure is configured

the organisation’s token and bridge infrastructure becomes fully operational within Lucid’s interoperability environment.