Tokenomics Community Calls - Thread

In this thread I’ll provide weekly updates on our Tokenomics Community Calls.


1st public call

Today we introduced the idea of the Tokenomics Community Call, and shared encouragement for more Phi Labs teams, or committees to hold weekly public calls on discord.

We screenshared the Token Allocation Paper briefly to show initial token allocations slightly before publishing.

The bulk of the call was going over the Archway Economics Paper, explaining the subsections, vision and future.

We ended the call with community suggestions, which largely held that future calls should have more live simulations and data showcased.

The next call is slated for next Monday at 3PM UTC (same time), and if there’s specific metrics or questions you’d like to go over, please comment them here, or always feel free to bring them to the next call!



Today we discussed the Smart Contract Hackathon, some recent Airdrop news, and Price-of-Gas, as discussions about it are being more heavily discussed on CT amidst other networks, including JUNO

We set the stage for future talks about Community Pool monitoring and Governance innovation, kicked off the discussion about pragmatics of Community-Owned-Liquidity, and went over a sim of Uniswap data comparing activity on Ethereum, to what it would look like on Archway.

By request, we’ll be moving future meetings to Fridays at 4:30 PM UTC, immediately preceding the Community Pictionary call.

1 Like

Unfortunately, I didn’t attend the Tokenomics Community Call.
Could you clarify the situation with the Foundation tokens (150M) here?
Will they be available for sale on TGE or do they have a lockup?

They’re a Foundation. They’re not “Available for sale”, but they’re also not subjected to an arbitrary smart contract lockup.


Today we discussed the CoinList sale, airdrop information, and several other ecosystem updates.

@Lumi joined to discuss what Architech is doing with ‘credits’ as a dapp in the Archway ecosystem.

The Uniswap data/simulations from last week were previously discussed again, as was the intention of using to check for some specific metrics as we build out live analysis charts for Archway.

Meetings are officially on Fridays at 4:30PM UTC currently, before community Pictionary.

1 Like


Our primary conversation today was about how to get liquid ARCH, and namely on the potential of setting up a liquid community pool fund. Some conditions and guidelines towards the safety, security, and processes of this were discussed, and it has been suggested that we polish a proposal and bring it to the forum before the Governance call on Wednesday.

TJ shared some constructive concerns about mPoG being too high, and this is something we should monitor closely post-launch, and pending feedback is likely to be the first parameter adjusted. We’re also actively looking into better documentation for fee-grants so that we could seamlessly onboard more users without having to worry about the gas fees until later. This, plus especially if the grants are provided, may be enough to ease any concerns about comparably high gas fees leading to negative first impressions.

Bonus Block’s model, value-add, and potential network synergy was discussed as well, and we’ll closely monitor their metrics.

1 Like


Missed last week due to traveling, but yay for a successful chain launch!

In today’s call we discussed some new data from the chain post-launch. Namely:

  1. Gas pricing and its effects
  2. Fee Grants
  3. The Protocol implementation of the economic model, and reconciliation

1 Gas pricing and its effects:
Obviously Gas prices on Archway are more expensive, and anybody who has been following the tokenomics of the chain isn’t surprised by that, however an assumption made in simulations is reasonable access to liquidity. With the chain being freshly launched, there is currently a lack of access to ARCH liquidity that would permit substantive chain usage. This led to several downed relayers at times, and rate-limited users’ ability to explore the new chain. As liquidity grows this will get easier, but in the meantime some potential fixes could include lowering the mPoG to 500 GWAY, getting additional funding for relayers, and/or substantive Fee Grants, which brings me to point number 2.

2 Fee Grants:
While testing Astrovault and the Airdrop it became apparent that there were several bugs in fee grants, be it module or implementation, that were previously undiscovered. Multiple ecosystem teams spent an insane amount of hours finding errors, patching the SDK implementation, and working tirelessly with the wallet teams directly (shout out to Cosmostation and Leap for incredible response times and detailed troubleshooting!). Luckily the Fee Grant implementations worked pretty well, and users enjoyed the typical top-of-class UX they’ve come to expect from Archway! There are still some issues with some wallets where fee grants aren’t possible on ledger, or with 0 balance, but for the most part we should be able to recreate the work that was done by these core ecosystem teams for future dapps. Unfortunately however, fee grants aren’t quite as free currently as had previously been discussed, because of point 3.

3 Protocol Implementation of the Economic Model
The Archway protocol has undergone many versions and variations, as protocols do, prior to launch. After dedicating much time and effort to the development of the time-based model, with time-reflexive parameters, it was decided to move forward with a fully audited and code-frozen previous implementation, with several tokenomic updates such as mPoG rather than MCF, and Premiums, but leaving out time-based metrics and inflation, token burn, and a couple more things. One oversight during the upgrades was that we didn’t revert the basis of determining DIT distribution from Max Gas/Block (from the MCF version) to half of Gas Spent, causing us to remunerate devs from inflation at rates mimicking maximum congestion.

In layman’s terms, devs are getting only about 50% of what is intended at this time, and the other close to 50% is being rolled over into the Dapp Treasury.

Props to TJ from Lydia Labs for noticing this discrepancy from Archgregator, and of course to Igor from Nuclear Block for building!

Though this means that Fee Grants will only be 50% reimbursable immediately, we’re actively tracking DIT rewards and block fill, which will enable us to retroactively reimburse devs the rest of their rewards from the Dapp treasury in the coming months.

Thanks to everybody who came to the call, and congratulations to everybody for the chain being live! I will not be hosting next week due to being at AwesomeWasm, but will have the next call on July 21.



Forgot to update for last weeks call, but had to do primarily with lowering mPoG from 900 GWAY to 500 GWAY, and structuring the Liquidity Council proposal. The LC proposal is now live on the forum, but I haven’t moved forward with the lowering mPoG as ARCH price has decreased to the point where we’re actively in the discussed fee price-range.

In today’s call we discussed some next steps for Archway tokenomics. The burn feature will be added in the next upgrade, but time-based functionality and the core model won’t come until Q4. The next build/upgrade we can and should pursue is designing tax brackets that factor many different forms of decentralization in weighting the community pool tax in non-uniform ways on different validators. The following are some thoughts on what to pursue:

Tax Brackets Weight Considerations:

  1. How many tokens are staked to the validator?
  2. What hardware is being used?
  3. Where are the nodes being hosted?
  4. How active are the validators in governance?
  5. How active are the validators’ individual delegates in governance?

Adjusting tax ratios based on these can properly redefine risk-pricing in dPoS ecosystems, and it would be great to have Archway be the first to do it! Additionally, by securing the chain properly, inflation can be significantly lowered as it’s meant to incentivize securing the chain, which will be less of a risk.

For consideration however, I’m no longer the employed Tokenomics Lead for Phi Labs, but just another builder and active community member in this ecosystem, as I always plan to be. Consensus appeared to be that I pursue a Grant or Community Pool funding for the development of this upgrade, in which I’d aim to work closely with Rockaway Labs and the Phi Labs Protocol team.

As always thank you to the community members who joined the call, and look forward for on-going feedback and discussion! See everybody at the Governance call on Wednesday to talk ‘Liquidity Council’!

Hey Eric -

Was curious on how some of these Tax Bracket Considerations could be enforced via code?

1. How many tokens are staked to the validator?

  • This is pretty straightforward (enforceable)

2. What hardware is being used?

  • From my understanding this would require input from the Validator itself, who has the incentive to state they’re running the ‘optimal’ hardware (whether it’s true or not) (not enforceable)

3. Where are the nodes being hosted?

  • Thinking an IP address can be pulled (would be enforceable), but if not this requires Validator input as well (not enforceable)

4. How active are the validators in governance?

  • Would this be strictly whether or not a Validator has voted on network proposals (enforceable) or the ‘quality’ of their contributions such as participating in governance discussions (which is more subjective)

5. How active are the validators’ individual delegates in governance?

  • Does this refer to the % of individual delegates ‘overriding’ their Validator (enforceable)?
1 Like

2 + 3. So Rockaway Labs already has access to data such as hardware type and location (2 and 3). I’m not positive how they pull it, but I’ve seen others aggregate said data as well, so it’s definitely knowable without voluntary contribution, but we will need to assess it further to see if the information is manipulatable.

4 + 5. This would be quantitative, not qualitative, however I still think a formula should focus less on how active the validator is in voting, and more on how active their independent delegates (by weighted percentage) are at voting, so if they work together to be active in governance, they all pay less in taxes comparatively. The goal is to foster proper education and involvement.

Want to keep subjectivity out of this before it devolves. Is there anything else you think would be good to factor into this type of weighting?

1 Like

One thing I was curious about that doesn’t seem to be common in any Cosmos chains is encouraging Validators to “self-bond” more. A Validator having more “self-bonded” would be an additional quantitative parameter I could see being helpful.

I do understand that this probably does favor the “top” Validators as they likely can afford to self-bond more, but I think using a % of the Validators total delegation can mitigate this a bit.

Is self-bonding not encouraged because during slashing events all delegators are slashed (not the self-bond)?

1 Like

I believe self-bond would also be slashed. That sounds like an awesome metric to also encourage! Love it.