[Proposal] Add liquid staking functionality to TAC network

[Gravity-LST]

Overview

This proposal aims to add liquid stake possibility for the TAC network. The main x/liquidstake module is compatible with the existing staking and ERC-20 modules of the TAC node, introducing liquid staking tokens (gTAC) that are automatically represented as ERC-20 assets. This enables LSTs to be used natively within TAC EVM dApps and, via the TON adapter, across the TON DeFi ecosystem.

The second module enhances liquid staking by allowing users to convert already-staked TAC into the liquid staking module and mint LST tokens immediately, without waiting for the 21-day unbonding period. Without this feature, stakers would need to initiate an undelegation, wait 21 days, and only then deposit into liquid staking. Withdrawing from liquid staking still observe the same 21-day unbonding period as direct staking.

The LST will be managed by Gravity as part of Ylem, a Telegram-focused venture studio that had previous experience with TAC, implementing the miniapps for Morpho and Euler. Gravity will be responsible for the full cycle of development, marketing, and enhancing LST's presence in the DeFi TAC and TON ecosystem.

The module has been audited by Halborn and is ready to be tested in the TAC SPB network. Here are the PRs in the TAC GitHub repositories reflecting the changes:

• TAC chain, PR #61
• EVM, PR #9
• CosmosSDK, PR #2

Updating process

If this discussion will not raise critical doubts from validators and public audience over the course of next week, and there will be a positive outcome from the TAC Foundation, we will prepare a binary release of the updated TAC node and send an on-chain transaction with the proposal. The validators will have 12 to 24 hours to vote on the expedited proposal. They also have to update their TAC nodes with the provided binary release once the TAC network reaches the agreed height.

Technical implementation

The proposed implementation includes adding 2 modules:

1. Liquid stake module, which is forked from an existing open-sourced module x/liquidstake, developed by Persistence One. The implementation was then audited by Halborn.
2. Dexter Superfluid module, allowing users to move their staked TAC funds to liquid staking, bypassing the unbound period. This implementation was taken from the Dexter Core repository, which was audited by Halborn.

Why fork the x/liquidstake module

The module leverages native Cosmos SDK modular system alongside EVM compatibility to allow staked assets to be used in both Cosmos and Ethereum-compatible environments. Benefits include:

• Match the CosmosSDK AppModule interface
• An active repository that is widely used and consistently updated
• Compatibility with existing staking and ERC-20 modules of TAC nodes

Vesting Accounts Limitations

Certain TAC held by the team and investors are locked under the x/auth/vesting module. While these tokens can be used for native (direct) staking with delegation to restricted validators, liquid staking is not available for these funds. This is due to the fact that staking or transfer staked TAC to liquid staking module requires on-chain transactions that vesting contracts do not permit for locked tokens.

Configuration

The module introduces an admin role that can modify the following configurations:

• Whitelist of validators and their weights: This defines the validators participating in liquid staking and the share of staking delegated to them from the LST protocol
• Unstake fee rate: The fee for unstaking
• LSM pause: Indicates whether the module is paused
• Autocompound fee rate: The liquid staking protocol can charge a fee for staking rewards, after deducting the validator's fee
• Minimum liquid staking TAC amount

Additionally, there are hardcoded values that can only be changed through a new governance transaction:

• Liquid staking token (ERC20)
  • Name: Gravity Staked TAC
  • Symbol: gTAC
  • Decimals: 18
  • Address: 0x0000000000000000000000000000000067544143
• Pre-compile liquid staking module address: 0x000000000000000000000000000000000000d3f1

We propose to assign the admin role to a multisig Safe{Wallet}, with signers from Gravity, Ylem, and TAC representatives.

Note: Since the liquid stake module operates with the existing staking module, the business logic of the regular staking mechanism remains applicable to liquid staking as well, including reward distribution, slashing, and the unbound period of 21 days.

Staking Flow

Step 1: User submits stake transaction

• Trigger: User calls LiquidStake with amount of base TAC token*
• Interface: Web3

Step 2: x/liquidstake module processes stake

• Validates the staking amount

Step 3: Sending of TAC tokens from user wallet to node account

• Calls functions from x/bank module to transfer base tokens from user to Node account

Steps 4-6: Delegation

• x/liquidstake uses x/staking to delegate tokens to validators
• Delegation is batched or directed to selected validators (weighted strategy)

Step 7: Minting of stakeToken

• x/liquidstake mints gTAC (also known as stakeToken) equivalent to the staked amount
• Uses x/bank to credit minted gTAC to the user account

Step 8: x/erc20 integration and completion

• gTAC is registered using x/erc20.RegisterCoinPair
• This enables automatic wrapping of gTAC as an ERC-20 token
• ERC-20 token is usable via any EVM-compatible wallet (e.g. MetaMask)
• Event emitted for MsgLiquidStake transaction
• User receives gTAC in ERC-20 form

*If a user already has TAC staked in direct staking, they can convert it to liquid staking by calling stakeToLp with the amount of the base TAC token. The function can also be called from the TON side via a proxy contract.

Unstaking flow

Step 1: User submits unstake transaction

• Trigger: User calls LiquidUnstake with amount of gTAC tokens to burn
• Interface: Web3

Steps 2-3: Validating of request and sending of gTAC tokens to node account

• Validates user balance of gTAC
• Calls x/bank.SendCoinsFromAccountToModule to transfer stToken from user to module account

Steps 4-5: Burning of gTAC tokens

• Calls x/bank.BurnCoins to burn gTAC from the module account

Steps 6-7: Initiate unbonding

• x/liquidstake calculates equivalent base token value
• Calls x/staking to undelegate from validators
• Creates an unbonding entry for future withdrawal

Steps 8-9: Track unbonding period and receiving of tokens from validators

• Wait for UnbondingTime (default 21 days or chain-configured)
• Optionally emit events/logs for claimable entries

Steps 10-11: Withdrawal by user

• After unbonding period, user calls WithdrawUnbonded
• x/liquidstake or withdrawal handler sends base token from module to user via x/bank
• Unstake process is finalized
• User receives native base TAC tokens (unstaked)

Interaction with TON network

The solution is fully compatible with the TON network:

• The Gravity team will develop a Telegram mini app (TMA) and a proxy smart contract to interact with the liquid stake module from the TON side by natively using TON Wallet
• The LST token gTAC can be bridged to the TON side as a TON Jetton to interact with TON DeFi

Benefits of suggested approach

• No need to write and audit custom Solidity contracts
• Native Cosmos integration ensures compatibility with IBC and Cosmos governance
• Seamless use of stToken in DeFi on EVM and on the TON network via TON Adapter

[croll83]

I read the proposal and i'm quite comfortable with the approach.

It's a bit uncommon to see a liquid staking solution requiring the addition of a new module, but looking more closely, it's the best balance between a custom (non-battletested) EVM Solidity staking contract and a cosmos wasm (more battle tested but not evm compatible) native staking solution.

The proposed approach does not prevent more LST (either pure evm/solidity based or using the same module approach) to go live on TAC and it's not creating additional overhead for the validator set (except for the upgrade, which is still ordinary). Also the possibility to mint LST for already staked TAC tokens simplify the adoption for gTAC.

The TAC dev team support this proposal, unless some major issues arises from this public discussion, we would love to see the proposal going onchain to support this change.