Proposal #1 Enable REGEN Transfers

Hi all, I welcome discussion on this proposal, please reply here with any concerns or your support — thank you!


This proposal enables sending and receive REGEN assets. If this proposal passes, the Bank module parameter SendEnable will be updated to true.

Security Considerations

This parameter has been enabled in the past by other Cosmos based projects and tested in past test nets. Further, the current voting power distribution is now decentralized above 50%.


This proposal follows on Patogit’s discussion thread started here and discussions from this event attended by validators such as {IA}, Melea, Akik Takat, and others.


Greetings, wanted to add this resource to the mix for our review: governance/params-change at master · cosmos/governance · GitHub

Which is referenced by CosmosParametersWiki/ at master · gavinly/CosmosParametersWiki · GitHub

gavinly resource was provided by @dpdanpittman in discord chat


Thank you swidnikk - appreciate your leadership here. For LOACOM - both of these proposals are critical to unlocking the next phase of growth and development. Signaling a strong yes to both.


Thank you @swidnikk . This looks great.
As a long time community member and token holder, I’ll be glad to support both of these proposals.


Thanks @I-A! Useful indeed — thanks for sharing :slight_smile: I have the JSON to get it on chain and will post to IPFS.

Hey all, not sure what has been covered already in various channels, this is all new to me.

But I’ve gone through the governance docs also linked above.

Looks like RN genesis file is showing that 200 $REGEN will need to be deposited within 14 days. The proposer can deposit the full amount or allow others to contribute as well.

Looks like we’d have the required 40% quorum if at least the top 7 validators participate in the vote (currently 43.93% of voting power).

I saw the regen tx gov submit-proposal param-change ... command explained in the governance docs linked above … but could not find the regen tx gov vote ... command that the validators would each use to cast their vote.

However, found this resource on validator voting, written by @KingSuper

So, is it even possible that any validator would be against this proposal? I can’t think of a reason why.

Once @swidnikk submits the proposal, it would appear here in the explorer too, correct?

Thanks all {:seedling:}


Hi everyone! Just wanted to mention that the upgrade date (preferably block height) should be mentioned in the proposal that is submitted on chain.

Preferably this date is the same as the second proposal (enabling IBC transfers) so that we do not have to do two separate upgrades.

Everything else looks fine.


Thank you and noted. This upgrade is simply a parameter update and I believe when it goes on chain it will take effect once approved, though I will confirm.

It was recommended that we perform these two parameter updates as separate governance proposals because it has never been done at the same time before.


Agreed that we should -

1 - Use `halt-height``` rather than halt-time

2 - Do both parameter changes in a single upgrade

Ideally, I’d like to see the upgrade tested on a testnet prior to executing on Mainnet.

1 Like

Thanks for taking the lead here @swidnikk :sun_with_face:

In addition to the comments I made above, here are my thoughts -

1 - I don’t see a reason to not enable transfers. At the same time, I can’t recall the “usual” arguements to support delaying transfers. @swidnikk or @mircea could you please remind me what they might be?

2 - My assumption here is that IBC is required for Regen to trade on Gravity DEX. If this assumption is correct, then conceptually I’d support both proposals. Technically I don’t think introducing both would increase risk over doing each incrementally.

Yet, if both have never been enabled simultaneously, I’d feel more comfortable doing this on a testnet first, rather than going right to mainnet with it.

I’d like to see Regen lead the way in testing on testnet, rather than mainnet. The time to start would be with the first upgrade, as not doing so becomes a slippery slope and the “convenience” of testing in production becomes quite addictive.

Finally, would this be a manual upgrade or would an automatic upgrade module be used?

1 Like

We don’t need to upgrade the network, this would be an on-chain Param change proposal. Once after the proposal goes through, these param values will be changed to true if the proposal is successful

1 Like

Yeah, @chris-chainflow this is just a simple parameter change and transfers were tested in previous test nets.

1 Like

Can we run the param changes on testnet? Might as well. :slight_smile:

1 Like

This proposal is now live and on chain,

@anilcse if you want to confirm on the testnet, I shared details with you

1 Like

I’m agree with activate TX :slight_smile:
No reason for not doing, imo :slight_smile:


We voted yes. Good to see progress of the Regen vision.


I have an additional question and suggestion -

1 - Have we decided to run the paramater changes on a testnet before initiating them on mainnet?

I’d like to understand a clear direction on this decision before voting.

2 - Also, I think it makes sense to add links to the commit hash of the code, genesis file, etc. that will be updated as part of this proposal to the proposal itself.

Hi Chris,
There is no network upgrade (the parameter change is handled automatically if/when the proposal passes), there is no new commit hash, code or genesis file, etc.

Also, I believe it’s already been tested on testnet and there has been some suggestion of testing it again if anyone needs.