Skip to main content

BABY Wallet & Staking Integration Guide

The Babylon Genesis is a PoS chain built using the Cosmos SDK and utilises most of the vanilla Cosmos SDK functionality shared among chains developed using it. Therefore, a wallet already supporting chains built using Cosmos SDK should find it straightforward to add Babylon Genesis as a supported blockchain.

In this document, we will walk through the considerations of integrating the Babylon Genesis blockchain into your wallet:

Babylon Genesis Network Information​

Following is a list of the key network details of Babylon Genesis:

  • RPC nodes can be found for the network you are interested in our networks registry.
  • Token minimum denomination: ubbn (6 decimals)
  • Human-readable denomination: BABY

Accounts, message signing, token balance, and token transfer​

The Babylon Genesis chain utilises the default Cosmos SDK functionality for accounts, message signing, token balance, and token transfer. Please refer to the relevant Cosmos SDK documentation for more details.

Staking​

Babylon Genesis uses an epochised staking mechanism. Staking messages are queued and processed at epoch boundaries instead of taking effect immediately. Wallets wishing to support Babylon PoS delegations natively must use the custom x/epoching mechanism.

The mechanism details are centralized in the BABY Staking Mechanism guide.

The epochised staking approach introduces the following UX considerations for wallet integration:

  • Delayed Staking Activation: Although wrapped staking messages are executed immediately, the actual staking operation takes effect only at the epoch's end. Wallets should clearly communicate this delay to users to set proper expectations.
  • Delayed Funds Locking: Users' funds remain liquid until staking activation occurs at the epoch's conclusion. This creates a for staking failure: if users transfer or spend their funds before staking takes effect, the staking transaction will fail. Wallets should warn users about this possibility.

Wallets can provide users with visibility into pending staking messages using the LastEpochMsgs query in x/epoching. This query allows wallets to display the messages queued for execution at the end of the current epoch.

Unbonding​

Babylon speeds up BABY unbonding by leveraging Bitcoin timestamping. Wallets should treat unbonding as a multi-step state transition and communicate that completion depends on the configured Bitcoin confirmation depth and network conditions.

See BABY Staking Mechanism for the canonical unbonding flow.

Wallet Integration Recommendation​

To provide the best experience for users here are some suggestions to wallet developers:

  1. Epochised Staking UI:

    • Show a clear indication that staking operations are queued for end-of-epoch execution

    • Display estimated time until the end of current epoch

    • Provide a way to view all pending staking operations

  2. Fast Unbonding UI:

    • Accurately communicate the unbonding period

    • Indicate that unbonding leverages Bitcoin security

    • If possible, show progress of Bitcoin confirmations for unbonding requests

  3. Slashing Warnings:

    • Include clear warnings about the slashing risk

    • Highlight the importance of choosing reliable validators

Implementation Best Practices​

  1. Proper Error Handling:

    • Handle epoch transition edge cases

    • Manage potential failures due to users spending funds before epoch processing

  2. Refresh Strategies:

    • Implement proper cache refreshing after expected epoch boundaries

    • Update delegation status after expected unbonding completion times

  3. Testing:

    • Test thoroughly against Babylon testnet before mainnet integration

    • Verify all epoch-based operations complete as expected

  4. User Communication:

    • Clearly explain the unique aspects of BABY staking (epochised staking, fast unbonding)

    • Provide educational content about the relationship between Bitcoin security and BABY staking

Common Integration Challenges​

  1. Epochised Staking Transition:

    • Users transferring funds after staking transaction but before epoch processing

    • Solution: Clear warnings about not transferring funds until end of epoch

  2. Fast Unbonding Expectations:

    • Managing user expectations around unbonding times, which depend on Bitcoin block times

    • Solution: Provide estimated time ranges rather than exact times

  3. Validator Selection:

    • Helping users choose reliable validators to minimize slashing risk

    • Solution: Display validator uptime, commission rates, and voting power