We are pleased to announce that the governance proposal for the Cronos POS Chain v6.0.0 mainnet upgrade is now live. This proposal introduces important improvements to the network’s performance, security, and interoperability by incorporating the latest developments from the Cosmos SDK. We encourage all validators, node operators, and community members to review the details and participate in the voting process.

What is this proposal?

This proposal aims to upgrade the Cronos POS Chain mainnet (chain ID: crypto-org-chain-mainnet-1) to v6.0.0-2. This release brings the chain in line with the latest Cosmos ecosystem standards and includes key dependency upgrades, the new Circuit Breaker module, and database optimizations to boost efficiency for both developers and users.

• Core library upgrades

The upgrade includes the following dependency bumps bringing Cronos up-to-date with the latest standards. Cosmos SDK v0.50.10 builds on the foundational improvements from the “Twilight” release which introduced better event handling, settings management, and support for a more flexible consensus engine to boost performance. v0.50.10 extends these capabilities with improved modularity, runtime stability, and tooling fixes that make maintenance and upgrades easier.
Together with the IBC-go v8.5.1, it improves cross-chain communication and compatibility with the wider IBC ecosystem.
And CometBFT v0.38.13 provides stability improvements to the consensus layer.

• Circuit Breaker Module

The v6.0.0 upgrade introduces the x/circuit module, which provides network operators with an emergency mechanism to freeze specific message types. It can be used to respond to potential vulnerabilities without requiring a full chain halt, by allowing an authorized account (such as a validator or governance account) to trip the circuit breaker to temporarily block messages from being executed or included in the mempool.

• RocksDB caching layer

A caching mechanism has been added to RocksDB to optimize memory usage during block execution. It significantly reduces RAM consumption by limiting in-memory state storage during block execution. As a result, full nodes now use less RAM especially during periods of high activity, making it easier and more cost-effective for validators and node operators to run the network.

• MemIAVL and RocksDB Enhancements

MemIAVL has been bumped to its latest version with improved state sync performance and consistency. RocksDB is now upgraded to v9.2.1, with VersionDB adjusted for compatibility and optimal read/write performance. These enhancements reduce memory pressure and improve database handling for validators and full nodes during chain operations.

• Other Updates and Fixes

Beyond the major updates detailed above, this release includes several important compatibility improvements, such as Solo Machine upgraded to v0.1.4, MsgModuleQuerySafe added to allowed message types in ICA host settings, enhanced validation for expedited governance proposals and more.

These updates collectively enhance the reliability and performance of the Cronos POS Chain and reduce infrastructure requirements for validators and node operators.

For more details, users can refer to the full binary release notes.

Governance voting process

The community governance voting process for this upgrade will start once this proposal has been funded by a sufficient deposit. The upgrade will be performed at the block height of 24836000 if the proposal passes. The Chain will be paused to allow validators to upgrade.

How can I prepare?

Validators and full node hosts need to upgrade to the latest chain-maind binary. There is no other required action.

The 14-day voting period begins at 12:50pm HKT / 4:50 am UTC on July 11, and ends at the same time on July 25.
We highly encourage all Cronos POS Chain validators and delegators to cast their votes.

How do I vote?

We have started the on-chain parameter change governance proposal 31 and would like to invite you to participate in the voting process. You can cast your vote by using “chain-maind” or Crypto.com DeFi Desktop Wallet (latest version 1.5.1).

Option 1: Crypto.com DeFi Desktop Wallet

1. Download the latest version of the Crypto.com DeFi Wallet v1.5.1

2. Select Governance section

3. Choose proposal #31

4. Cast your vote

Option 2: CLI (chain-maind)

To check the proposal:

chain-maind q gov proposal 31 --node https://mainnet.crypto.org:26657/

Check the vote by:

chain-maind tx gov vote 31 [voting_option]  --from [key_name] --chain-id="crypto-org-chain-mainnet-1" --node https://mainnet.crypto.org:26657/

You may track voting results at the Cronos POS Chain Explorer.

How do I upgrade my nodes?

Node runners do not need to perform any operations yet, as the upgrade proposal must be passed first. Important dates for your attention:

• Jul 25 2025, 12:50pm HKT / 4:50 am UTC: When the upgrade voting period ends, you can check the result at https://cronos-pos.org/explorer/proposals.

• At block height 24836000: Please upgrade your node at this block height if the upgrade proposal passes. You can find the approx time and upgrade count down at https://www.mintscan.io/crypto-org/block/24836000.

Join the Cronos Discord and follow Cronos Developer Newsletter to stay in touch with our team and connect with the community.

The State of CRO Today

Since its inception, CRO has continuously evolved in tandem with the transformation of Crypto.com and Cronos ecosystem through several revolutionary milestones.

At its genesis, CRO was designed as a unified gateway to consolidate the benefits of the Crypto.com platform and also to secure the network for the then-nascent Cronos Proof-of-Stake (POS) chain, which was the first foundational step in establishing the Cronos chain ecosystem.

With the launch of the Cronos EVM and zkEVM chains, CRO has become a pivotal asset powering a rapidly growing blockchain ecosystem. Today, CRO fuels decentralized finance (DeFi) use cases, serving as a gas token, DeFi collateral, and a yield-bearing token for on-chain users. It also secures three interconnected chains that have collectively processed over 165 million transactions, driving value accrual for the Cronos ecosystem.

Now, as both Crypto.com and the Cronos ecosystem double down on their ambitious roadmaps, the stage is set for CRO to undergo its next evolution. This transformation is necessary to align with their bold vision and to propel the ecosystem into a new era of innovation and growth.

Bold Ambition

In November, Cronos unveiled a bold new vision to become the primary blockchain for AI Agents, a transformative vision that positions Cronos at the forefront of onboarding billions of users into crypto.

Simultaneously, Crypto.com announced an ambitious roadmap aimed at bridging the gap between crypto and traditional finance by launching groundbreaking initiatives, including ETFs backed by CRO (“Cronos ETF”). These efforts are designed to break down barriers and reach an even broader audience, encompassing retail and institutional users.

CRO lies at the heart of both these monumental efforts. As the ecosystem evolves, CRO will play a pivotal role as the central economic engine, driving adoption and enabling seamless integration for the next generation of crypto users.

Investing in the World Capital of Crypto

One of the most exciting parts of the roadmap is connecting CRO to the institutional liquidity pools through Cronos ETFs. The Bitcoin ETF in the U.S. has been the fastest-growing ETF of all time, attracting more than USD 100 Billion since its launch in January 2024. Securing a position among the top 10 protocols and achieving U.S. ETF approval will be essential to drive institutional adoption of CRO.

Making America the World Capital of Crypto will ensure the successful execution of the Cronos roadmap, hence we are proposing that the community vote on the creation of a Cronos Strategic Reserve, a reversal of the February 2021 token burn, to support this ambition.

Introduction of Cronos Strategic Reserve

In 2021, 70 billion CRO were burnt in one of the most significant burn transactions in history. Under today's proposal, an equal number of tokens will be re-issued on Cronos POS into a Cronos Strategic Reserve escrow wallet, bringing the total supply back to the initial supply of 100 billion CRO. The Cronos Strategic Reserve escrow wallet will operate under strict control mechanisms.

The Strategic Reserve escrow wallet will be subject to a new 5-year lockup on top of the 5-year lockup that has already passed since CRO's original issuance on Ethereum, bringing the total vesting period to 10 years. Vesting will be applied linearly every month and managed via a native Cosmos SDK vesting account mechanism on the Cronos POS chain (technically, vesting is applied every approximately 30.4 days or 2628000s).

With this change, CRO emission parameters will be adjusted to ensure that validator rewards remain at the same level. Detailed technical changes and their implications are outlined in the GitHub post.

Proposal & Upgrade Timeline

Proposal and on-chain governance voting schedule:

• Governance proposal available: 3 March 2025

• Governance Voting Start Date: 3 March 2025 (see https://www.mintscan.io/crypto-org/proposals/29)

• Release of chain-maind binary v5: by 11 March 2025

• Governance Voting End Date: 17 March 2025

• Implementation: In the days following the end of the governance voting period, at the specified block height outlined in the governance proposal.

서론

Cronos POS(이전 Crypto.org) 체인의 새로운 발전을 지켜보면서 그 토큰 경제도 지속적으로 적응하고 발전해야 합니다. 최근 GitHub 에 제안된 안건은 네트워크의 견고함을 나타내는 핵심 지표인 잠금(bonded) 비율을 강화하기 위한 전략적인 매개변수 조정을 주장하고 있습니다. 

이 계획은 더 높은 연간 수익률(APR)을 통해 위임자와 검증인에게 CRO 인센티브를 강화함으로써 네트워크의 경제적 보안에 더 깊은 참여를 장려하고자 합니다. 그러나 이 메커니즘은 어떻게 작동하며 이전에 승인된 커뮤니티 소각 제안과 어떤 결과를 가져올 수 있을까요? 이 글에서 그 내용을 자세히 살펴보겠습니다.

배경

2023년, 우리는 Cronos POS 체인에서 CRO 스테이킹 참여가 분명하게 증가하는 것을 목격했습니다. 스테이킹된 총량은 2023년 초 약 50억 개에서 지금은 85억 개+로 70% 넘게 증가했습니다. 이러한 스테이킹의 증가는 스테이킹 APR 감소로 이어졌고 이는 거의 12%에서 오늘날 6.5.%로 떨어졌습니다.

Cronos POS 체인은 Cosmos SDK 위에서 운영되며 "민트" 모듈에 의해 관리되는 인플레이션 일정을 따릅니다. 이 중요한 모듈은 블록당 검증인에게 배포되는 새 CRO 토큰의 양을 결정합니다.

기본적으로 스테이킹 APR은 두 가지 주요 요인에 의해 영향을 받습니다. 첫 번째는 민트 모듈에 의해 정해진 새 CRO 토큰 생성 속도입니다. 두 번째는 스테이킹(잠금) 비율인데 스테이킹된 CRO 토큰 수가 많을수록 보상을 받는 사람들이 많아지고 이는 차례로 각 참여자의 APR을 낮춥니다.

왜 더 높은 스테이킹 APR이 필요한가요?

네트워크 보안을 강화하고 스테이킹 위임에 대한 경쟁적이고 공정한 인센티브를 유지하기 위해서 Cronos POS와 같은 체인에 있어 스테이킹 APR은 필수적입니다. 이는 사용자들이 네트워크와 상호 작용하도록 동기를 부여하고 안정성을 강화하는 중요한 역할을 합니다.

전체 CRO 공급 대비 높은 스테이킹 총량은 CRO 홀더들이 블록체인의 보안과 거버넌스에 상당한 헌신을 하고 있다는 것을 나타냅니다. 일반적으로 이 비율이 높을수록 생태계는 더 강건하고 건강하다고 여겨집니다.

다른 레이어 1 블록체인을 살펴보면, 그들의 스테이킹 비율이 대체로 50%를 넘는 것을 볼 수 있습니다. 예를 들어, 솔라나는 68%의 잠금 비율을 자랑하며, 폴카닷은 58%를 기록하고 있습니다. 코스모스 생태계에서 더 가까운 예로, 코스모스 허브는 63%의 스테이킹 비율을, 오스모시스는 53%의 비율을 보이고 있습니다. 

앞으로 나아감에 있어 특히 유동성 스테이킹의 인기가 높아지면서 스테이킹 참여가 지속적으로 증가할 것으로 예상됩니다. 예를 들어, Cronos에서 선두주자인 유동성 스테이킹 프로토콜인 베노 파이낸스는 출시 이후 1년 만에 1억 1천만 CRO 이상을 스테이킹에 끌어들여 스테이킹 활동의 꾸준한 상승 추세를 보여주고 있습니다.

이렇게 늘어나는 스테이킹 비율은 스테이커들이 적절한 인센티브를 받을 수 있도록 발행 매개변수의 재조정을 필요로 합니다. 이러한 인센티브는 PoS 체인의 기능적 기반인 네트워크의 경제적 보안을 유지하는 데 결정적입니다.

그렇다면 새로운 메커니즘은 실제로 어떻게 작동하나요?

제안된 변경 사항이 Cronos POS 체인에 미칠 영향을 이해하려면 세 가지 핵심 매개변수를 알아야 합니다:

1. Inflation_max: 이 매개변수는 인플레이션율의 상한을 설정합니다. 현재 이는 0.025(2.5%)로 설정되어 있으며 총 CRO 공급의 연간 최대 증가량을 결정합니다.

2. Inflation_rate_change: 이 매개변수는 인플레이션율의 연간 최대 변화량을 지시합니다. 현재 잠금 비율이 'goal_bonded'와 비교될 때 어떻게 되는지에 따라 영향을 받습니다. 현재 이는 0.006(0.6%)입니다.

3. Goal_bonded(목표_잠금): 이 매개변수는 Cronos POS 체인의 원하는 스테이킹 비율을 나타내며 현재는 0.3(30%)로 설정되어 있습니다. 네트워크의 인플레이션율은 이 목표에 반응하여 조정됩니다: 실제 스테이킹 비율이 목표보다 낮으면 인플레이션율은 'Inflation_max'까지 증가합니다. 반대로 스테이킹 비율이 목표를 초과하면 인플레이션율은 감소합니다.

제안된 조정 사항:

1. goal_bonded 업데이트: 목표를 30%에서 60%로 증가.

2. inflation_max 업데이트: 상한을 0.025에서 0.037로 상향 조정.

3. inflation_rate_change 업데이트: 0.006에서 0.1로 증가.

현재 잠금 비율은 중요한 30% 임계값을 초과하여 'goal_bonded' 메커니즘에 따라 인플레이션율이 감소하고 있습니다. 이는 스테이킹 APR에 하향 효과를 일으킵니다. 제안된 변화는 네트워크 참여자 모두에게 공정하고 지속 가능한 인센티브 시스템을 보장하기 위해 역학을 재조정하고자 합니다.

이 조정 사항은 네트워크의 스테이킹 비율 변동에 빠르게 적응할 수 있는 더 반응성 있는 인플레이션율을 도입합니다. 궁극적으로 이러한 수정은 스테이킹 APR을 안정화함으로써 검증인에 대한 CRO 발행을 증가시키는 것을 목적으로 합니다.

커뮤니티 소각과 어떻게 함께 작동하나요?

커뮤니티 소각과 관련해서는 그 영향이 스테이킹 APR 감소에 미치는 영향은 미미하다는 점을 인식하는 것이 중요합니다. APR이 줄어든 것은 네트워크 스테이킹 참가가 급증하면서 증가한 잠금(bonded) 비율이 커지도록 기여했습니다.

한번 Cronos POS 체인의 토큰 경제 맥락에서 수도꼭지의 흐름이 발행되는 CRO 토큰을 나타내는 것을 상상해보세요. 수도꼭지의 흐름은 "민트" 모듈에 의해 특정 속도로 설정되며 커뮤니티 소각 메커니즘은 이 흐름의 할당을 결정합니다. 구체적으로 그것은 CRO 발행의 15%를 커뮤니티 예비금으로 채널링하며 나머지 85%는 검증인에게 갑니다.

새로운 제안은 기존의 커뮤니티 소각 메커니즘을 변경하지 않습니다. 대신 수도꼭지를 조정하여 물의 흐름을 증가시키는 것과 같습니다. 이 변경은 물이 나누어지는 방식에 영향을 미치지 않고 사용 가능한 총량을 증가시킵니다. 그것은 발행률을 조절하여 토큰이 시스템에 얼마나 많이 그리고 얼마나 빨리 도입되는지를 결정합니다.

따라서 이 메커니즘들은 함께 작동하지만 토큰 경제의 다른 측면에 영향을 미칩니다: 하나는 전체 발행률을 제어하는 반면, 다른 하나는 재분배를 관리합니다. 함께 그들은 Cronos POS 체인 내에서 사용자, 위임 스테이커, 그리고 검증인 모두에게 혜택을 주는 균형 잡힌 생태계를 유지합니다.

여러분이 할 수 있는 일

우리는 커뮤니티가 당신의 검증인과의 대화와 Discord 및 GitHub 과 같은 커뮤니티 채널 참여를 통해 Cronos POS 체인의 미래에 참여하도록 권장합니다. 

검증인들은 투표하기 전에 자신의 위임자들의 다양한 관점을 고려해야 합니다. 위임자 여러분, 만약 여러분의 검증인과 의견이 다르다면, 독립적으로 투표할 권리를 행사하거나 여러분의 비전과 일치하는 검증인으로 전환하세요. 자세한 투표 지침은 제공된 가이드를 참조하세요(링크 / 링크). 여러분의 적극적인 참여는 모두를 위한 강건하고 지속 가능한 토큰 경제를 만드는 데 중요합니다.

Introduction

As we observe new developments on the Cronos POS chain (previously named Crypto.org), its token economics should also continually adapt and evolve. A recent governance discussion on GitHub advocates for a strategic parameter adjustment aiming at bolstering the chain’s target staking ratio - a key barometer of network robustness for Cronos POS. 

This initiative seeks to strengthen CRO incentives for delegators and validators through higher Annual Percentage Rate (APR) , thereby encouraging a more substantial commitment to the network's economic security. But how does the mechanism work, and what implications might it have in relation to the previously passed Community Burn proposal? Let’s unpack them in this article. 

Background

In 2023, we've seen a clear rise in CRO staking participation on the Cronos POS Chain. The total amount staked has increased more than 70% from around 5 billion at the beginning of 2023 to 8.5+ billion at the time of writing. This rise in staking has led to a decrease of the staking APR, falling from nearly 12% to 6.5% today.

The Cronos POS Chain operates on the Cosmos SDK, adhering to an inflation schedule governed by the "mint" module. This critical module is responsible for determining the quantity of new CRO tokens distributed to validators per block.

The staking APR is influenced by two primary factors. The first is the rate of new CRO token creation as stipulated by the Mint Module. The second is the staking (bonding) ratio —the higher the number of staked CRO tokens, the more recipients there are for the rewards, which in turn dilutes the APR for each participant.

Why would we need higher staking APR?

To maintain a competitive and fair incentive for staking delegation, thereby enhancing the network's security, the staking APR is crucial for a chain like Cronos POS. It serves as a key motivator for users to engage with the network, enhancing its stability.

A high total staking amount relative to the total CRO supply signifies a substantial commitment from CRO holders to the security and governance of the blockchain. Generally, the higher this percentage, the more robust and healthy the ecosystem is perceived to be.

For perspective, examining other Layer 1 blockchains reveals that their staking ratios typically exceed 50%. For instance, Solana boasts a bonding ratio of 68%, while Polkadot has 58%. Looking closer to home within the Cosmos ecosystem, the Cosmos Hub stands at a 63% staking ratio, and Osmosis at 53%.

As we move forward, a continued increase in staking participation is anticipated, especially with the growing popularity of liquid staking. Take, for example, Veno Finance, a leading liquid staking protocol on Cronos. In just one year since its launch, it has drawn over 110 million CRO into staking, signaling a consistent upward trajectory in staking activities.

This rising staking ratio necessitates a recalibration of the emission parameters to ensure that stakers receive adequate incentives. Such incentives are critical for maintaining the economic security of the network, which is the cornerstone of a functional POS chain.

So how does the new mechanism actually work? 

To grasp how the proposed changes will impact the Cronos POS chain, it's essential to understand three key parameters:

1. Inflation_max: This parameter sets the upper limit of the inflation rate. Currently, it is set at 0.025 (2.5%). It determines the highest possible annual increase in the total CRO supply.

2. Inflation_rate_change: This parameter dictates the maximum annual change in the inflation rate. It's influenced by how the current bonding ratio compares to the 'goal_bonded'. Right now this is at 0.006 (0.6%). 

3. Goal_bonded: This parameter indicates the desired staking ratio for the Cronos POS chain, which is currently set at 0.3 (30%). The network's inflation rate adjusts in response to this target: if the actual staking ratio is below the goal, the inflation rate will increase up to 'Inflation_max'. Conversely, if the staking ratio exceeds the goal, the inflation rate will decrease.

The proposed adjustments:

1. Update inflation_max: Raising the cap from 0.025 to 0.037. 

2. Update inflation_rate_change: Increasing from 0.006 to 0.1. 

3. Update goal_bonded: Increasing the target from 30% to 60%. 

Currently, the bonding ratio has exceeded the critical 30% threshold, leading to a decrease in the inflation rate as per the 'goal_bonded' mechanism. This causes a downward effect on the staking APR. The proposed changes aim to recalibrate the dynamics to ensure a fair and sustainable incentive system for all network participants.

These adjustments introduce a more responsive inflation rate that can swiftly adapt to fluctuations in the network's staking ratio. Ultimately, these modifications are intended to increase CRO emissions for validators by stabilizing the staking APR.

How does it work in conjunction with Community Burn?

Regarding the Community Burn, it is important to recognize that its impact on the declining staking APR has been minimal so far. The decrease in APR can be largely attributed to an increased bonding ratio from a surge in network staking participation.

In the context of the Cronos POS chain's token economics, envision a water faucet where the flow represents the CRO tokens being emitted. The faucet's flow is set at a certain rate by the “mint” module, and the Community Burn mechanism determines the allocation of this flow. Specifically, it channels 15% of the CRO emissions into a community reserve, with the remaining 85% going to validators.

The new proposal doesn't alter the existing Community Burn mechanism. Instead, it's like adjusting the faucet to increase the water flow. This change doesn't impact how the water is divided but rather increases the total amount available. It regulates the emission rate, effectively determining how much and how quickly tokens are introduced into the system.

Therefore, these mechanisms operate in tandem but affect different aspects of the tokenomics: one controls the overall emission rate, while the other manages redistribution. Together, they maintain a balanced ecosystem within the Cronos POS chain, benefiting users, delegated stakers, and validators alike.

What you can do

We encourage the community to engage with the future of the Cronos POS chain by discussing the proposal with your validators and participating in community channels like Discord and GitHub.

Validators should consider the diverse perspectives of their delegators before voting. Delegators, if you find disagreement with your validators, exercise your right to vote independently or switch to validators aligning with your vision. Refer to the provided guides for detailed voting instructions (here and here). Your active participation is crucial in forging a robust and sustainable economy for all.

Share

Subscribe now

Background 

As many of you will recall, back in May, the Cronos PoS chain (formerly known as Crypto.org) passed a pivotal governance proposal aimed at slowing down CRO token inflation. This proposal introduced a burning mechanism to reduce the overall inflation rate. The approach involves allocating a share of tokens generated through future inflation to a "Community Pool," which are then periodically burned.

Official Burn Procedure Explained

The focus of today's article is on Step 5 in the token economic cycle diagram, which we've previously discussed. The key is to allocate a portion of tokens generated through emissions to a community pool, followed by a periodic burn. To perform this "burn," a "community pool spend" governance proposal must be initiated. Funds can then be transferred to a "dead" address which no one controls (i.e. cro1qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqtcgxmv) , effectively reducing the available token supply and concluding a single burning cycle.

As of the time of writing, the community pool holds approximately 50 million of CRO, which brings us to our next topic.

So... wen burn?

We propose to initiate the CRO Burn when the community pool hits the 50M CRO threshold. Achieving this target will not only be a pivotal moment in the upgrade of our protocol but will also serve as a harbinger for a more balanced and resilient token economic model for Cronos PoS.

This inaugural CRO Burn is more than a one-off event; it's the first step in a broader, long-term strategy. As we plan for the future, we are exploring two potential paths to sustainably implement future CRO burns:

• Threshold-Triggered Burn: With this model, each time the community pool's CRO balance reaches a specified amount— e.g. 25M CRO—a burn event will be triggered. This approach ensures that burning is responsive to the rate of token accumulation, thus directly impacting the circulating supply in a dynamic manner.|

• Calendar-Governed Burn: Alternatively, we could stick to a time-based approach where burns occur at quarterly intervals, irrespective of how much CRO has been amassed in the community pool. This would provide a predictable and consistent burning schedule, which may be easier for token holders and market analysts to anticipate.

Each option has its merits, and the choice between them will set the course for how the Cronos PoS chain manages its token supply moving forward. We are eagerly looking forward to the community's insights and active participation in making this decision. Please visit the Cronos Discord server or Github to share your thoughts.

Looking Ahead 

As we look ahead, the successful completion of this inaugural CRO Burn serves as a milestone in our mission to optimize the Cronos PoS chain's token economics. But this achievement is not an endpoint; rather, it's a catalyst for further exploration. Now that we've made strides in controlling supply-side factors, we're primed to delve into the mechanics of demand. The growth and expansion of our network not only set the stage for reducing inflation but also potentially steer us towards a deflationary path, making the vision of an 'ultra-sound' CRO increasingly attainable.

Ask what You can do for Cronos

We cannot stress enough the importance of active community participation in shaping the future of Cronos PoS chain. Engage with your delegated validators and take part in the proposal discussions on Discord and GitHub. Your voice is crucial in evolving a vibrant and enduring token economy that benefits all CRO holders and the broader ecosystem.

Previous blog post: A Straightforward Proposal to Slow Down CRO Inflation

Reference Links

1. Initial Burn Proposal

2. Official proposal

3. Community Pool balances

TL;DR

As of October 16th, 2023, the Crypto.org Chain, one of the leading blockchain networks of the Cosmos ecosystem, becomes the Cronos POS chain, where POS stands for Proof-of-Stake.

This rebranding aims to bring more coherence into the Cronos blockchain ecosystem, which consists of:

• Cronos ($CRO), the native utility token of the Cronos ecosystem,

• Cronos POS blockchain (formerly known as Crypto.org), the proof-of-stake Cosmos chain positioned as “layer zero” of the Cronos ecosystem,

• and Cronos EVM blockchain (abbreviated into Cronos blockchain), the leading Ethereum-compatible blockchain of the Cosmos ecosystem, home to hundreds of decentralized applications.

The root domain of the Cronos POS chain becomes: cronos-pos.org. The Cronos EVM chain keeps its existing domain (cronos.org).

All URLs and endpoints will be updated gradually during the next several weeks.

Existing Crypto.org URLs will initially redirect to the new cronos-pos.org domain URLs. We expect the old URLs to be removed completely in 3 months, so by the end of January 2024.

At the protocol level, nothing changes. The Cronos POS network continues to deliver on its track record of security, performance, and reliability together with its world-class network of validators and partners.

To review the mapping from old to new URLs, please visit https://docs.cronos-pos.org/for-users/new-brand-and-domains.

The logo of the Cronos POS chain keeps the instantly recognizable hexagon commonly associated with the Crypto.org chain in wallets and on third party websites, while emphasizing the connection to the rest of the Cronos ecosystem:

Why Change?

The Cronos EVM blockchain and Cronos POS blockchain share a common mission, to serve and grow the #CROFam user community as we usher in an era of mainstream adoption of cryptocurrencies.

With shared goals powered by a common Cronos ($CRO) utility token, we can bring coherence to the user experience and developer ecosystem by bringing the two chains together under one roof.

With its new brand, the Cronos POS chain joins a multi-layered ecosystem that connects the Ethereum and Cosmos universes with a complete suite of decentralized technologies:

• Cronos POS chain is the layer-zero network that guarantees the security of the Cronos ecosystem. It is the native issuer of the $CRO utility token, secured by a vast network of more than 100 nodes representing ~350 M US$ in staked value, in the top 3 of all Cosmos chains. The Cronos POS chain has securely validated around 33 M transactions, with an average transaction fee of 0.00001 US$.

• Cronos (the EVM blockchain) is the Ethereum-compatible, permissionless, programmable layer-1, home to more than 500 project teams who have created decentralized applications powered by smart contracts. The Cronos EVM  chain has securely delivered more than 70 M transactions for more than 1 M users to date, and secures around 300 M US$ of DeFi Total Value Locked.

• On top of Cronos EVM blockchain acting as the EVM-compatible settlement layer, many layer-2 chains can be deployed by application creators. For example, Caldera offers a platform of optimistic layer-2 rollups on top of Cronos EVM.

Overall, the Cronos ecosystem is a powerful platform that can support thousands of transactions per second across multiple layers.

The Cronos brand unites Cronos POS and Cronos EVM and paves the way for future synergies leveraging some of the breakthrough innovations originating from the Cosmos ecosystem, such as inter-chain accounts and inter-chain security.

(Re)Introducing the Cronos POS Chain

Cronos POS is a public, open-source and permissionless blockchain - a fully decentralized network with high speed and low fees, designed to be a public good that helps drive mass adoption of blockchain technology through use cases like Payments and NFTs.

Cronos POS is a top 3 proof-of-stake blockchain network of the Cosmos ecosystem, when measured by total value staked. It is extremely low cost, with transaction fees around 0.00001 US$, making it ideal for peer to peer payments and high volume NFT collections. Its native token, $CRO, is a top 2 cryptocurrency among protocol tokens of the Cosmos ecosystem.

Cronos POS is used by world-class ecosystem partners like Crypto.com, Ledger, Coinbase and Alchemy, and 100 active validators with a multi-year track record of reliably supporting proof-of-stake networks.

Crypto.com, one of the world’s largest crypto exchanges with 80 M users worldwide, uses Cronos POS to power its Crypto.com Pay and Crypto.com NFT products.

As a blockchain protocol built on the Cosmos SDK, Cronos POS is ideally placed to work with the broader Cronos ecosystem and explore new potential use cases for its highly performant proof-of-stake consensus, utilizing Cosmos SDK modules like IBC, inter-chain accounts and inter-chain security.

Phased Approach

The rebranding of Crypto.org Chain into Cronos POS will proceed in 3 phases:

• Phase 1: On October 16th, 2023, Cronos POS becomes the official name of the blockchain protocol formerly known as Crypto.org Chain. The following URLs are introduced:

  • Main website: cronos-pos.org, which replaces crypto.org

  • Documentation: docs.cronos-pos.org, which replaces docs.crypto.org

  • Block explorer: 

    • https://cronos-pos.org/explorer replaces https://crypto.org/explorer

    • https://cronos-pos.org/explorer/croeseid4/ replaces https://crypto.org/explorer/croeseid4/

    • https://cronos-pos.org/explorer/croeseid5/ replaces https://crypto.org/explorer/croeseid5/

• Phase 2: During the next few weeks, all remaining crypto.org endpoints and URLs will be replaced by cronos-pos.org endpoints and URLs. Changes that require user action will be published on the Cronos POS blog post and in Discord. You can monitor the progress and the mapping of old and new URLs at this page: https://docs.cronos-pos.org/for-users/new-brand-and-domains.

• Phase 3: Around the end of March 2024, all endpoints of the Crypto.org domain will be deprecated.

Aside from the URL changes, users should not expect any meaningful disruption during this transition period.

Looking Ahead

The Cosmos ecosystem continues to be an exciting space that both Cronos EVM and Cronos POS are committed to. Cronos POS will continue to contribute to the open-source projects that keep the Cosmos SDK at the forefront of blockchain technologies.

Advances in node storage and IAVL implementation, interchain security (ICS) and interchain accounts, will be evaluated synergistically by both chains and will contribute to new use cases and improved performance across the board.

All possible synergies between Cronos EVM and Cronos POS blockchains can be explored. We look forward to hearing the thoughts and feedback of the community regarding Cosmos SDK functionalities and synergies that should be explored jointly by the Cronos EVM and Cronos POS protocols. Please share your ideas on the Discord server.

In response to the growing attention from the community regarding the token supply — We propose to introduce a mechanism to gradually burn a portion of the CRO supply emitted by the network. The overall goal is to reduce the inflation of the circulating token supply and bring long-term benefits to the token economy. The proposal 16 is now live and we would like to invite you to cast your vote before May 16, 2023.

What is this proposal?

This new proposal 16 recommends a burning mechanism that would reduce the inflation rate of Crypto.org Chain. The proposal highlighted is of importance for every CRO holder, details and discussion can be found on Crypto.org’s GitHub discussion page and in our previous blog post.

If this proposal passes, a periodic burning process will be introduced, and approximately 100 Million tokens could be burned in the first year.

Governance Voting Process

The community governance voting process for this proposal has started under the proposal id 16 and the voting period ends at 03:28:18 UTC on May 16, 2023.

If the proposal passes, the parameters update will be performed automatically at the end of the voting period. The Crypto.org Chain will remain in operation with no service downtime.

How do I vote?

We have started the on-chain parameter change governance proposal 16 and would like to invite you to participate in the voting process. You may refer to these guides on how to cast a vote for a governance proposal by using

• Chain-maind;

• Crypto.com DeFi Desktop wallet; or

• Keplr wallet

Note for Crypto.com DeFi Desktop wallet users:
If the proposal 16 does not show up, please kindly refresh the wallet by Ctrl + R or ⌘+R (for Mac), and restart the wallet.

Together, we can create a more vibrant and sustainable token economy that benefits all CRO holders and the broader ecosystem.

Crypto.org Team

***Join the Crypto.org Chain Discord channel to stay in touch with our team and connect with the community.

Introduction

Recently there have been growing discussions on CRO token economics. Specifically, a new proposal on Crypto.org’s GitHub discussion page recommends a Burning mechanism that would reduce the inflation rate of Crypto.org Chain. The proposal highlighted is of importance for every CRO holder, therefore we’ve put together this article to unpack the details and help everyone grasp the benefits and potential implications of this proposed burning mechanism.

Currently, there are 26 Billion CRO tokens in circulation, with an annual inflation rate of roughly 2.5%. This means that each year, about 646 Million CRO tokens are emitted to circulation.

As pointed out here, daily emissions have increased a great deal from 1 M CRO in March 2021 to 1.74 M CRO currently, primarily as a result of technical improvements that have led to Crypto.org blocks being validated faster (from every ~6.5 seconds then to around 5.1 seconds now).

The proposed mechanism aims to gradually burn a portion of the CRO rewards emitted to the validators. This approach entails allocating a portion of tokens produced through future inflation to a “Community Pool” and then burning the collected tokens on a periodic basis. The anticipated result is a decrease in effective inflation rate, ultimately leading to a more robust CRO token economy.

How does the proposed “burning” work?

Before explaining the burning mechanism, let’s first gain an understanding of how current staking and reward mechanisms work on the Crypto.org chain.

1. CRO Holders delegate CRO tokens to validators

2. Validators secure the chain by producing and validating blocks based on the number of staked tokens.

3. CRO rewards received by CRO holders after deducting Validator Commissions

4. Validators receive commissions from rewards (subject to validator’s commission rate)

Let’s now take a look at how the proposed mechanism would work.

1. CRO Holders delegate CRO tokens to validators

2. Validators secure the chain by producing and validating blocks based on the number of staked tokens.

3. Instead of directly emitting the CRO fully to the validator, some portion of the rewards (15% as per proposal) are redirected to Community Pool

4. CRO rewards (minus portion redirected) received by CRO holders after deducting Validator Commissions

5. Validators receive commissions from rewards (subject to validator’s commission rate)

6. CRO in Community Fund are sent to Burn Address through governance vote and removed from circulation

What does it mean for CRO holders?

At present, 4.75 billion CRO are bonded, constituting 18% of the total CRO supply. With annual rewards of around 646 million CRO distributed to stakers, the staking APY stands at 13.6%. The proposed burning mechanism is estimated to take approximately 100 million CRO (15% of annual rewards) out of circulation in the first year, reducing the effective inflation rate from 2.49% to around 2.1%. As a result, staking rewards will experience a slight decrease from 13.6% to 11.5%. Despite the reduced staking rewards (in CRO terms), the burning mechanism is designed to enhance the overall token economy by decreasing the circulating supply and selling pressure in the long run.

Path to an “ultra-sound” CRO

The proposal marks an exciting first step towards refining the token economics of CRO and draws inspiration from other established chains such as Cosmos Hub, Osmosis and Ethereum.

For instance, last year Cosmos Hub passed a proposal to increase the community tax rate in order to boost its community pool. Similarly, Osmosis has an ongoing tokenomics upgrade proposal under discussion that entails reducing OSMO token’s inflation rate.

It is crucial to understand that both supply and demand side factors could drive the CRO token’s supply. By focusing on the supply side, the burn proposal would reduce inflation and CRO in circulation, thus increasing the token’s scarcity.

Another approach, which is to burn a portion of transaction fees, could also be considered in the future. However, the transaction fees of the Crypto.org Chain are cheap, which means that Crypto.org Chain generates less than 100,000 CRO in transaction fees annually. Burning transaction fees would have an insignificant impact on the emission rate compared to the proposed burning scheme and its scale of 100M of CRO annually.

Looking ahead, further exploration into the demand side could be experimented. For instance a fee-burning mechanism similar to Ethereum’s EIP-1559 would involve burning a portion of gas fees from Cronos network’s transactions. As Cronos network grows, this mechanism may pave the way not only for a lower inflation of Cronos token, but a potential deflationary point in the future.

What you can do

We encourage the community to actively participate in shaping the future of Crypto.org chain by communicating with your delegated validators and participating in the discussion of the proposal on Discord and GitHub discussion.

If you are a validator, you should actively listen to your delegators opinions before you cast your vote. You may also decide to cast a weighted-vote if there are different opinions across your delegators.

If you are a delegator, if you cannot reach a consensus with the validators you have chosen, you can still cast your own vote to the proposal or you can decide to re-delegate to other validators who share the same goals as yours. You may refer to these guides for Crypto.com DeFi Desktop wallet or Keplr wallet users on how to cast a vote for a governance proposal.

Together, we can create a more vibrant and sustainable token economy that benefits all CRO holders and the broader ecosystem.

We’re excited to announce the launch of our latest governance proposal for the V4 upgrade for the Crypto.org Chain. This will explore fresh opportunities for our ecosystem to empower the chain. We are urged to hear our community’s feedback on the upgrade proposal and would like to invite you to cast your vote.

What is this proposal?

We are proposing a network upgrade for the Crypto.org Chain mainnet crypto-org-chain-mainnet-1.

This newest Crypto.org Chain binary v4.2.2 is an upgraded base on Cosmos SDK 0.46, IBC-go 5.2.0, and Go v1.19, which contain a few important updates to the network, including support for Interchain Accounts, Relayer Incentivisation, and NFT transfer over IBC. It also comes with 1) the new modules and updates in Cosmos SDK 0.46, such as the implementation of 5% MinCommissionRate, which serves as an incentive for validators to create a sustainable validators ecosystem; 2) support for message-based governance proposals, which execute the messages under the gov module address; and 3) support for x/group module, allowing the creation and maintenance of on-chain multi-signature accounts.

Details are available in our previous post of Crypto.org Chain v4 Release.

If this proposal passes, validators and full nodes would need to upgrade their chain-maind to the newest version to enable this upgrade.

Governance voting process

The community governance voting process for this upgrade will start once this proposal has been funded by a sufficient deposit. If the proposal passes, the upgrade will be performed at the block height of 10073800. The Chain will be paused to allow the majority of validators to upgrade.

How can I prepare?

Validators and full node hosts need to upgrade to the latest chain-maind binary. There is no other required action.

The 14-day voting period began at 06:04 UTC on Feb.7, 2023 and ends at the same time on Feb.21. If the proposal passes, the chain will be upgraded with the new updates discussed above. We highly encourage all Crypto.org Chain validators and delegators to cast their votes.

How do I vote?

We have started the on-chain parameter change governance proposal 15 and would like to invite you to participate in the voting process. You can cast your vote by using “chain-maind” or Crypto.com DeFi Desktop Wallet.

By Crypto.com DeFi Wallet Desktop Wallet:

• Download the latest Crypto.com DeFi Desktop Wallet v1.3.9;

• Select Governance;

• Choose proposal #15;

• Cast your vote.

By “Chain-maind”:

You can check the proposal by using chain-maind

chain-maind q gov proposals 15 --node https://mainnet.crypto.org:26657/

Check the vote by:

 chain-maind tx gov vote 15 [voting_option]  --from [key_name] --chain-id="crypto-org-chain-mainnet-1" --node https://mainnet.crypto.org:26657/

Check the voting result at:

https://cronos-pos.org/explorer/proposals

How do I upgrade my nodes?

Node runners do not need to perform any operations yet, as the upgrade proposal must be passed first. Important dates for your attention:

• Feb.21, 2023, 06:04:35 UTC: When the upgrade voting period ends, you can check the result at https://cronos-pos.org/explorer/proposals.

• At block height 10073800: Please upgrade your node at this block height if the upgrade proposal passes. You can find the approx time and upgrade count down at https://www.mintscan.io/crypto-org/blocks/10073800

***Join the Crypto.org Chain Discord channel to stay in touch with our team and connect with the community.

For more information, developer tools, ecosystem development information, and network governance matters, please visit crypto.org or reach out to us at chain@crypto.org.

After months of preparation and dry runs supported by our validators, the next major Crypto.org Chain v4 update is coming in Q1 2023! Crypto.org Chain binary v4.2.2 is now released, which is based on Cosmos SDK 0.46, IBC-go 5.2.0, and Go v1.19.

In today’s post, we will highlight several features of the new release that users and developers can expect from Crypto.org Chain v4 and what this upgrade brings to the table. Also, governance proposal #15 about this upgrade has just started today, so our community can cast your vote now!

Cosmos SDK 0.46

Cosmos SDK 0.46 includes a number of improvements over the previous version, such as a minimum commission, new modules like x/group, and support for NFT transfer over IBC modules. Depending on the latest release and development progress, the binary will be upgraded to Cosmos SDK v0.46.*. New parameters like MinCommissionRate are added in this Cosmos SDK version too.

a) 5% MinCommissionRate

Our community has been proposing to impose a minimum commission fee of 5% on all Crypto.org Chain validators’ commission rates. As a response to this request, we will implement a 5% MinCommissionRate in this upgrade. 
This implementation would highly incentivise validators and help us to maintain a sustainable validator ecosystem.

Crypto.org validators can decide their own commission fee structure and how the reward distribution works. After this network upgrade, Crypto.org Chain validators can still set commissions at a rate above 5%. For validators who offer a commission lower than 5%, their commission fee will be automatically raised to 5% when the upgrade is complete.

b) Message-based governance proposals

The Cosmos SDK v0.46.* release introduces a new governance proposal format with a new Protobuf package of cosmos.gov.v1 and gov execution models based on sdk.Msg. In the previous version, users need to execute one or more messages through Cosmos transactions. With this new message-based governance proposal, all the messages can now be executed via a governance proposal instead of a Cosmos transaction.

In general, a sender’s signature is required when executing messages through a transaction. After the upgrade, users can directly initiate a governance proposal that includes the message to be executed. After the votes are cast and the proposal is passed, the messages will become a list of sdk.Msg that will be executed. This proposal will then execute the messages under the identity of the gov module address.

More details are available in Cosmos SDK v0.46.7 release notes.

c) Support for x/group module

The new module x/group is introduced, providing a function to define a group that can execute arbitrary messages based on agreed-upon rules. x/group allows for the creation and maintenance of on-chain multi-signature accounts. Additionally, it enables voting for message execution based on configurable decision policies. Group members can create proposals and vote on them through group accounts using different decision policies.

Support for Interchain Accounts

One of the main problems that interchain accounts solve is that they allow one blockchain to access the application features of another blockchain. They allow one blockchain to send a transaction to another IBC-based blockchain to the interchain account first, before interacting with additional modules on the blockchain.

Interchain accounts are now supported in the Crypto.org Chain mainnet v4 release. The Interchain Accounts module enables cross-chain account management built on IBC. It allows the “controller” chain to access the application features of the “host” chain and open an interchain account on it. The “controller” blockchain can then submit transactions to be executed on the “host” chain on behalf of the created interchain account.

Interchain accounts can fill the role of application-layer interoperability while the network layer maintains the IBC standards. More details are available on the Cosmos Interchain Accounts page.

Support for Relayer Incentivisation

IBC-go released a version that supports fee middleware for relayer incentivisation. The Fee Middleware module is designed to incentivise application packets to get relayed. Relayers ensure a smooth transactional process. Therefore, it is important to ensure calling the interchain through effectively incentivising relayers. Incentivised channels compensate relayers for relaying IBC packets from one blockchain to another. With this upgrade, we will integrate IBC Fee middleware to incentivise relayers for IBC transfers to the mainnet.

Support for NFT transfers over IBC

To tackle the issue of transferring NFTs flawlessly across multiple blockchains with IBC, it is necessary to have an NFT implementation which supports reusing NFTs between modules and chains. Notably, the standardised NFT module x/nft was introduced in Cosmos SDK 0.46, and IBC transfers for NFTs became possible. On the Crypto.org Chain, we have a custom implementation that supports transferring NFTs over IBC in the same way as a standard module. We plan to migrate the Crypto.org Chain’s existing NFT module to Cosmos SDK’s standardised NFT module x/nft. The Crypto.org Chain has been offering support for NFTs using a custom NFT module in chain-main.

Users are expected to be able to transfer their NFTs between different blockchains using ICS721 when it becomes available in IBC-go. ICS721 is a proposed standardisation of Cosmos-based NFTs and allows ERC721 NFTs to be transferred across the Cosmos ecosystem in an interoperable way.

Other Updates

The x/supply module has been deprecated in the Crypto.org Chain (including both CLI and gRPC) to prepare users for obtaining a more accurate source for getting a liquid supply of a token via the solution suggested here. More details are available on the ADR page.

Additionally, there are security changes implemented, including Swagger UI security fixes and an upgraded CodeQL scanning pipeline.

What’s Next

We hope you now have a better idea about what’s to come for Crypto.org Chain v4.

If you are interested in receiving more details about the chain, you can refer to our binary release notes and keep a lookout for our updates on the Cronos & Crypto.org Chain Discord server.

The Cronos team is pleased to report that the latest Cronos Mainnet upgrade, “Galileo” (version 1.0), was successfully completed earlier today (January 18, 2023).

With the v1.0 version number, this release confirms that the Cronos blockchain network is well out of beta, having processed more than 65 M transactions for more than 1 M users without downtime.

The major improvements introduced in Cronos v1.0 are as follows:

• Mempool prioritization to scale TPS even further (transactions per second);

• Optimized node storage: 30% less storage for full nodes;

• Node performance improvements such as GRPC queries concurrent responses; generalized reduction of node start-up time by ~50%;

• New Cosmos functionalities to pave the way for greater EVM/Cosmos interoperability (IBC incentivization, IBC token transfer memo field).

For more details about this upgrade, please read this earlier blog post.

As indicated in our last roadmap update, the work continues.

The Cronos protocol engineering team will continue to deliver Phase 1 optimizations of the protocol and database (short to mid-term) while further investing in the R&D work streams required for Phase 2 (Cronos Rollups, Cronos “Next Level”).

Meanwhile, the Cronos Labs team continues to grow the DeFi, NFT, and Web3 Gaming application ecosystem by scaling the Cronos Ecosystem Grants program and the Cronos Accelerator. Applications for the upcoming Accelerator Program are open until early March.

• Meet the Cronos Labs team every 2-3 weeks for the Cronos Stream (video) to discuss recent chain and ecosystem news and meet app founders. The shows are announced on Twitter and can be also replayed on Youtube.

• Cronos Labs announced the 6th batch of Cronos ecosystem grants:

  • Transak: fiat on-ramp integrated with Cronos chain (fiat to crypto). Now available in the US!

  • Snook: online, multiplayer, Snake-like IO game.

  • Legends of Bezogia: play-and-earn MMORPG game.

  • NFTScan: professional NFT explorer.

  • Footprint Network: on-chain data analytics.

• Two new case studies of Cronos dapps have been published. Hear from app founders why you should build on Cronos chain:

  • Single Finance

  • Argo Finance

• Ledger self-custodial wallets now support your CRO holdings on Cronos chain (in addition to Crypto org Chain). Click "add account" in Ledger Live and select Cronos (CRO), as shown below. (Link to Tweet)

• DexCheck, the analytics app used to track tokens, big trades, and top traders supports Cronos chain now. Check out the app at https://dexcheck.io/app/cronos/big-trades

• If you are a Cronos Chain / #crofam builder, don't forget to register your dapp on the newly created Alchemy dApp Page! After clicking “Submit a project,” you can select Cronos under “What chain(s) is your project on?” Visit: https://www.alchemy.com/dapps?chain=Cronos

• Tenderly, the all-in-one Web3 development platform for building, testing, monitoring, and operating smart contracts, announced that its Cronos integration is now live.

• The Cronos Ambassador(CROnaut) Program is looking for ambassadors who are proficient in the following languages: Korean, Japanese, and Spanish. Interested parties can find out more info about the program here.

• Official Cronos updates and blog posts can now be read in the Korean language. Check out the Cronos Community Korea Twitter account and the Medium blog.

Please subscribe to the Cronos newsletter and follow the Twitter account for timely updates.

Cronos moves out of beta and publishes an updated roadmap. Having produced 60+ million transactions without interruption and quadrupled chain capacity since mainnet launch, Cronos has moved out of beta, and will continue to optimize the chain for scalability and performance. Learn more.

#CROFam surpasses 70 million users worldwide. Crypto.com, a strategic partner of the Cronos project, just announced that their user base has surpassed 70 million worldwide and that annual revenue will exceed 1 billion USD. Learn more.

The Cronos Accelerator Program completes its 1st cohort and opens applications for the next cohort. Nine start-ups completed the 10-week accelerator program with demo day: Bubble Maps, DG Pals, Eyeball Games, Glass Finance, Harbor Games, Meshlink, ReferReach, The New Resistance, Wild Forest. Applications are open for the second cohort. Learn more.

The Crypto.com DeFi Wallet now supports Cronos ID. Cronos ID domains can be used in lieu of crypto wallet addresses to send or receive cryptocurrencies in the DeFi Wallet. Visit DeFi Wallet here.

The Cronos ecosystem grant program is alive and kicking. Recently, the focus has been on enabling the integration of Cronos chain by protocols and developer tools who have already achieved significant user traction on other chains, in order to bring new users to the Cronos ecosystem and its native dApps. Learn more about batch 4 and batch 5.

In the spirit of bringing new addressable users to Cronos dApps, several dApps join the Brave Wallet partner program. VVS, Cronos ID, Ferro, and Minted have joined the Wallet Partner Program. If your project would like to join the program, please contact Cronos Labs.

If you would like your project to be featured in the next newsletter, please fill out this form.

Cronos mainnet and testnet upgraded. The Cronos mainnet has been updated to v0.7.0 (major upgrade ‘Huygens’) then v0.8.0, while the testnet is iterating on v0.9 in preparation of the next major mainnet upgrade which should be v1.0. Meanwhile, a separate Pioneer 11 testnet has been launched, specifically to advance the development of the Gravity Bridge between Cronos and Ethereum. That said, if you’d like to bridge your funds between Cronos and other networks, a Crypto.com account remains the safest and most convenient solution.

The list of developer tools integrations is growing. Cronos dApp developers have access to a wide range of end-user wallets, multi-sig wallets, cloud providers, analytic tools, fiat/crypto onramps (Transak, Banxa), and other tools. See the full list here, and contact Cronos Labs if you have questions.

Cronos Play is gaining adoption. Cronos Play is a suite of developer tools and integrations to streamline the development of Web3 games in Javascript, Unity, Unreal, and C++. The Cronos Play Plugin for Unreal Engine is now available in the Unreal Engine Marketplace, and has been downloaded more than 20,000 times. Learn more.

Cronos Labs has several initiatives in the pipeline to increase the visibility of Cronos dApps. We are working on ways to increase the number of AMA sessions and improve the discovery of Cronos dApps, while continuing to raise the bar with respect to the transparency of projects, so that users can do their research. Developers, make sure that you publish your docs, repositories and audits, and verify all your smart contracts on Cronoscan. Learn more.

Meanwhile, don’t forget to register your project on cronos.org. If you have launched a new dApp or service on Cronos chain, please visit the Cronos ecosystem page in order to register it in the public database of projects.

The Cronos Chain Ambassador (CROnauts) Program officially launched on 5th Sept 2022. If you are keen on contributing to the development of the Cronos community and ecosystem, you can find out more here or in the Cronos Discord Server.

Cronos Labs is evangelizing the Cronos ecosystem at Korea Blockchain Week, the Moralis Gaming & Metaverse Hackathon, ETH Online, Messari Mainnet, Token2049 Singapore, Gamescom Asia, ETH Lisbon, NFT London and soon ETH India.

Please share this newsletter on social media if you liked it!

Cronos Gravity Bridge testnet “Pioneer 11” launched in June this year, bringing the decentralized Gravity bridge that connects the Cronos “Pioneer 11” testnet to the Ethereum Goerli testnet for asset transfers. Through the first upgrade of the Cronos Gravity Bridge testnet “Pioneer 11” two months ago, further enhancements were made to the Cronos <> Ethereum bridge, including the implementation of the bidirectional tokens transfers and optimization of the gravity module.

With the team’s efforts, we have just released binary v0.8.0-gravity-alpha2 and are ready to propose the next upgrade to Pioneer 11 testnet on October 26!

What’s Included in This Upgrade:

This version contains the new gorc binary with some new features. One major update is that it allows multiple attestations to be processed within a block so that the speed of the bridge further increases. In addition, the storage can now be optimized by simplifying the storage structure. We have also strengthened the security of the bridge by changing the block delay after Ethereum merged and adding more safeguards. It also includes some performance improvement on the orchestrator.

What to Expect:

The target time and date of the Pioneer 11 testnet network upgrade is 2 PM HKT, October 26.

To fully prepare for the upgrade work, Pioneer 11 Testnet transfers on the gravity bridge web app have been paused since October 20. Pioneer 11 Testnet transfers will resume once the network upgrade is complete. The bridge web app will remain fully functional with respect to Cronos mainnet transfers.

If you would like to share any questions or feedback, please reach out via the #cronos-testnet channel on the Cronos Discord server or by email at contact@cronoslabs.org.

The Cronos team

A solo machine is a standalone process that can interact with blockchains through the Inter-Blockchain Communication Protocol (IBC). It can store key information like signed messages and private keys but has no consensus algorithm of its own. The solo machine client can be seen as a verification algorithm capable of authenticating messages sent from a chain or solo machine. With solo machines, one can access the IBC transport layer and blockchains (including features built on them) within the Cosmos ecosystem without developing their own blockchain. This provides great ease to token issuers who would like to natively mint IBC-enabled tokens.

Another feature of using a solo machine is that it can leverage Interchain Accounts (ICA). The key feature of the Interchain Accounts module is that it enables cross-chain account management via the IBC, which allows one blockchain to access the features of another blockchain. On the Crypto.org Chain, we have leveraged solo machines to issue tokens like Polkadot (DOT)-pegged coins. These DOT tokens can be natively transferred within the Cosmos interchain ecosystem using IBC.

Solo machines open up plenty of use cases in the Cosmos ecosystem. In this article, we will review simple approaches to implementing token operations using the IBC solo machine (e.g. mint and burn as well as delegation and undelegation) on the Crypto.org Chain locally, while any Cosmos SDK based blockchains should support it.

Developers and users who are interested can clone our Stag repository to quickly go through these steps and try the approaches out.

Prerequisite: Blockchain Configuration

The blockchain is running locally in this example and the proper configuration setup is required. In the genesis file, ensure 1) transfer in the genesis file is enabled (receive_enabled: true and send_enabled: true); 2) the staking message (/cosmos.staking.v1beta1/MsgDelegate and /cosmos.staking.v1beta1/MsgUndelegate) is enabled at allow_message under host_genesis_state. This lets them communicate properly later on.

After completing the integration, run the chain in the background.

Signer Configuration

Firstly, you need to install Rust to be able to conduct the operation with stag. The prerequisites setup guide is available here and the Stag CLI guide is available here.

After installing Rust, you need to configure signers for your preferred chains. The sample config for a signer is included in signer.yaml by stag signer sample-config, where you can set up your own signer and update its details accordingly.

Add a Blockchain and Create an IBC Channel

The next step is to add the chain to the solo machine. To run IBC operations on-chain, stag needs several basic configurations to be set up for that specific chain. You can tailor the trusted_height and trusted_hash to your chain’s own trusted height and trusted hash using stag core add-chain <path to chain.yaml>. 
A sample chain.yaml is shown here:

Now, you can establish an IBC connection with a blockchain using

$ stag core connect <chain_id>

(chain-main-1 is the chain_id in our example here), and create an IBC channel with a chain using

$ stag core channel create <channel_type> <chain_id>.

There are two options for channel_type: transfer or ica. In the example below, the transfer channel is created, which looks like:

Use Case #1: Mint and Burn Tokens

A solo machine can be used to mint and burn tokens on any IBC chain. To mint and burn tokens on-chain using a solo machine, simply run

$ stag transfer mint <chain_id> <amount> <denom>.

We will mint 1,000 GLD tokens as an example, allowing us to perform the

$ stag transfer mint chain-main-1 1000 gld.

If you would like to check your current token balance, you can do so by executing

$ stag query balance <chain_id> <denom> — ibc-denom.

In our example, we perform token minting with

$ stag transfer mint chain-main-1 1000 gld.

In return, the response should look like this:

The same token can be burned with the query

$ stag transfer burn <chain_id> <amount> <denom> .

Use Case #2: Delegation and Undelegation

Before delegating tokens from your interchain account to a validator, ensure that you have enough tokens in your account, which allows delegation to be executed successfully. If you would like to send tokens from one interchain account to another, you can do so with

$ stag ica bank send <chain_id> <to_address> <amount> <denom>.

Delegation and undelegation can be done with

$ stag ica staking delegate <chain_id> <validator_address> <amount> <denom> and $ stag ica staking undelegate <chain_id> <validator_address> <amount> <denom>.

In our example, we perform delegation using

$ stag ica staking delegate chain-main-1 tcro17jw7dzu9… 1000 basetcro, and similarly, we can undelegate with

$ stag ica staking undelegate chain-main-1 tcro17jw7dzu9… 1000 basetcro.

Solo Machine UI

Apart from Stag CLI, you can perform the same execution through a UI (User Interface). With the Stag repository, you can simply run just serve-ui under the path of ../stag-ui. Ensure that you have the required target for Rustup setups, which can be installed by rustup target add wasm32-unknown-unknown.

Once it is connected, the default server listening is at http://127.0.0.1:8080 and the frontend should look like:

Like what we did with CLI, we first need to configure the signers, chains, and connections before building the channels.

Here’s what minting and burning tokens look like:

This is how delegating and undelegating will appear:

It’s as simple as that!

If you would like to receive all the latest Crypto.org Chain updates or ask any questions, visit the Crypto.org Chain Medium page and join us on our official Discord channel.

Thanks to the co-author Devashish Dixit.

After the last binary upgrade blog post where we explored what the Cronos Testnet v0.7.0 upgrade entailed, the Cronos development team has worked hard to build a newer version to introduce more features to Cronos Chain. The later version of Cronos v0.8.1 upgraded the Cosmos SDK on the Cronos testnet and integrated with the IAVL v0.19 upgrade. This introduced a new index that improves performance.

As of now, some major progress has been made for v0.9.0-beta. V0.9.0-beta1 is the first beta release of the next major breaking version; V0.9.0-beta2 includes additional changes like interchain accounts retraction and swagger doc enhancement.

This Cronos Testnet v0.9.0-beta upgrade represents as a step ahead of the mainnet upgrade and opens the opportunity to introduce these new options to our community in such a way that our DApp projects and other users can explore and test out the newly developed features on the testnet first.

In this blog post, we will explore the significant upgrades and all the latest features in the new beta versions.

App DB Backend

For completeness and better UX of the node host, the team will simultaneously support both rocksdb (except arm mac binary) and goleveldb in one single binary from v0.9.0-beta onwards. This can be configured in the app.toml with the app-db-backend field.

Prioritised Mempool

V0.9.0-beta1 is based on the updated Ethermint Cosmos-SDK 0.46 which enables mempool prioritisation. The prioritised mempool brings with it useful features like canceling transactions if they cannot be processed within a designated period. The transaction priority is determined by the effective priority fee calculated by the EIP-1559 feemarket. It sorts transactions according to EIP-1559, including both ETH transactions and Cosmos transactions.

For native Cosmos SDK transactions, the gas price computed with the current fee/gas field is used as the feeCap, and the tipFeeCap needs to be provided with the ExtensionOptionDynamicFeeTx. If there are no extension options provided, the tipFeeCap defaults to max int/value.

Validators need to use the v1 mempool to enable this feature. However, the current priority mempool has a limitation in that it only processes one transaction (the SDK transaction) per sender in the new proposed block. Thus, validators may need to send a batch of ETH transactions to be able to process in the same block at the current stage. Overall V1 is a middle solution and prioritized mempool will no longer be needed by the SDK with the advent of ABCI++ when Cosmos-SDK ADR-60 is accepted.

In addition, the patch to the hermes (the rust version of IBC relayer) to support the prioritised mempool is yet to be merged. This would allow the support of custom extension options to specify max_priority_price in Ethermint dynamic fee tx. The team is working on this merger and is always taking into consideration community feedback.

Gas Refund Logic

The existing fee charging logic is calculated using gas_used * gas_price and all unused gas fees are refunded. Ever since this new proposal was made, the team has been working to control the minimum amount of gas that is charged. This should be proportional to the GasLimit of the transaction. The main point of this is that if the actual gas used is far from the transaction’s gas limit, the unused gas is partially refunded rather than in full.

Therefore, a new gas refund logic has been implemented in this update. A minimum gas charge is now in place and set to 50% of the gas limit. With this new gas refund logic, more fees are charged when the unrealistic gas limit is set for a specific transaction. And the overall transactions in a block are less likely to be rejected.

For instance, if the gas limit is set to 100, while only 1 is used, 99 is refunded based on the current gas mechanism. The new gas refund logic requires a minimum charge of 50. Therefore, if the gas limit is set at 100 and only 30 is used, 50 will be refunded instead of 70. That’s because the minimum gas charge is 50. However, if more than 50 is used, the gas refund logic remains unchanged. For example, if the gas limit is 100 and 60 is used, 40 will be refunded.

This deters users from creating large numbers of transactions with high gas limits, as it increases the cost of transaction spamming with high gas limits, which lowers the block utilisation rate. Also, this new gas logic increases the actual cost of producing the transaction congestion because of the minimum gas charge. As mentioned above, overall block utilization is improved and the new transactions in a block are less likely to be rejected under this gas logic.

Custom Tx Indexer

In order to save disk space for the full nodes, a custom Ethereum tx indexer has been implemented. The full nodes will need to enable it in app.toml with the json-rpc.enable-indexer field. The existing node will also need to run the command cronosd index-eth-tx to manually index the legacy blocks, which helps avoid resyncing from scratch. We recommend that developers check if json rpc can still run normally after enabling the new custom tx indexer.

IBC Incentivisation

The final update we would like to share is the upcoming changes on IBC incentivisation. Currently, when the sender initiates an IBC transfer, they only need to pay for the gas fee on the blockchain that they are using but not for the receiver side as the second set of gas fees are paid for by relayers. The new update offers an option for the sender to set a gas fee for the relayer. The relayer can optionally choose to receive the fee when the transfer is successfully performed. This incoming update is supported on the chain but not on the relayer yet.

What’s Next

We are looking forward to seeing how these major changes on the v0.9.0 upgrade would benefit the Cronos chain and our ecosystem as well as your feedback on it!

If you would like to share your thoughts or any questions about the Cronos chain and this upgrade, please reach out to us via the #cronos-testnet channel on the Cronos & Crypto.org Discord server or by email to contact@cronoslabs.org.

Introduction

Witnet is a decentralized oracle protocol that provides reliable data to autonomous smart contracts. It works as a trustable source of randomness for creating unpredictability in various use cases, such as games and NFTs. Witnet has been live on the Cronos Mainnet and Testnet for several months, and the Witnet Random Number Generator is deployed on the Cronos blockchain. In this post, we are going to introduce the purpose of the Witnet randomness generator and walk through a smart contract sample.

Randomness Oracle in Smart Contracts

Random numbers can be useful in decentralized applications. The use cases can be NFTs, video games, or anything else that requires unpredictability at the smart contract level. For example, a smart contract that automatically generates collectibles inside an NFT collection will need a source of randomness to assign different traits. This allows for a variety of unique NFTs to be generated for a certain collection.

However, the execution of smart contracts is deterministic, and smart contract developers do not have access to native random number generation functions natively in Solidity. The randomness must come from outside of the blockchain. This is where an oracle comes in: the job of an oracle is to import number series from off-chain into the blockchain, in a way that provably fulfills certain properties.

Witnet provides a solution to generate randomness on EVM-compatible chains, including Cronos. Every time that a block is created on Cronos, the oracle’s nodes (called “witnesses”) can be asked to generate random numbers independently, and these numbers are assembled into a single random number which is stored in the Witnet smart contract on Cronos.

At a given block height of the blockchain, any other smart contract can query the next random number from the Witnet smart contract, called the WitnetRandomness contract (also known as the Witnet Randomness Oracle). The WitnetRandomness contract offers a user-friendly interface to developers. It is the easiest way to generate reliable randomness for smart contracts.

WitnetRandomness can be used by practically any dApp, as it has already been deployed by the Witnet Foundation. The WitnetRandomness contract uses an instance of the low-level WitnetRequestRandomness. The same instance can also be used by other applications running within the same chain. The best way to interact with the WitnetRandomness contract is through the IWitnetRandomness interface, which is readily available through the witnet-solidity-bridge npm package.

Generate Random Numbers with Witnet

You can start by checking out the Witnet documentation.

In this section, we will walk through random number generation using a sample smart contract. Please ensure that you have some CRO (or TestCRO) stored in your crypto address to pay transaction fees. If you are deploying on Cronos testnet, simply use the test-token faucet to obtain the testnet TCRO tokens.

Firstly, we need to import the interface of the WitnetRandomness .sol file into our smart contract in order to be able to interact with it. This is done with:

import “witnet-solidity-bridge/contracts/interfaces/IWitnetRandomness.sol”;

This is a full example of basic smart contract that makes use of randomness (credits to Witnet for the example):

// SPDX-License-Identifier: MIT
pragma solidity >=0.7.0 <0.9.0;
import “witnet-solidity-bridge/contracts/interfaces/IWitnetRandomness.sol”;
contract MyContract {
uint32 public randomness;
uint256 public latestRandomizingBlock;
IWitnetRandomness immutable public witnet;

/// @param _witnetRandomness Address of the WitnetRandomness contract.
constructor (IWitnetRandomness _witnetRandomness) {
assert(address(_witnetRandomness) != address(0));
witnet = _witnetRandomness;
}

receive () external payable {}

function requestRandomNumber() external payable {
latestRandomizingBlock = block.number;
uint _usedFunds = witnet.randomize{ value: msg.value }();
if (_usedFunds < msg.value) {
payable(msg.sender).transfer(msg.value — _usedFunds);
}
}

function fetchRandomNumber() external {
assert(latestRandomizingBlock > 0);
randomness = witnet.random(type(uint32).max, 0, latestRandomizingBlock);
}
}

This contract involves a two-step workflow:

• Step 1: the user should call requestRandomNumber(). This initiates an asynchronous request to the WitnetRandomness contract to generate a new random number associated with the current block number. If you need any user input/action to be recorded before the random number is known, you should do it at this workflow step (for example, a bet). You can see that requestRandomNumber is payable, this means that you need to send some CRO or TCRO when you call this function. Some of the balance will be used to pay transaction fees during the asynchronous process, the rest will be transferred back to your address.

• Step 2: the user should call fetchRandomNumber(), which will retrieve the random number from WitnetRandomness and store it in the randomness variable of your smart contract.

You should deploy the contract to the Cronos network. The contract constructor requires the address of the WitnetRandomness contract on the blockchain network. You can retrieve the addresses on Cronos here. For this example, you can use the Cronos Testnet address (0x0017A464A86f48B342Cae3b8Fe29cFCDaA7b0643).

Remark: make sure that you are using the Cronos WitnetRandomness address, not the Cronos WitnetRequestBoard address.

In case a gas estimation error appears when executing requestRandomNumber(), increasing the gas allowance will solve the problem. Since randomisation requests will take some time to complete, calling fetchRandomNumber() right after requestRandomNumber() will most likely cause the transaction to revert. Therefore, you should wait for 5 to 10 minutes before executing fetchRandomNumber().

See the following screenshot from remix.ethereum.org:

After executing fetchRandomNumber(), you can then query the value of the randomness variable within Remix. The screenshot below shows that the random uint32 value is “1345667621.”

Decode output {
“0”: “uint32: 1345667621”
}

If you would like to generate another random number, you need to execute the same two steps again:

As usual, you can review your transaction details on CronoScan/Testnet CronoScan.

That’s it! With the Witnet Randomness Oracle, you can quickly and safely generate random numbers for your smart contacts on Cronos.

For community support, please visit the Witnet Discord or the Cronos Discord.

In this dev update, we would like to highlight several major exciting updates made to the Crypto.org Chain over the past few months, along with what we have to plan for the chain in the future.

Crypto.org Chain Alpha Croeseid Testnet v4.0.0

After our recent post on v4.0.0-alpha-4-croeseid, we released an alpha testnet v4.0.0-alpha-5-croeseid for the Crypto.org Chain, which was upgraded to Cosmos SDK version v0.45.7, go version v1.18, and IBC-go version v4.0.0. It includes the following updates:

Interchain Accounts

We’ve added support for interchain accounts in Crypto.org Chain since v4.0.0-alpha. These can act as both the controller and host chain for interchain account operations. The key features of the Interchain Accounts module are that it enables cross-chain account management built on IBC. They allow one blockchain function (as the controller chain) to access the application features of another blockchain (as the host chain) and open an interchain account on the host chain. Then, the controller chain can submit transactions to be executed on the host chain on behalf of the created interchain account.

Relayer incentivisation

Relayers can ensure a smooth transactional process. Therefore, calling the interchain through effectively incentivising relayers is crucial. We’ve added support for creating incentivised IBC channels since the last release. Meanwhile, it is still possible to create non-incentivised IBC channels. The Fee Middleware module is designed to contribute to incentivising application packets getting relayed. Incentivised channels compensate relayers for relaying IBC packets from one blockchain to another. Additionally, support for fee middleware for interchain account (ICA) channels is enabled.

CosmWasm

CosmWasm grants developers an easy way to build smart contracts using WebAssembly (Wasm), so it’s no surprise they are keen to see it enabled on the Crypto.org Chain. However, there is some ongoing development supporting the latest Cosmos SDK by the Coswasm team in order to be closely aligned with the development roadmap. Additionally, the support for CosmWasm on Windows operating systems and Arm64 architectures is still in the experimental stage, which requires further development and testing. So Cosmwasm has been tentatively delayed for the upgrade and we will continue to observe the updates on CosmWasm and make changes to chainmaind accordingly in future releases.

Deprecation

Since this release, we’ve deprecated the x/supply module in the Crypto.org Chain (including both CLI and gRPC) to prepare users for obtaining a more accurate source for getting the liquid supply of a token by the solution suggested here. Developers and users who are interested can read more about this on the ADR page.

Crypto.org Chain Croeseid-5 Testnet

We’re starting the Croeseid-5 Testnet as a new blockchain from scratch, instead of upgrading the version of the existing Croeseid-4 testnet. Both testnets will run in parallel and serve different purposes. One remains as the next mainnet version, while another is an alpha testnet for exploring new features.

Crypto.org Chain Croeseid-5 testnet will run on Cosmos SDK v0.45.7, ibc-go v4.0.0, and go v.1.18. In Croeseid-5 testnet, users will get unrestricted access to all the features of interchain accounts. One benefit of interchain accounts is that they can act as both the controller and host chain. All message types are allowed to execute on these accounts even if there are any changes made by other controllers. Moreover, same with Croeseid Testnet v4.0.0, users can create incentivised IBC transfers or interchain account (ICA) channels, while creating non-incentivized channels is still possible.

Upcoming Croeseid-5 Testnet Upgrade

As with all our previous releases, a testnet upgrade will be launched with the aforementioned enhancements before going live on the mainnet.

Cosmos SDK 0.46 includes quite a few improvements over the previous version, such as a minimum commission, new modules like x/group, and a standardised NFT module x/nft. Depending on the latest release and development progress, the binary will be upgraded to Cosmos SDK v0.46.*.

Regarding the new modules, x/group allows for the creation and maintenance of on-chain multi-signature accounts. Additionally, it enables voting for message execution based on configurable decision policies. Group members can create proposals and vote on them through group accounts using different decision policies.

On the other hand, along with the new NFT feature, we plan to migrate the Crypto.org Chain’s existing NFT module to Cosmos SDK’s standardised NFT module x/nft. Crypto.org Chain has been offering support for NFTs using a custom NFT module in chain-main. Given that different chains are using their own implementation of NFT modules, it is challenging to achieve flawless interpretability of NFTs across multiple chains using IBC to support more use cases. Thus, it is necessary to have a standardised NFT implementation which has support for reusing NFTs between modules and chains. Developers and users who are interested can read more about the NFT module in the ADR page.

With this new implementation, users are expected to be able to transfer their NFTs between different chains using ICS721 when it becomes available in ibc-go. ICS721 is a proposed standardisation of Cosmos-based NFTs, similar to the ERC721 standard for Ethereum. The ICS721 standard allows ERC721 NFTs to be transferred across the Cosmos ecosystem in an interoperable way.

For ibc-go, it is in the process of being upgraded to v5.0.0, which will be based on Cosmos SDK v0.46.*. We will release the binary upgrade to ibc-go v5.* correspondingly.

The Next Crypto.org Chain Mainnet Upgrade

The upcoming Crypto.org Chain mainnet upgrade will come with all the aforementioned enhancements of the Croeseid-5 and Croeseid-5 Upgrade. Unlike the testnet, users will not have unrestricted access to every feature, with on-chain parameters needing to be changed by passing governance proposals.

The Crypto.org Chain Mainnet Upgrade is estimated to be carried out in Q1 2023. The details of the upcoming mainnet upgrade are as follows:

Cosmos SDK

The current Crypto.org Chain mainnet is running Cosmos SDK v0.44.5. All new parameters will be added in newer versions of Cosmos SDK (e.g. MinCommissionRate will be initialised to 5% during the upgrade).

Interchain Accounts

Both HostEnabled and ControllerEnabled parameters will be set to false during the upgrade process. This will disable all the functionalities of the interchain account by default. These will then be enabled in phases using governance proposals, so that they can’t be exploited in case any issues arise. The current list of allowed messages when the Crypto.org Chain is acting as the host chain can be seen here (subject to change before release).

Relayer Incentivisation

No post-upgrade governance proposal will be required for creating incentivised IBC channels. Users can create new incentivised IBC channels directly after the upgrade.

NFT Module

As mentioned above, we’ll be migrating from Crypto.org Chain’s custom NFT module to the Cosmos SDK’s standardised NFT module. As there are a lot of NFTs currently minted on the network, upgrading all of them at one go may take a long time. Recent enhancements in Cosmos SDK’s IAVL store give us hope to perform an in-place store migration without taking up too much time. The final decision regarding the NFT module’s upgrade process depends on the benchmark results of the new Cosmos SDK’s IAVL store. These results will be shared with the community once they are available.

What’s coming next?

We hope that you have gotten an idea about our upcoming plans for the Crypto.org Chain. We will continue to add new functions and prepare for the next network upgrade.

If you would like to participate in the network and be part of our journey, please bookmark the Crypto.org Chain Medium Page and join our official Discord channel for all the latest updates!

After months of preparation and multiple rounds of revision, v4.0.0-alpha-4-croeseid has been released! Our dev team has been working hard to bring major amazing features to the Crypto.org chain since the first Crypto.org Chain’s v4.0.0 alpha release.

The latest release, v4.0.0-alpha4-croeseid, has been upgraded to Cosmos-SDK v0.45.6, IBC-go v4.0.0-rc0, and go 1.18. In this post, we will explore some of the key features of the v4.0.0-alpha release.

Support for Interchain Accounts

Interchain accounts are now supported in the v4.0.0 alpha release.

Chains on the Cosmos SDK are required to align with certain network standards (known as the Interchain Standards, or “ICS”) and transport layers to allow blockchains to communicate. Interchain Accounts implement the ICS-27 protocol on the Cosmos SDK, and their modules simplify the process of handling different ICS standards for IBC transactions on IBC modules.

The key features of the Interchain Accounts module are that it enables cross-chain account management built on IBC. It allows one chain to create new interchain accounts on other chains, relay the transactions to these interchain accounts, and submit them to the target blockchain, thus controlling these accounts via IBC transactions.

Unlike how traditional accounts have their transactions signed by private keys, Interchain Accounts are instead controlled by separate chains via IBC transactions and implemented as sub-accounts of the interchain accounts module account. To provide more context, one of the main problems that interchain accounts solve is that they allow one blockchain to access the application features of another blockchain (such as staking and swapping tokens). They allow one blockchain to send a transaction to another IBC-based chain to the interchain account first, before interacting with additional modules on the blockchain.

Interchain accounts can fill the role of application-layer interoperability, while the network layer maintains the IBC standards. Users can learn more on the Cosmos Interchain Accounts page.

Support for Fee Middleware Module

IBC-go released a beta version that supports fee middleware for relayer incentivisation. In the v4.0.0-alpha releases, we have integrated IBC Fee middleware for incentivising relayers for IBC transfers. The Fee Middleware module is designed to contribute as an approach to incentivising application packets getting relayed.

The relayer infrastructure ensures the liveness of the Interchain network and it comes with operational costs. The Fee Middleware module is designed to allow ICS29 fee payments in this middleware design, and are built with the assumption that sender chains are the source of incentives. The Fee Middleware module enables addresses to be registered with each party involved in relaying the packet on the source chain. The fees will be paid to each party at the end of each packet lifecycle, and the registration process is automated at the starting point of the relayer infrastructure.

CosmWasm

CosmWasm is a fantastic feature for developers who build on Crypto.org Chain, as one can easily add CosmWasm smart contract support to the chain without changing the existing logic. As a WASM-based Smart Contract module for the Cosmos SDK, CosmWasm is considered as a smart contract platform built for the Cosmos ecosystem. It contains the library that provides all modular code needed for building a smart contract.

There is some ongoing development supporting the latest Cosmos SDK by the Coswasm team, we will continue to keep updated with the CosmWasm team’s development progress and work on bringing it into the Crypto.org Chain accordingly.

Other Updates

Other than the major updates detailed above, security changes implemented include Swagger UI security fixes and an upgraded CodeQL scanning pipeline. Lastly, other changes include the deprecation of the x/supply module, including its CLI and gRPC.

What’s Next

Users interested in learning more can refer to the binary release notes. This is the first step to integrating the features and the Crypto.org team will continue to work on expanding and realising more features and functionalities on the Crypto.org Chain mainnet. Please stay tuned and we will release more details soon!

On June 28th, 2022, we launched the Cronos Gravity Bridge on the “Pioneer 11” Testnet, a cross-chain communication protocol that allows the transfer of digital assets between Ethereum’s Goerli testnet and a dedicated Cronos testnet.

Cronos Gravity Bridge is poised to be positioned as the canonical decentralised bridge between Cronos and Ethereum mainnet. It will enable the seamless transfer of digital assets between the Ethereum and Cosmos ecosystems. Therefore it is important that, as a community, we harden the technology and users feel safe when bridging tokens between Ethereum and Cronos Chain. 

In addition to engaging with industry-leading cybersecurity audit firms, we are announcing the Cronos Gravity Bridge Testnet Bug Bounty Program - sponsored by Cronos Labs with a bounty up to USD 200,000. Join the bounty hunt today!

Learn more about the program

Join the bounty hunt

Technical Deployments

• Covalent integrates with Cronos to ease Data Access for Developers, Data Analysts & Investors

• Block size of Cronos chain has doubled from 20M to 40M gas. This means that Cronos can process twice the previous number of txs/day!

• Two new releases (rc0, rc1) on v0.7.1 with several bug fixes and improvements to Cronos Chain

• Cronos Play releases Unreal Engine Plug-in and C++ SDK

• EtherScan supports Cronos Chain testnet

• Cronos Gravity Bridge testnet “Pioneer 11” launch, a dedicated testnet created specifically for the purpose of testing the Cronos Gravity Bridge. The Cronos Gravity Bridge Web App is also available for testing here.

• Query Prices on Cronos using Band protocol or Witnet

• Newly revamped Cronos documentation and whitepaper

Gaming & Metaverse Hackathon

Organized by Moralis with the support of Cronos, the Gaming & Metaverse Hackathon is a virtual hackathon that will take place from August 20th to September 25th, 2022, with $60,000 in prizes already committed and more to be announced. Applications are now open until August 15th, 2022. More details here.

Want some tips on how to stand out in a hackathon? Read our blog post here.

I'm ready to hack now

Cronos World Tour

The Cronos Labs team promoted the Cronos ecosystem at numerous conferences in 2022 Q2: Paris Blockchain Week, DevConnect & ETHAmsterdam, Permisionless 2022, Dcentral Austin, NFT.NYC and the EthCC conference and the EthCC Hackathon in Paris. Watch the EthCC presentation here.

Korea Blockchain Week is our next stop from 7 - 14 August’22 - we look forward to seeing you at our booth!

Cronos Contributor Program

As part of our efforts to make Cronos Dapps more visible to everyone, we have launched the Cronos Contributor Program — a program that financially rewards community members for sharing their knowledge with everyone. Our first task was for participants to share about Cronos Chain and 3 ecosystem dapps that they love. You can check out the winning entries here, congratulations to the winners! The next task is expected to be revealed on 27th July 2022.

Why build on Cronos?

Our “Cronos Ecosystem Spotlight” blog post series highlights how Dapp founders have benefited from choosing Cronos at their home. Read the latest posts and learn from the experience of other builders:

• DG Pals

• Ferro

Potential vendors & integrations

Lots of vendors want to work with Cronos Dapps! If you would like to advertise your products or services to other founders, please complete the form here. And if you would like an introduction to the projects below, please email contact@cronoslabs.org (introductions only, no recommendation).

• Brave Browser offers up to 5,000 USD credits in Brave Ads as well as joint announcements to Dapps who include Brave Wallet as one of the user login options.

• Anchain.ai offers white-label storefront and marketplace services to NFT creators and brands. They also offer KYC/AML anc compliance solutions to institutional investors and digital asset platforms.

• Assure DeFi is a blockchain security company which pioneered the leadership verification services market. Token project founders and NFT creators rely on Assure’s data integrity and anonymity promise, while its Gold Standard Verification empowers investors and collectors with an accountability chain and active recourse support.

• Entersoft is a global security company offering application security, penetration testing, smart contract audit and cloud security to Dapp developers. They specialize in fintech and crypto/blockchain.

Please share this newsletter on social media if you liked it!

An internal dry-run has been completed, and the Cronos mainnet beta binary v0.7.0 will be released soon. The binary is upgraded based on Cosmos SDK 0.45.4 and Tendermint v0.34.19, containing several major changes, key improvements and multiple fixes.

Moving forward, we are proposing the network upgrade for the Cronos mainnet beta to take place on May 10, 2022. On that date, node operators will need to upgrade their cronosd binary to the newest version v0.7.0 at a specific block height announced in a separate post. No action is required before May 10, 2022.

See this post for announcement and details

What’s included in this upgrade:

• This binary includes multiple dependency upgrades (Ibc-go, Ethermint, Cosmos-SDK) and several bug fixes, including WebSocket bug fix, Metamask transaction failure fix, and more.

• A new feemarket module introduces a dynamic fee structure to the network. With this implementation, the common base fee is calculated dynamically at each block for the next block, depending on network utilization, and enforced in the whole network.

• In v0.7.0 binary, the development team has implemented a refactoring of the EVM’s StateDB to improve the performance of contract execution significantly. This improvement allows a larger transaction volume to be processed within each block, hence increasing overall efficiency and scalability.

If you are interested in diving deeper, you may refer to Network Upgrade on Cronos Testnet v0.7.0 and Cronos Testnet v0.7.0 upgrade release notes.

What to expect:

The proposed upgrade date is May 10, 2022 and the chain will be upgraded at a specific block height.

See this post for announcement and details:

• Target upgrade block height;

• Links to v0.7.0 release;

• Instruction for the upgrade (config.toml and parameters updates).

After the upgrade block height, all node operators should upgrade their node binary to v0.7.0 so that their node can continue to sync with the chain. The chain will be paused, and put back on once the majority of validators have been upgraded.

How do I prepare?

Node runners will need to upgrade to the latest cronosd binary until the chain reaches the specific block. Kindly refer to our announcement regarding the block height for the upgrade and DO NOT UPGRADE to the binary v0.7.0 before that.

See this post for announcement and details

If you would like to test out some new features ahead, feel free to interact the Cronos testnet v0.7.0. For instance, you may try to performing transactions with the dynamic fee structure. The transaction records including transaction fees can be tracked on the Cronos testnet explorer.

—

If you have questions or comments, please reach out to us via the #cronos-mainnet-beta channel on the Cronos & Crypto.org Discord server or you may email chain@crypto.org.

We sincerely thank you for your support. Best regards,

The Cronos chain team