Extension chains

Try again now:

Network name: XZNN
New RPC URL: https://ext-testnet.zenon.community
Chain ID: 73405
Currency symbol: xZNN
Block explorer URL: TBA

Iā€™ve sent you 10000 XZNN here: 0x61C94aaC2842d1A93f6BF4ab8873504a52717bD9

xZNN please, sir.
excited to test.

1 Like

Post your address.

0x707B4911d50B5a3b55b01f1C6bbE57ea5db6a372
:face_with_peeking_eye:

After many attempts to find a good candidate for the extension-chain codebase, I finally settled for Cronos.

It has a cleaner codebase than OKXā€™s exchain and also a well maintained Ethermint dependency.

Other clean Ethermint implementations like Evmos or Berachain have restrictive licensing terms that limit fair usage.

Ethermint follows EIP-1559. This means the the extension-chain will also inherit this burning fee mechanism.

At the moment this aligns with the objective to create a deflationary force within the ecosystem, given the fact that the extension-chain wonā€™t have any inflation at all.

Users will be able to wrap ZNN into xZNN and use it to pay gas fees in order to interact with EVM smart contracts on the extension-chain.

Pillars will need to run the infrastructure. Given itā€™s a Cosmos fork, a small number of Pillars is required to bootstrap the network (up to 20 Pillars).

However, the specs required to join this validator set are a bit higher than a typical znnd node in terms of hardware resources.

We can further incentivize extension-chain Pillar nodes with a ZNN bridge fee (when user enter or exit the extension-chain).

I want to hear your opinions on this subject.

Which DB are we running? The RAM requirements are different.

RAM: 4 GB (LevelDB) or 64G RAM (RocksDB)

1 Like

Since we wonā€™t have huge activity right from the beginning, Iā€™d go with goleveldb.

What do you think about this? We can collect exit fees from users and distribute them to active extension-chain Pillars.

I think previously we discussed a fee model in the xChain that was 33% to smart contract, 33% to validators and 34% burned. Is that not feasible?

Maybe we should research how other are doing this where a native token is not involved. Itā€™s probably entrance / exit fee or a share of the TX fees for interacting with smart contracts. Iā€™ll search around and see what I learn.

Itā€™s feasible, but not in the short term. The default fee mechanism for Ethermint is EIP-1559 and changing it requires time and resources.

We donā€™t want to put an entrance tax because we want to drive users into the extension-chain where they have EVM to play with. Custom transaction fees are more difficult to implement.

What we want to achieve now is a sustainable extension-chain that drives value to the ecosystem in the short term. Burning xZNN fees will drive the demand for native ZNN, too. I just want to know if/what additional incentives for Pillars participating in the extension-chain are needed.

1 Like

The native Cronos chain does not seem to reward validators. Or I cannot find that in their documents. Iā€™ll keep looking.

They have 2 chains: a Cosmos fork without EVM and Cronos, a Cosmos fork with EVM (Ethermint). They donā€™t have inflation in Cronos. Every chain with vanilla Ethermint have the default EIP-1559 mechanism in regard to fees.

The easiest solution is to implement a bridge tax for either ZNN ā†’ xZNN, xZNN ā†’ ZNN or both.

I would not tax the ZNN to xZNN because we must encourage users to swap and use the extension-chain to burn as many fees as possible.

However, I would tax xZNN to ZNN because the users porting back their coins to the mainchain will create inflation (staking, delegating, etc.).

This tax will be distributed to the set of active extension-chain Pillars.

2 Likes

Agree

EIP 1559 Summary

EIP-1559 introduces two components to transaction fees: a base fee and a tip (or priority fee).

  • Base Fee: This is an algorithmically determined fee that fluctuates based on network congestion. When the network exceeds a certain level of utilization, the base fee increases; when itā€™s underutilized, the base fee decreases. This fee is burned, meaning it is removed from circulation, which can have a deflationary effect on the total supply of Ether (ETH) over time.
  • Tip (Priority Fee): To incentivize miners (or validators, post-Ethereumā€™s transition to Proof of Stake with the Merge) to include a transaction in the blockchain more quickly, users can add a tip. This tip goes directly to the miners/validators as a reward for processing the transaction.

Questions

Because usage will be low initially, validators will likely not receive Tips. There will be no need to include them to process TX.

  1. Is there any reason we cannot start with small xZNN to ZNN exit fees and later transition to Tips as the network grows?
  2. Will contract deployers get compensated in any way?
1 Like

Theoretically transactions tips are part of the EIP-1559, so we have the functionality built-in right from the beginning.

Initially, no. But we can do that post-launch with a hard-fork.

I support a small exit fee from xZNN to ZNN to incentivize validators. Maybe we start with no fees for some period of time to build interest.

2 Likes

Aliencoder thinking delegating create additional inflationā€¦ This project is doomed.

@aliencoder

will the transactions on the xchain also have fees? Or will the user only pay a fee when they bridge their xZNN back to ZNN

Every transaction on the xchain will have a fee (negligible in the beginning/if network usage is low). The users swapping xZNN back to ZNN will pay an additional fee that will be used to incentivize the Pillars validating the xchain.

1 Like

the mainchain will create inflation (staking, delegating, etc.) != delegating create additional inflation

1 Like