ARC-61: Set Up the Second Year of ASTRO Emissions on Terra


This proposal creates an ASTRO vesting schedule for the second year of Generator emissions on Terra 2. This new vesting schedule is meant to start on July 1st 2023 and last until June 30th 2024.


This proposal aims to transfer ASTRO from the Assembly Treasury to the Astroport Vesting contract and create a schedule for the second year of emissions on Terra 2.

As proposed in a tokenomics post from December 2021, each year, the total amount of ASTRO distributed through Generator emissions should be 20.408% lower than the previous year’s emissions.

This proposal aims to transfer 58,787,016 ASTRO to the Terra 2 Vesting contract in order to set up the second year’s ASTRO emissions. The allocation for the remaining 20,804,824 ASTRO (which makes up for the gap to a total of 79,591,840 ASTRO) is currently being discussed in ARC-62 & 63.

Executable Message

The executable message for this proposal looks as follows:

      "wasm": {
        "execute": {
          "contract_addr": "terra12ncurr62xe93xrsh2drp4zvehj0gn32lfnshr8k0p4xfyju2knwq2qgmh2",
          "funds": []
      "wasm": {
        "execute": {
          "contract_addr": "terra1nsuqsk6kh58ulczatwev87ttq2z6r3pusulg9r24mfj2fvtzd4uq3exn26",
          "funds": []


Copyright and related rights waived via CC0.


I support fully this proposal

That’s too much emission for Terra, volume has been ridiculously low lately.

Taking into account the current trading volume on Terra V2, the proposed emission indeed appears to be substantial. We recognize that the current emission system is built around a per-block rewards mechanism, which is consistent with the Fee:Emission Ratio employed by other DEXs. However, we’re curious to know if an alternative approach was explored?

What we have in mind is Adaptive Emission Schedule that could dynamically adjust the per block ASTRO emission based on real-time metrics such as trading volume, total value locked (TVL), user growth, etc. The benefit here is that it could make the system more responsive to the actual usage of each ASTRO satellite and its growth.

We believe this could be a significant step forward in creating a more sustainable and attractive tokenomics model for ASTRO.


Definitely onboard with exploring this idea. The emissions directed towards Terra2 dont reflect the reality that potential volumes/TVL on Terra are much lower than a chain such as Neutron. Instead of relying on conjecture, a system such as the one Diversitas has suggested would be prudent

1 Like

totally agree with this proposal

Its amazing congratulations astroport ai. You good project

Wanted to add a couple more details and an update:

  • The Assembly can choose to change the amount of ASTRO that’s scheduled to be distributed on Terra further down the line
  • The 79,591,840 ASTRO is in fact meant to be distributed between Terra, Injective and other satellite deployments

The reason this proposal doesn’t allocate some of the ASTRO to Injective right away is that at this stage, the Astroport deployment on Injective has several months of emissions runaway and we don’t yet know how much more ASTRO should be allocated for that satellite.

Now, for the update. Given that ARC-62 and 63 are up on the forum and that the 79,591,840 ASTRO is meant to be distributed across all Astroport satellites, we propose the following:

  • 10,402,412 ASTRO is allocated for the Neutron Astroport deployment as mentioned in ARC-62
  • 10,402,412 ASTRO is allocated for the Sei Astroport deployment as mentioned in ARC-63
  • The remaining 58,787,016 ASTRO is allocated for now on the Terra Astroport deployment
1 Like

Couldn’t we change the amount of ASTRO distributed to Terra 2 already in this prop? Killing 2 birds with 1 stone.

Given volumes have been trending down since ARC-42, I guess most pools don’t meet the 0.1 Fee:Emission ratio anymore. An update on this would be nice, including the ROAR-LUNA LP as ARC-60 looks like it’s going to pass.

1 Like

Bundling different changes in a single proposal is generally suboptimal. People might agree with one of the changes and disagree with the other and in the end this can block both changes from being implemented.

1 Like

Thank you for the update. Already this sounds more responsible.