Confidential Asset Issuance Cost Reduction

[Angus]

Confidential Assets (CAs) are an integral building block of the Beam ecosystem and set to be a driver of growth within it. They were first introduced to Beam in 2020, and the initial amount required to issue them was set at 3,000 $BEAM. This came after a community vote on the matter.

Now we are back to see if this number should be reduced in the upcoming Hardfork, and if so, by how much. The required $BEAM can be updated, however, it does require a Hardfork, so not something that is easily altered.

The main benefit of decreasing the amount of Beam required is that it reduces the cost for CA creation. This is especially relevant with the number of DeFi applications set to expand this year. One example of this is that of the AMM DEX. When users enter a pool, they can receive an asset representation of their share of the pool. This can be a Confidential Asset, however the current amount of 3,000 $BEAM may turn people off, and somewhat stunt the growth of the ecosystem.

This is the main motivating factor behind this post, to gauge how the community feels with regards to a Confidential Asset insurance cost reduction.

Please share your thoughts on the matter, and ask any questions you have surrounding it.

Intention is to lower the issuance rate to one of the below:

• 100 BEAM
• 300 BEAM
• 500 BEAM
• 800 BEAM

This allows for cheaper issuance of assets on the Beam network as the DeFi ecosystem continues to grow.

We will discuss for the week, and if the general consensus is to reduce the BEAM required for asset issuance, we shall conduct a vote here on the forum. As the Hardfork is coming in the not too distant future, and the Voting Dapp is not yet live, the forum will be used for voting in this case. The voting Dapp will be live after the 7.0 release, so this will be the first and last time the forum will be used for a governance vote.

[schubertrader]

I am in favor of reducing the minting threshold as 3k beam could seriously deter people from creating CAs.

Maybe 500 Beams as a start would be good enough.

Things will need get reevaluated as price increase in the future.

[Aruki]

I think it should be way lower… in the 50 to 100 range.
why would you have such a barrier to experimenting and developing?
changing the CA will require a Hard Fork… you can only have a few in a couple of years as you do not want to shake the mining ecosystem.

[NewDark]

Choosing a specific figure is problematic in of itself, even if 3k is far too high.

The dream scenario:

• Algorithmically set. The cost fluctuates with demand.

Also good:

• BEAMX governance dictates the price moving forward.

Ok-ish:

• Cost is tied to a stablecoin figure in Beam

For the short term, a very large reduction so that people can experiment and use the network is needed.

[BeamBots]

It’s an honor for us to shape the future of Beam!

To the manner of CA minting, first a small disclosure, we talk from a position as we will mint a Beam CA in the near future, we have invested a lot of time and effort into Beam (and planning to keep doing so).

For us the CA cost is not be a factor if to mint or not to mint, however we do not understand why shall we create such a barrier to mint a CA, we shall encourage developers to experiment on Beam minting more asset, we shall encourage more token on the network (in fact for us it’s one of the KPI of the network growth), we shall encourage LP CAs when there is a DEX and we shall encourage several bridges with many bridged assets!

We clearly remember the vote back in 2020 that set the CA mint cost, back at the time it seems ok, but now that there are Shaders, which are a building block for Defi (which shall come with many tokens) we do not see the reason to have it so high.

in a post not long ago the LP CA was discussed, but what about bridges? think of a project like us, who might one day run a few bridges, and think of 800 Beam to mint a CA, running 4 bridges with 10 asset each will cost us 32K Beam at 800 mint costs. This will not make it profitable, and developers will hesitate to run a bridge.

Yes. We shall keep thinking of scalability (in term of chain size) but let’s face it Beam is not there yet, and if spamming starts we can always make it higher in the next fork.

We recommend having the CA cost mint as low as 100 Beam.

We are so excited that future decisions will be done via Beam Voting DAPP in a confidential manner - just like voting should be!

[Vanilla-Ice-Beam]

Perspective: How is it that high prices for NFTs is generally seen as positive yet, apparently, the developers can’t afford to mint CAs? I assume beam has testnets, and I assert that any team serious about deploying CAs would invest the time and money to do so.

Perhaps set the cost algorithmically.

[R3PUBL1C]

In my opinion nothing beats data-driven decision making; market research should be conducted to find values acceptable to the market. As a tool to calculate baseline value, USDT is used as the most popular stable coin at the time of writing. USDT inflation rate locked on April 26th, 2022 for the purposes of this post.

\\
\\
\\

Section 1 - Adjusted Market Rate

The below costs are adjusted to the market cap equivalent deployment cost for 8KB standard contracts, at a 100m fully diluted MCap for Beam:

1. Ethereum: 0.51 ETH - 8 KB * 640000 Gas/KB * 0.0004 (Adjusted USDT Gas Price) * 0.000229 (Adjusted ETH value) = 0.46 USDT Adjusted

2. Polygon: 0.175 MATIC: 0.01 USDT Adjusted

3. AVAX: 0.5 AVAX = 0.02 USDT Adjusted

4. SOL: 2 SOL = 0.40 USDT Adjusted

\\
\\
\\

Section 2 - Scaled Market Rate

If we take the issuance rate assumed by the OP, and scale it up to the equivalent MCap of the above-mentioned chains we get the following:

1. Beam price ETH-Adjusted: 1,116 USDT/Beam

• 100 BEAM: 111,600 USDT Adjusted

2. Beam price MATIC-Adjusted: 41.23 USDT/Beam

• 100 BEAM: 4,123 USDT Adjusted

3. Beam price AVAX-Adjusted: 88.35 USDT/Beam

• 100 BEAM: 8,835 USDT Adjusted

4. Beam price SOL-Adjusted: 159.65 USDT/Beam

• 100 BEAM: 15,965 USDT Adjusted

\\
\\
\\

Section 3 - Current Comparative Rate

The current cost of deploying a standard contract on each of the above chains is roughly as follows

1. Ethereum: 0.51 ETH - 1,530 USDT
2. Polygon: 0.175 MATIC - $0.23. USDT
3. AVAX: 0.5 AVAX - $36 USDT
4. SOL: 2 SOL - $200 USDT

\\
\\
\\

Summary

Considering all of the above, market rates suggest that the acceptable pricing would have an algo-adjustable rate starting at 100 BEAM (±31 USDT currently) to be scaled down to a minimum of 0.5 BEAM with a price per deployment ceiling of ±550 USDT.

To promote adoption an initial discounted rate under 100 BEAM should be considered.

[raskul]

how about this. thinking outside of the box now…

make the fee to create a CA - 50 Beam and instead of refunding the fee if the creator destroys their token, make it totally non-refundable. Give that 50 Beam fee to miners - in turn this will encourage more hashrate - more network security and bumper blocks for the block finder?

interested to hear the community thoughts on my idea

[Aruki]

the research you made is impressive, nice work!
but why have it so complicated? why not stick to an amount which is high enough to avoid spam, and small enough to remove the innovation/experimentation of dev barrier?
I would just have it as low as ±50 Beam - and upon the next fork renew this discussion

[Angus]

There is a few suggestions for an algo-adjustable rate.

Although a good idea on the surface, given the nature of Beam CAs, it comes with a lot of complexities and added risk to the network as a whole. As Beam CAs are not contracts on top of Beam, and rather they are native assets, it would mean that an oracle would be needed, and that the oracle would need to be involved in the consensus.

With this in mind it makes more sense to keep it simple, and aim for a small amount. Personally I’d say 100 Beam or even 50 Beam would be a good amount. Cheap enough even with a large Beam price rise, yet enough to deter anyone spamming the network with large amount of assets.

[R3PUBL1C]

Honestly I overlooked this point (returning the BEAM after asset reclamation), as this would not be a ‘Cost’ per the title of the article.

BEAM spent for contract creation/Asset Issuance should never be returned to the asset creator - it should be a ‘cost’. Beam spent to deploy should either be burned or used for some collective purpose such as a marketing fund with ideas voted on by the DAO.

If there is some utility that requires a staked quantity of Beam, targeted towards devs, it should be a separate entity (dev forum, script repository, etc).

[Makoto]

I think it is better to keep the issuance cost simple. Complicated schemes can lead to unexpected problems.

I understand the intent is to curb fraud, but it should be set at the smallest quantities to facilitate tthe ecosystem expansion.

Therefore, I think 100 BEAM is most appropriate.

If the BEAM price increases in the future and even 100 BEAM becomes a hurdle, I think token issuers could raise funds through fundraising platform.

[NewDark]

I do like the cost aspect without it being refundable.

I’d personally still prefer the cost not being static either by demand or governance, but agreed otherwise

[Jimmy]

I also like the cost aspect without it being refundable.
I think 50 till 100 Beam would be enough. I’m also good with less. Imo it’s important to make it accessible and attractive for dapp developers.
Would be a good concept to burn those Beams.

[Andi]

In order to understand what the cost of creating a CA should be, you need to evaluate the harm from spam. Does creating a CA take up a lot of space on the blockchain or something else?

[raskul]

Individually, not really no.
More to do with people creating massive amounts of pointless tokens which will never be transacted and just lay dormant - in that case, it might have some effect on blocksize but i suspect not to any detrimental effect. There should be a low barrier, but not low enough to disuade people bringing their tokens to the Beam architecture.

I’m also exceptionally keen to push that the fees to create a CA should go to miners in blockfees. We’ve seen the disgruntled effect upon eth ecosystem when they ripped fees away from miners. I think we can make a point by ensuring our miners are well catered for - thus improving network security. But anyway, creation of a CA doesn’t bloat the chain if the cost to create it is high enough to mitigate the creation of pointless tokens. Ideally we want to to find a middle ground where the confidential assets created are created for valuable and valid purposes.

[Andi]

I think that in terms of utility for BEAM, worthless tokens are no different from transactions. Therefore, the cost per KB for creating a token should be the same as for offline transactions. The miner must receive a commission.

[Kowabunga]

Possibly an unpopular opinion, but meme tokens, ponzis and so on are an important ingredients for bootstrapping a vibrant ecosystem and user base. Every little community around any CA will indirectly promote Beam by shilling their token to the world.

Its not the job of the L1 platform to define what is a worthy or an unworthy usecase for its technology.
If anything at all, Beam should strive to remove barriers wherever possible instead of creating them.

From my point of view a 100 Beam asset creation cost seems already too high. Especially if you can’t rectify it without a hardfork.

Even if the final decided asset creation cost seems trivial to some, for someone else from a different background it might be a prohibitive cost.

In order to prevent outright malicious spam i.e. someone creating millions of dead CAs, a small fee in the range of 1 to 10 USD should be sufficient.

[Andi]

To prevent spam when creating a large number of CAs, I suggest setting limits on the block size. For example, no more than 10% of the maximum block capacity for all CAs.

[Vanilla-Ice-Beam]

tbh, if we were spending money on proper Biz Dev and marketing (to developers), the cost would never be an issue. Would the powers that be please tell us what the expense ratio is between core development and BD / Marketing? This would be very useful info in general.