Celestia Improvement Proposals (CIPs)

Abstract

Currently, the state machine has a token filter which restricts the creation of non-native assets on it for both Hyperlane and IBC. This means that any asset other than TIA cannot be bridged to Celestia via its currently supported interoperability protocols: Hyperlane and IBC. This CIP proposes removing this token filter to allow any asset to be bridged to Celestia.

Motivation

Currently, restricting token creation to only TIA on the state machine prevents Celestia from serving as an effective routing layer for cross-chain assets that are in demand by Celestia-native applications. Removing this restriction allows Celestia-native applications to access any asset from any chain also connected to Celestia by simply making a connection to Celestia itself. This allows Celestia to serve as an effective routing layer, enabling various assets to reach Celestia-native applications.

Specification

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119 and RFC 8174.

To disable the token filter for Hyperlane, the WarpKeeper configuration MUST be modified to include synthetic token support by adding the HYP_TOKEN_TYPE_SYNTHETIC token type to the allowed token types array.

app.WarpKeeper = warpkeeper.NewKeeper(
    encodingConfig.Codec,
    encodingConfig.AddressCodec,
    runtime.NewKVStoreService(keys[warptypes.ModuleName]),
    govModuleAddr,
    app.BankKeeper,
    &app.HyperlaneKeeper,
-   []int32{int32(warptypes.HYP_TOKEN_TYPE_COLLATERAL)}, // Only collateral tokens
+   []int32{int32(warptypes.HYP_TOKEN_TYPE_COLLATERAL), int32(warptypes.HYP_TOKEN_TYPE_SYNTHETIC)}, // Add synthetic tokens
)

To have similar functionality for IBC, the IBC token filter that prevents non-TIA tokens from being transferred via IBC MUST be removed to allow non-TIA assets to flow through IBC channels.

This token filter is currently implemented in app/app.go at line 357.

Backwards Compatibility

This CIP is backward compatible. Existing functionality for TIA transfers will remain unchanged. The addition of non-TIA assets is purely additive and does not affect existing users or applications.

However, note that this is a state machine breaking change and requires a major upgrade.

Test Cases

• An E2E test that transfers a non-TIA asset via IBC from an IBC-enabled chain like Osmosis to Celestia. Verify the token appears in Celestia’s state machine. Confirm the token can be transferred via IBC to the same chain and also to another IBC-enabled chain.
• The same test as above but with Hyperlane from/to a Hyperlane-enabled chain.

Backward Compatibility

• Verify TIA transfers continue to work as expected
• Confirm no regression in existing Hyperlane and IBC functionality

Security Considerations

Removing the token filter for Hyperlane and IBC introduces security risks that must be carefully managed:

Primary Risk Category

Network Resource Exhaustion: Unlimited token types may lead to state bloat, transaction spam, and bridge congestion. Large volumes of worthless tokens could consume bridge liquidity and manipulate fee markets.

Risk Assessment

This risk is consistent with other multi-chain ecosystems. The proposal’s additive nature preserves existing TIA security while introducing this risk primarily for users who choose to interact with bridged tokens.

Copyright

Copyright and related rights waived via CC0.