LST for Regen Network

General
1

I would like to develop an LST of Regen here is a LST document for Regen. Looks like it would not be too hard to code and there are already confirmed validators that could do it with- LSTRegen - Google Docs

4

Development Walkthrough: dREGEN LST for Regen Network with Drop.money Confirmed Validators

This guide provides a step-by-step technical workflow for building dREGEN—a liquid staking token for Regen Network—using CosmWasm smart contracts on Neutron, fully aligned with Drop.money’s architecture and leveraging existing contract patterns. The validator set integrates Stakecito and Simply Staking as confirmed Drop.money operators.

1. Project Architecture Overview

Primary Modules:

  • **Liquid Staking Contract (Core)
    **

  • **Validator Manager Contract
    **

  • **Reward Distributor Contract
    **

  • **Token Factory Contract
    **

Ecosystem Context:
Follows Drop’s standard: CosmWasm smart contracts on Neutron, using IBC, ICTX, and ICQ for cross-chain flows. All liquid staking receipt tokens are minted natively via Neutron’s Token Factory module.drop+2

2. Validator Delegation Pattern

Purpose:
Splits delegation between Stakecito (60%) and Simply Staking (40%) with robust config and emergency controls.

a. Configuration Structure

rust

// Validator configuration

pub struct ValidatorConfig {

pub stakecito_address: String,        *// 60%*

pub simply_staking_address: String,   *// 40%*

pub stakecito_commission: u64,        *// 5%*

pub simply_staking_commission: u64,   *// 10%*

pub min_delegation: Uint128,          *// Safeguard for small values*

pub emergency_pause: bool,            *// Circuit breaker*

}

  • These parameters are stored and updated using CosmWasm’s storage patterns.

b. Delegation Execution

rust

// Split and delegate user’s REGEN deposit to the two validators

fn execute_delegate(amount: Uint128, config: &ValidatorConfig) → Vec {

let stakecito_amount = amount \* Uint128::new(config.stakecito_allocation) / Uint128::new(100);

let simply_staking_amount = amount - stakecito_amount;

vec!\[

    StakingMsg::Delegate { validator: config.stakecito_address.clone(), amount: stakecito_amount },

    StakingMsg::Delegate { validator: config.simply_staking_address.clone(), amount: simply_staking_amount }

\]

}

  • Uses the Staking message in CosmWasm to direct delegations according to ratio.

3. dREGEN Token Minting

Pattern:
Uses Neutron’s Token Factory module following Drop.money standards. Minting, burning, metadata management, and admin controls reference the creator’s address.neutron+1

a. Creating the Denomination

rust

// TokenFactory Msg to create the dREGEN asset

MsgCreateDenom {

sender: contract_addr,

subdenom: "dregen",

}

Resulting denom:
factory/{contract_address}/dregen

b. Minting & Burning

rust

MsgMint {

sender: contract_addr,

amount: Coin { denom: "factory/{contract_address}/dregen", amount }, 

mint_to_address: user_addr,

}

MsgBurn {

sender: contract_addr,

amount: Coin { denom: "factory/{contract_address}/dregen", amount }, 

burn_from_address: user_addr,

}

  • The contract maintains supply via state updates; changes to exchange rate reflect staking rewards.

c. Metadata Setup

rust

MsgSetDenomMetadata {

sender: contract_addr,

metadata: {

    name: "Drop Regen",

    symbol: "dREGEN",

    description: "Liquid staking token for staked REGEN via Drop.money",

    ... *// Units, display, aliases*

}

}

  • Ensures wallet/Dapp compatibility and correct display.

4. Reward Distribution Implementation

Automated Claiming and Compounding

  • Drop.money auto-compounds rewards by periodically claiming (every 100 blocks, for example) using CosmWasm’s DistributionMsg.

rust

DistributionMsg::WithdrawDelegatorReward { validator }

After Claim:

  • Rewards are split again according to the validator ratio.

  • Rewards are re-delegated via StakingMsg::Delegate.

  • Contract updates state:

    • total_regen_staked += claimed rewards

    • exchange_rate recalculated

Yield Distribution Strategy
Can follow Drop’s approach (95% auto-compound, 3% treasury, 2% validator bonus), easily configurable in contract state.

5. Code Section Breakdown for Vibe Coding

  • Storage Definitions: STATE/CONFIG/REWARD_TRACKER using cw_storage_plus

  • InstantiateMsg: Validates validator addresses and initial allocations

  • ExecuteMsg:

    • StakeRegen: User deposit, sends MsgDelegate per configured ratio

    • ClaimRewards: Withdraws, splits, redelegates rewards, updates rate

    • MintDREGEN: Issues dREGEN tokens via TokenFactory minting

    • BurnDREGEN: Handles unstake/redemption burn logic

  • QueryMsg: For users/Dapps to get current exchange rate, total staked, reward history, etc.

  • Admin/Control: Emergency pause, admin updates, validator changes (with access control)

  • Tests: Mock env/deps with integration tests verifying all flows (deposit, delegation, mint, rewards, redelegate)

6. Integration with Drop.money Contract Patterns

Reference Contract Repositories:

Best Practices:

  • Follow Drop’s contract interfaces for validator integration and messaging templatesdrop

  • **Use Token Factory ops and metadata patterns that match dATOM, dTIA, etc. for wallet/DEX compatibility
    **

  • **Leverage validator manager and reward distributor contract code for splitting delegations and compounding
    **

  • **Mirror Drop.money’s slashing and performance monitoring code to enforce validator reliability
    **

7. Example Contract Flow

  1. User stakes REGEN:
    Contract receives funds, splits delegation 60%/40%, sends StakingMsgs, mints dREGEN via TokenFactory.

  2. Rewards accrued:
    Cron job triggers ClaimRewards; contract claims, splits, redelegates, mints/burns dREGEN as needed, updates exchange rate.

  3. User queries:
    Dapp or wallet calls QueryMsg for exchange rate, validator ratios, and accrued rewards.

  4. Unstaking:
    User burns dREGEN, contract undelegates underlying REGEN following Drop.money LSM module logic.

8. Recommendations

  • **Code directly on top of Drop.money and Neutron’s existing CosmWasm/TokenFactory structure; mirror all relevant contract sections where their logic fits Regen/validator split.
    **

  • **Save substantial dev time by forking Drop.money’s latest contracts from Hadron Labs GitHub and refactoring as needed for dREGEN denomination, validator config, and REGEN-specific logic.
    **

  • **Structure your code for modular testability with clear separation between delegation logic, token minting/burning, and reward management.
    **

Summary

By closely following Drop.money’s established CosmWasm architecture, leveraging confirmed validator addresses, and using Neutron’s Token Factory, the development process for dREGEN will be fast, secure, and compatible with all Cosmos ecosystem tools. Each major coding section described above can be vibe coded modularly, swapping in Drop.money logic wherever possible for validator integration, token minting, and compounding.

This results in:

  • **Efficient development leveraging proven, audited contracts
    **

  • **Easy maintainability and extensibility for future upgrades
    **

  • Interoperable, drop-in participation in DeFi and ReFi protocols throughout Cosmos

5

I have now created an initial repository for this and got it to deploy successfully on Neutron testnet. Now looking for further reviewers before it gets mainnet.

1 Like
6

Regen Liquid Staking codebase has been successfully deployed to the Neutron Cosmopark environment.

:white_check_mark: Deployment Complete

Contract Deployed:

  • Code ID: 24

  • Transaction Hash: F68B8E0F0E6C503531A99C3BD6FD08EB4EDACA2EA6D5E00CCC92CCA650B0D901

  • Block Height: 6475

  • Deployer Address: neutron14xcrdjwwxtf9zr7dvaa97wy056se6r5erln9pf

Environment Status:

  • Cosmopark fully operational with Neutron and Gaia nodes

  • IBC relayers running

  • All prerequisites installed (Go 1.24.6, Docker 28.4.0, NPX 10.8.2)

Deployment Details:

  • Contract artifacts built and optimized

  • Fees corrected to 250,000 untrn and 250,000 ibc/…

  • Transaction successfully processed despite script connection issues

The Regen Liquid Staking contract is now live on the Neutron testnet and ready for testing and integration.

1 Like
7

Where this really takes us is opening REGEN up as usable liquidity across markets. An Osmosis pool with REGEN/LST-REGEN would be the logical first step, giving delegators and validators a way to enter and exit positions smoothly. From there, bridging via Axelar lets us deploy liquidity on Celo (and other EVMs), which connects LST-REGEN to lending, stablecoin collateral, and broader DeFi use cases.

Validators are likely the first participants, but the real opportunity is that it doesn’t just recycle existing staking — it turns staked REGEN into a productive asset that can circulate in DeFi. That loop (staking → LST → liquidity → trading/yield → back to staking) is what has driven demand for LSTs elsewhere, and it’s the best path we have to secure tighter spreads, deeper markets, and real trading conditions for REGEN.

8

Congrats on getting the contract deployed to Neutron testnet — that’s real progress. But I think it’s worth naming the elephant in the room: QuicksilverREGEN also worked technically, yet no one actually provided liquidity for it, so it went nowhere. The risk is that we repeat the same cycle — strong infrastructure, no follow-through.

Will anyone step up this time to seed the REGEN/dREGEN pool on Osmosis (and later via Axelar to Celo/Base)? Because without liquidity and incentives, even the best LST won’t generate demand. That’s the real question we need to answer if this is going to succeed.

9

Thanks. Yah would be great to know why no liquidity was provided- for me it was an awareness thing and then by the time I knew about it there was nothing in terms of dRegen and users sharing they weren’t able to withdraw their Regen after it being dRegen, so I did not feel good depositing it. As it is estimated that a large percentage of regen is staked, I would think a lst would be wanted and it would be something that could be used in the wider defi ecosystem. However, I do think there is a tipping point for people to really get on board with having an LST. This tipping point would need $ resources to get there.

1 Like
10

Important to note and distinguish between stake and bonded validators. Around 51% of total supply is bonded, meaning those tokens are actively securing the network through validators.

The rest of what was previously bonded (and earning yield) includes delegations to jailed or inactive validators. Those validators themselves won’t be re-activated — the open question is whether the delegators to those validators will eventually re-delegate or restake, potentially through an LST mechanism that re-engages dormant stake endogenously within the ledger.

I wasn’t here when the validator count was reduced, but I assume it related to expectations of operator consistency and BD activity. That context feels important when evaluating an LST design — if we strengthen operational performance and validator reliability, the network can scale participation and yield much more predictably.

11

Thanks for the work you are putting in here. I am someone who put hundreds of thousands of regen tokens ito qregen liquidity. So, it’s not fair to say nobody added liquidity. The poor performance of the regen token makes it seem that way however what was once tens of thousands of dollars in liquidity became thousands. The larger discussion here in my mind, is why is Regen trying to start a new LST token, when there are MAJOR unresolved issues with the existing LST token? How are we supposed to trust there will be any support if things don’t go as planned?