What You’ll Learn

• Canton Network architecture and key differences from traditional blockchains
• Our proof of concept setup and implementation approach
• EVM vs. Canton development paradigm comparison
• DAML developer experience and tooling assessment
• Key takeaways for institutional DLT adoption

Introduction

Between March and April 2025, the R&D team at ioBuilders conducted research on the Canton Network to better understand the technology and explore its potential integration into our products and services. The research primarily involved a proof of concept (PoC), in which several participants minted and exchanged fungible tokens. This article summarizes our findings and key takeaways.

Canton overall description

The Canton Network is a distributed ledger interoperability protocol designed to solve key limitations found in many blockchain systems — namely scalability, privacy, and composability. Unlike traditional blockchains that maintain a global shared state, Canton allows multiple ledgers to operate independently while still functioning as part of a cohesive, virtual global ledger. This architecture enables institutions to collaborate and share data securely without sacrificing performance or regulatory compliance.

At the core of Canton is the Daml smart contract language, which enforces strict authorization rules and fine-grained privacy. It ensures that only relevant parties can access data and actions within a workflow. This privacy model, combined with Canton’s unique architecture, supports GDPR compliance through principles like data minimization and the ability to prune transaction history. Contracts are visible only to authorized stakeholders, and transaction data is split, sequenced, and delivered securely to each party involved.

Canton supports scalability by avoiding the bottlenecks of global consensus. Transactions are processed in synchronization domains, which handle message sequencing and ensure total ordering of transaction steps without replicating state globally. This structure allows for parallel execution of workflows and seamless composability between applications, making Canton ideal for complex financial operations. Smart contracts remain active only as needed and are tracked through the Active Contracts Set (ACS), which represents the network’s evolving state.

While Canton is not a blockchain in the conventional sense, it delivers many of the benefits associated with DLT — such as auditability, decentralized trust, and atomic transaction finality — without the downsides of global replication. However, the system does rely on trusted synchronization domain operators, introducing a layer of trust that contrasts with fully permissionless blockchains like Ethereum. Still, Canton’s model enables enhanced privacy, performance, and regulatory alignment, making it a compelling foundation for institutional-grade digital infrastructure.

Network

The canton network can be represented like this:

• Party : users (person, legal entity, …) interacting with Canton’s application
• Participant node : enable users to connect to the canton network.
• Domain node : backbone of the canton network.
• Cantons message service : provides a total order on transaction requests within a domain.

Transaction flow

A Canton transaction is submitted to the network by the “submitter” and works as follows:

• Submitter (Bob) splits the transaction up into messages according to the Daml privacy model (one chunk per party involved)
• Submitter batches all the messages and sends to the domain’s sequencer => Confirmation request
• Sequencer orders, timestamps and distributes the messages to the recipients (involved parties)
• Recipients verify the message correctness.
  - All OK : they attempt to lock the contract(s) consumed by the transaction and send a positive response => Confirmation response

ℹ️ A contract must be locked before it can be consumed. If a contract is already locked (because it was requested in a different transaction flow) it can’t be locked again and the recipient would retruned a negative response.

• KO : send a negative response => Confirmation response
• Mediator received all the confirmation responses, aggregates them, sign it and sends it to the transaction’s participants.
• Participants receive the mediator aggregated response.
  - All OK : execute the transaction (consume contracts, create new ones etc…) and release the lock.
  - KO : release the lock.

PoC Definition

Canton promises privacy and programmability. Our goal with this proof of concept (PoC) is to get a sense of the complexity involved in designing and building applications using Canton, in comparison to Solidity/EVM.

To achieve this, we focused on developing a simple application, keeping the smart contracts, backend, and test logic as minimal as possible.

Scope

• There are three organizations: Alice, Bob, and Charlie and a Bank.
• All necessary infrastructure is deployed locally(participant nodes, sync domain, etc.).
• Using DAML, a fungible token is implemented, including a transfer operation.
• Every transfer emits an event.
• No organization (Alice, Bob, or Charlie) can see the balance of the others.
• The application must be able to query the ledger from each organization’s perspective and confirm that no organization can see others’ balances.

Test scenarios

1. Alice transfers 5 tokens to Bob

• Queries confirm that:
  - Balances have changed correctly.
  - Each organization still cannot see the balances of the others.
• The transfer event is captured.

2. Bob transfers 2 tokens to Charlie

• Again, queries verify that:
  - Balances are updated.
  - Privacy is maintained across all organizations.

Key Questions We Aim to Answer

• Which Canton Network components were used (node types, APIs, libraries, etc.)?
• What are the key differences between the EVM and Canton paradigms when it comes to designing and building applications?
• What are the steps to design, develop, and deploy an application using DAML?
• From an EVM-solution developer’s perspective, how easy or complex is it to work with DAML
• How well do the development tools (IDE, SDK, etc.) support the process?

PoC Implementation

The PoC was divided in three modules:

• Smart contracts : where all the DAML scripts and smart contracts were implemented
• Infrastructure : where the local network was configured and deployed
• CLI : a simple typescript CLI to interact with a local version of Canton

Smart contracts

We used “DAML standard” and “DAML finance” smart contract libraries to implement the following scripts and workflow smart contracts.

• Scripts
  - setupHolding: initializes the accounts and the token.
• Workflows
  - CreateAccount.daml: creates a new account (Alice, Bob, Charlie, Bank)
  - CreditAccount.daml: mints new tokens in any of the accounts
  - Transfer.daml: transfer tokens between two accounts

Infrastructure

For this Proof of Concept (PoC), a local Canton network was constructed to provide a stable and observable testing environment. The focus was on a straightforward setup that allowed for a clear understanding of Canton’s core architectural components and operational model.

Local Deployment and Configuration

The network was deployed on a local “bare-metal” machine rather than using a containerized approach like Docker. This method was chosen because it offered a more direct and well-documented path for an initial PoC (as of April 2025), making it easier to control and monitor the environment. The architecture of our network was defined in a central configuration file and consisted of:

• Five Participant Nodes: Each node represented a sovereign entity, responsible for storing its own private data and running its side of the smart contracts.
• Two Domain Nodes: These acted as secure communication hubs or “synchronization domains.” They ensured that encrypted transaction messages between participants were correctly ordered and delivered without being able to read the contents. This setup, with one participant connected to both domains, was specifically designed to test interoperability.

Data Persistence with PostgreSQL

To ensure that the network’s state was saved and would persist through restarts, PostgreSQL was used as the storage backend. This is a critical step up from a purely in-memory test. Following best practices for this type of architecture, each node in the network — both participants and domains — was configured with its own dedicated database. This separation prevents data bottlenecks and ensures that each component runs efficiently and independently.

Network Operation and Monitoring

The local network was started and managed using the command-line. An initial bootstrap script was used to automatically configure the connections between the nodes. For all subsequent restarts, this script was omitted to ensure the network loaded its state from the PostgreSQL databases.

The primary tool for interacting with the live network was the Canton Console, an interactive command-line interface (REPL). This console proved invaluable for monitoring and administration, allowing the team to easily check the health and status of nodes, list which parties were connected to each domain, and manage the deployed smart contracts.

In summary, the infrastructure setup provided a successful foundation for the PoC. It highlighted that Canton’s architecture, while powerful, can be deployed locally in a straightforward manner for development and testing. It also made clear that moving from a PoC to a production environment would require more advanced solutions, such as container orchestration with Docker/Kubernetes and high-availability database clusters, to ensure reliability and scalability.

CLI

The CLI exposed the following functionality.

Create Account

• Alice requested an account to be created
• The Bank accepted (or rejected) the request

Mint

• Alice requested some tokens to be minted to her account
• The Bank accepted (or rejected) the request
• A New Holding SC, representing the newly minted tokens, would be created and linked to the token and Alice’s Account

Transfer

• Bob requested some tokens to be transfered from Alice’s Acccount
• Alice accepted (or rejected) the request
• One or Many Alice’s holdings (for a total balance equal to the transfer amount) would be transferred to Bob.

PoC Results

This Proof of Concept was designed to answer key questions about the Canton ecosystem, from its core components to the developer experience. The following sections summarize our findings.

Which Canton Network components were used?

The PoC leveraged a combination of infrastructure nodes, smart contract libraries, and client-side modules to build and interact with the application.

• Infrastructure Components: The network was built using essential Canton nodes, including five Participant Nodes to represent the organizations and two Domain Nodes to facilitate secure communication. For data persistence, PostgreSQL was configured as the storage backend for each node.
• DAML Libraries: The smart contract logic relied heavily on standard and finance-specific DAML libraries to manage accounts, instruments, and holdings.
  - Standard Libraries: DA.Map, DA.Set, Daml.Script
  - DAML Finance Libraries: A suite of modules for Account, Instrument, Holding, and Token interfaces.
• JavaScript Client Libraries: To interact with the Canton ledger from the command-line interface (CLI), we used the @daml/ledger and @daml/types packages (v2.10.0).

Key Differences Between EVM (Ethereum) and Canton Paradigms

Smart Contracts

• EVM: Mutable objects with fixed code and variable state. State changes are executed globally by the EVM.
• Canton: Immutable agreements, similar to rows in a database. A state change involves archiving the old contract and creating a new one. Logic is executed privately on participant nodes.

Accounts & Identity

• EVM: Managed via public-private key pairs. Parties cryptographically sign transactions, providing non-repudiation.
• Canton: Relies on traditional Web2 identity concepts (e.g., JWTs). Parties are authenticated by participant nodes, not through cryptographic signatures. (Note: Canton 3.0 aims to introduce party-level private keys).

Transaction Fees

• EVM: “Gas” fees are paid to validators for computational work and fluctuate based on network demand.
• Canton: Depends on each network governance. Some networks might not have fees. Other may impose fees which could be paid in a native token (Canton Coin, in the case of the Global Synchronizer) or other assets. Fees amount are normally based on factors like value transferred, holding time, and bandwidth, and in some cases fees are burned rather than paid to a specific entity.

Transaction Order

• EVM: A nonce is used to ensure transactions from an account are processed in sequential order.
• Canton: There is no explicit nonce. Instead, a deduplication mechanism within a time window prevents replay attacks. The sequencer is responsible for ordering.

Events

• EVM: Smart contracts can emit custom events, which are public and can be easily monitored by off-chain applications.
• Canton: Contracts cannot emit custom events directly. Off-chain applications must subscribe to ledger services (like the Transaction Service) to listen for and interpret transaction results.

What are the steps to design, develop, and deploy an application using DAML?

The development lifecycle in Canton follows a distinct pattern:

1. Model the Workflows: The first and most critical step is to define the contract templates and the workflows that govern their interactions, focusing on the rights and obligations of each party.
2. Implement the Contracts: Write the smart contracts using DAML, leveraging its strong type system and authorization model.
3. Deploy to Participants: Package the contracts into a DAML Archive (.dar file) and deploy it to the relevant participant nodes in the network.
4. Build the Off-Chain Logic: Develop the client-side application (in our case, a TypeScript CLI) that connects to the participant nodes’ APIs to submit commands and read ledger data. This includes defining filters to monitor ledger services for transaction outcomes.

From our developers perspective, how easy or complex is it to work with DAML?

The developers who participated in this proof of concept (PoC) were senior engineers with strong backgrounds in object-oriented languages such as Solidity and TypeScript, and extensive experience in building and deploying decentralized applications (dApps) on EVM-compatible networks.

Our researchers noted that the initial learning curve for DAML was steep. Its foundation in functional programming presents a fundamentally different way of reasoning about state and logic compared to the object-oriented paradigm. Moreover, DAML’s smart contract model — based on immutable agreements and conceptually similar to Bitcoin’s UTXO system — represents a significant shift from the EVM’s account-based model. For our developers, mastering these concepts required a considerable learning effort and a paradigm shift in thinking.

That said, developers with prior experience in functional programming may find the transition to DAML smoother, depending on their background and familiarity with such paradigms.

How well do the development tools support the process?

As of April 2025, the official development tool is a Visual Studio Code extension, which provides a reliable and functional environment for writing DAML code. However, in the opinion of ioBuilder’s researchers, the broader ecosystem of third-party extensions, tools and libraries was still maturing and evolving at the time, and presented limitations that could impact developer productivity, especially for teams accustomed to the rich and varied tooling available in the EVM ecosystem.

Exploring Canton Network: A Deep Dive into Privacy-First Distributed Ledgers was originally published in iobuilders on Medium, where people are continuing the conversation by highlighting and responding to this story.

Ethereum Layer-2 (L2) solutions are a set of scaling technologies designed to address the scalability challenges of the Ethereum blockchain. As Ethereum has become the leading platform for decentralized applications (dapps), decentralized finance (DeFi), and various Web3 projects, increased network activity has led to higher transaction fees and slower processing times. L2 solutions operate as independent blockchains, running on top of the main chain (referred to as the Layer 1 or L1) thus inheriting its security. Their main advantages are increased scalability and lower transaction fees although, in some cases, this might entail higher technical complexity and centralization risks.

Types of Scaling Solutions

Sidechains

Although not actual Layer 2 solutions, it is worth mentioning sidechains, as they were conceived and used before Layer 2 technologies. In this sense, sidechains can be considered precursors to Layer 2 solutions.

Sidechains are Ethereum-compatible independent blockchains that use their own consensus models and block parameters to process transactions. They do not actually run on top of the Layer 1 but in parallel to it. Users will transfer funds from the L1 to the sidechain using a bridge or a similar system, then start interacting with it directly.

The main difference between sidechains and layer 2 is that sidechains do not commit transactions or anything into the Layer 1, they are like a completely parallel universe people can “jump into” and “jump from”.

Sidechains can process a larger number of transactions, reducing congestion on the main chain, and they normally do it at a lower cost. However, operating on a sidechain is riskier because it does not inherit the security of Ethereum’s Layer 1. If the sidechain’s security is compromised, the assets on it could be at risk.

Examples : Polygon PoS, Gnosis chain (formerly known as xDai chain).

Plasma

Plasma is a layer-2 scaling solution for Ethereum that provides a framework for building “off-chain” decentralized applications that are secure, scalable, and swift.

Plasma works by creating smaller chains (child chains) that process transactions independently from the Ethereum mainnet. These child chains periodically submit a summary of their state (such as state roots) to the Ethereum mainnet, allowing for dispute resolution and security through fraud proofs. Each “child chain” extends from the root chain and is generally managed by a smart contract deployed on the parent chain.

This setup helps to scale Ethereum by reducing the load on the mainnet while ensuring the integrity of off-chain transactions.

However plasma chains present two main disadvantages:

• They do not support general computation (smart contracts), only basic token transfers and a few other transaction types.
• A malicious operator could submit an invalid transaction and withhold information about it, making it very hard to create a fraud proof.

Examples : OMG Network, LeapDao.

State Channels

State channels are a scalability technology that enables instant and low-cost peer-to-peer Ethereum transactions. They allow participants to securely transact off-chain while keeping interaction with Ethereum Mainnet at a minimum. Channel peers can conduct an arbitrary number of off-chain transactions while only submitting two on-chain transactions to open and close the channel.

Opening the channel means locking up funds into a special smart contract on the Ethereum mainnet (L1).

Closing the channel means submitting the final state of the off-chain exchanged transactions to unlock the funds and distribute them according to the final balances. The final state must obviously be signed by all the involved parties.

The channel can also be updated multiple times before closing it by submitting intermediate states of the parties’ balances, although that could undermine the efficiency gains.

State channels offer a way to make Ethereum transactions faster and cheaper by conducting most of the activity off-chain and only interacting with the blockchain when necessary to update the final state. They are considered secure since they inherit the L1 security but they can only be used to transfer funds between the involved parties, which makes then very limited in terms of usability.

Examples : The Raiden Network, Nitro.

Rollups

Ethereum L2 rollups are a type of second-layer scaling solution that aims to improve the scalability of the Ethereum blockchain by allowing for off-chain transactions to be “rolled up” and periodically committed to the blockchain. This approach enables faster and more cost-effective transactions, making it possible to process a large number of transactions without overwhelming the main Ethereum network.

Rollups bundle together hundreds or even thousands of transactions into a single L1 transaction, effectively distributing the transaction fee cost among all included transactions.

There are two main types of rollups: Optimistic Rollups and ZK (Zero-Knowledge) Rollups. Optimistic Rollups submit transactions to the L1 and are considered valid unless challenged within a certain time period. ZK Rollups, on the other hand, submit validity proofs alongside the transactions to the L1 to cryptographically prove their correctness.

Rollups allow for faster transaction processing at lower costs while inheriting the security of the L1.

Rollups in depth

Optimistic

Optimistic Rollups are a type of roll-up protocol that uses smart contracts deployed on Ethereum to manage interactions between the L2 (Layer 2) and the L1 (Layer 1, Ethereum). They work by aggregating multiple transactions into a single batch and submitting them to the main Ethereum chain. The rollups operate under the assumption (hence “optimistic”) that transactions are valid, but they include a challenge period during which any incorrect transactions can be disputed through fraud proofs.

They are compatible with the Ethereum Virtual Machine (EVM), allowing developers to port existing Ethereum smart contracts to rollups or create new dApps using existing tools. They are designed for interoperability with the Ethereum main chain, allowing users to pass messages and data between L1 and L2.

Optimistic Rollups offer increased scalability, reduced gas fees, and improved latency while inheriting security from the L1. The main drawback is that it requires participants to monitor the transactions submitted to the L1. If a fraudulent transaction is submitted and goes undetected until the challenge period is over, the system could be compromised.

Examples : Optimistic, Base.

zero-knowledge

Zero-Knowledge Rollups (ZK-rollups), just like optimistic rollups, are a type of roll-up protocol that uses smart contracts deployed on Ethereum to manage interactions between the L2 (Layer 2) and the L1 (Layer 1, Ethereum). They aggregate multiple transactions into a single batch they submit to the L1 as well. However, unlike optismitic rollups, transactions validity is not presumed, but proven through the use of zk-proofs, so basically, zk-rollups submit two main type of transactions to the L1, the batches of transactions plus the zk proof validating the batches of transaction.

ZK rollups have been recently evolving a lot, early versions primarily handled simple token transfers, but the latest one are EVM compatible, meaning that smart contracts and dapps can migrate from the L1 to ZK rollups.

They also offer higher scalability, reduced gas fees and improved latency, Zk-rollups require computational effort to generate zk-proofs, but they can finalize transactions faster than optimistic rollups since there is no challenge period.

Zk rollups come in three variants :

• zk-rollups : they submit the L2 transactions unencrypted to the L1 as calldata (blobs in the future). This allows for anyone to recompute the state of the L2 since the content of the transactions is publicly available. They also submit the zk-proof that validate them.
• Validiums : Validiums submit only hashes of L2 transactions to L1, with the actual data stored off-chain. This approach enhances privacy and reduces costs but relies on trusted external parties for data availability.
• Volition : hybrid approach that allows users to choose between zk-Rollup and Validium modes for their transactions. Users can decide whether they want their data to be stored on-chain (zk-Rollup) for higher security or off-chain (Validium) for greater scalability and lower costs. This flexibility enables users to balance security and efficiency based on their needs​.

Examples : Polygon zkEVM, StarkNet.

The Future of Layer 2

The future of Ethereum L2 (Layer 2) is a topic of great interest and debate in the blockchain and cryptocurrency community. As the Ethereum network continues to evolve, the need for scalability and efficiency has become increasingly pressing. L2 solutions aim to alleviate this pressure by providing an off-chain scaling solution for Ethereum-based applications.

Current State of L2

Currently, several L2 projects are being developed to address the scalability issues faced by Ethereum. Some notable projects include:

• Arbitrum: A popular L2 solution that uses Optimistic rollups to reduce transaction costs and increase network throughput. Its main advantages are compatibility with the EVM, high network throughput, and low transaction costs.
• Optimism: Another prominent L2 project that uses Optimistic rollups to achieve scalability. It has a high network throughput and low transaction costs, making it an attractive solution for DeFi applications.

Challenges and Concerns

However, the rapid growth of the L2 ecosystem also raises concerns about potential risks and challenges. Research by Binance Research suggests that the continuous growth of the L2 ecosystem could lead to:

• Increased competition: As more L2 projects emerge, competition for users and resources may increase, leading to higher transaction fees and decreased network throughput.
• Security risks: The migration of assets and users to L2 solutions could potentially reduce the security of the main Ethereum network, as staking rewards for validators may decrease.

Future of L2

Despite these challenges, the future of Ethereum L2 holds much promise. As the L2 ecosystem continues to evolve, we can expect to see:

• Increased adoption: As L2 solutions become more user-friendly and scalable, we can expect to see increased adoption across various industries, including DeFi, gaming, and social media.
• Improved scalability: The development of new L2 technologies and protocols will continue to improve scalability, reducing transaction costs and increasing network throughput.
• New use cases: The L2 ecosystem will enable new use cases, such as decentralized finance (DeFi) applications, that were previously not possible on the main Ethereum network.
• Addressing related risks : L2s come with their own sets of risks, like the usage in many cases of bridges which can be a point of vulnerability; if they fail or get attacked, users could lose funds.

Conclusion

The future of Ethereum Layer-2 (L2) solutions is promising, with numerous exciting developments on the horizon. As the Ethereum ecosystem evolves, the importance of scalable and efficient solutions cannot be overstated. L2 technologies such as sidechains, Plasma, state channels, and rollups are pivotal in addressing Ethereum’s scalability challenges, reducing transaction fees, and improving processing times.

In conclusion, Ethereum’s Layer-2 solutions are set to play a crucial role in the future of the blockchain. Despite the challenges, the potential for increased adoption, improved scalability, and the emergence of innovative use cases makes L2 technologies an essential component of Ethereum’s continued growth and success. As the ecosystem matures, the collaborative efforts of the community and developers will ensure that Ethereum remains at the forefront of decentralized technology.

Ethereum L2 solutions was originally published in iobuilders on Medium, where people are continuing the conversation by highlighting and responding to this story.

The Early Days: Scalability and Gas Fees

In its early days, Ethereum could process only about 15 transactions per second. As the platform’s popularity surged, particularly during the ICO boom of 2017, this limitation became glaringly evident. The low transaction throughput led to severe network congestion, causing delays in transaction processing and skyrocketing gas fees. Users had to compete by offering higher fees to get their transactions included in the next block, further exacerbating the issue. This bottleneck significantly impacted the user experience and constrained Ethereum’s potential for larger-scale applications, highlighting the need for scalability solutions.

Solutions:

• Sidechains: Sidechains are separate blockchains that run alongside the main Ethereum chain, designed to offload transactions from the mainnet. They operate under their own consensus mechanisms but are connected to Ethereum through two-way pegs, allowing assets to move between the main chain and the sidechain. By offloading some of the transaction load to these parallel chains, sidechains help alleviate the main chain’s congestion
• Layer 2 Solutions: Layer 2 solutions are built on top of the Ethereum main chain and aim to increase transaction throughput without sacrificing security. They achieve this by processing transactions off-chain and then settling the results on the main chain. There are several types of rollups (optimistic, zero-knowledge,…) but they all drastically increase the number of transactions that can be processed per second by reducing the data and computation load on the main chain.
• Beacon Chain and Shard Chains: The Beacon Chain is the backbone of the Ethereum 2.0 upgrade. It coordinates the network of validators and will, in the future, manage multiple shard chains, which are designed to further split the transaction load by creating multiple parallel chains, each capable of processing transactions independently. This means the network can handle many more transactions by distributing them across these shards.
• New Gas Model (EIP-1559): EIP-1559 introduced a significant change in how gas fees are calculated by implementing a base fee and a tip system. The base fee is burned, making it a dynamic component that adjusts automatically based on network congestion, aiming to smooth out fee volatility. This new model helps users predict gas costs more accurately and discourages the previous auction system, which often led to overpayments.

The Loss of Private Keys

In traditional Ethereum wallets, private keys are the sole means of accessing and managing funds, creating significant risks of loosing all your funds. Without a native recovery mechanism, the loss of a private key results in irretrievable loss of assets, a challenge especially for users unfamiliar with cryptographic key management.

Solutions:

1. Multisig Contracts: Require multiple keys to authorize transactions, adding security by ensuring that funds remain safe even if one key is lost or compromised.
2. Custodial Solutions: Third-party services manage private keys on behalf of users, reducing the risk of loss by entrusting security to a trusted entity.
3. Account Abstraction (ERC-4337): Allows more flexible account management, reducing reliance on a single private key by enabling methods like smart contracts and multisig setups, thus improving accessibility and security.

The Quest for Privacy

Blockchain’s inherent transparency, while vital for trust and security, exposes all transaction data to the public. This design ensures that sensitive information, including personal data and confidential business transactions, can be traced and viewed by anyone at any time. This data will remain accessible as long as a full node of the blockchain exists. This lack of privacy poses risks to users and organizations that need to maintain confidentiality while leveraging blockchain’s other benefits.

Solutions:

• Zero-Knowledge Protocols: Zero-Knowledge (zk) Protocols are cryptographic methods that allow one party to prove to another that a statement is true without revealing any information beyond the validity of the statement itself. They enable private transactions where the specifics of the transaction (like the amount and the parties involved) are hidden, but the integrity and correctness of the transaction are still verified and maintained. Smart contracts can be implemented using zk protocols to enable users to execute functionality on the blockchain without providing any information that could reveal their identities.

Crypto Texan | Aggregated on Twitter / X

The Oracle Problem: Accessing Real-World Data

Smart contracts on Ethereum and similar blockchains are powerful tools for automating agreements and processes. However, by design, they operate in an isolated environment — they only access and act upon data within the blockchain. This limitation restricts the range of applications for smart contracts because many useful scenarios require current, real-world information like weather, prices, or other dynamic external data. Without this, the potential for smart contracts remains confined to purely on-chain activities.

Solutions:

• Decentralized Oracles : Decentralized oracles are intermediaries that fetch data from outside the blockchain and provide it to smart contracts in a reliable and secure manner. These systems ensure that the data is accurate and tamper-proof by using a network of nodes to validate the information before it reaches the smart contract. By incorporating real-world data, smart contracts can react to external events and conditions, vastly expanding their potential applications.

What Is an Oracle in Blockchain? » Explained | Chainlink

The Environmental Toll: Energy Consumption

The proof-of-work (PoW) mechanism, used by Ethereum and other early blockchains, requires extensive computational effort to validate transactions and secure the network. This process involves solving complex cryptographic puzzles, which necessitates powerful hardware and results in significant electricity usage. The environmental impact of PoW, especially as the network grows, has been a major concern due to its large carbon footprint and unsustainable energy demands.

Solutions:

• Proof of Stake: Proof of stake (PoS) is a consensus mechanism that replaces the computationally intensive process of proof of work. Instead of miners competing to solve puzzles, validators in a PoS system are chosen to create new blocks and confirm transactions based on the amount of cryptocurrency they hold and are willing to “stake” as collateral. PoS drastically reduces the energy consumption of the network because it eliminates the need for continuous, intense computational efforts.

Ethereum Energy Consumption | ethereum.org

Storage Woes: Limited and Expensive Storage

The Ethereum blockchain, like many others, is designed for transparency and security, not for large-scale data storage. Storing significant amounts of data directly on the blockchain is prohibitively expensive because it requires more block space, which is a scarce resource. This limitation restricts the types of applications that can be effectively deployed, especially those requiring access to large data sets or frequent data updates.

Solutions:

• Decentralized Storage : Decentralized storage systems like the InterPlanetary File System (IPFS) provide a way to store data off the blockchain while maintaining a link to on-chain smart contracts. In these systems, data is stored across a network of nodes, each holding a portion of the data, and can be retrieved using unique identifiers. This approach dramatically reduces the cost of data storage by offloading the bulk of the data to a more efficient and scalable system outside the blockchain.

Almacenamiento NFT: Comparación entre IPFS, Filecoin y Arweave

The Need for Finality and Reversibility

In the traditional Ethereum proof-of-work (PoW) system, transactions do not achieve immediate finality. This means that after a transaction is included in a block, there remains a non-zero probability that it could be reverted due to a chain reorganization (reorg). This uncertainty, albeit small, complicates certain types of transactions and applications, especially those requiring high security and immediate trust, as it opens a window for potential double-spending attacks.

Suggested Solution:

• Checkpoint Blocks: In Ethereum’s proof-of-stake system, finality is achieved through a mechanism involving checkpoint blocks and validators. Each epoch starts with a checkpoint block, and validators vote for pairs of these checkpoints. When votes representing at least two-thirds of the total staked ETH are cast for a pair, the more recent checkpoint becomes “justified,” and the previous one is “finalized,” making blocks up to this point irreversible without significant loss. If finality stalls, an inactivity leak reduces the stakes of dissenting validators, helping the majority regain the needed two-thirds majority to finalize the chain. This ensures transactions are securely and permanently part of the blockchain.

Bridging the Gap: Lack of Interoperability

In its early days, Ethereum functioned as an isolated ecosystem. This isolation limited its ability to interact with other blockchains, hindering the broader adoption of decentralized technologies and the seamless transfer of assets across different networks. Such limitations were significant barriers to creating a truly interconnected and interoperable digital economy, where value and information could flow freely across various blockchain platforms.

Solutions:

• Bridges: Bridges are intermediaries that connect Ethereum with other blockchains, allowing the transfer of assets and information between them. They work by locking assets on one chain and issuing equivalent tokens or representations on the other, effectively enabling cross-chain transactions.
• Advanced Protocols like CCIP (Chainlink) and ZetaChain: Protocols like the Cross-Chain Interoperability Protocol (CCIP) developed by Chainlink and ZetaChain go beyond basic bridges by offering more sophisticated and secure mechanisms for cross-chain interactions. These protocols enable not just asset transfers but also cross-chain smart contract calls and data sharing. By facilitating deeper integration and interoperability, these protocols make it possible for developers to create complex applications that operate seamlessly across multiple blockchains. This leads to a more robust and versatile decentralized ecosystem, unlocking new opportunities for innovation and collaboration.

The Immutability Dilemma: Smart Contract Code

Smart contracts on Ethereum are immutable once deployed, which means their code cannot be changed. This immutability ensures trust and security by preventing tampering, but it also poses significant challenges. If bugs or vulnerabilities are discovered in a contract, they cannot be fixed or patched. This rigidity has led to significant losses and security breaches in the past, highlighting the need for a more flexible approach to manage and update smart contracts.

Solutions:

• Proxies (EIP-1967): Proxies are a design pattern used to make smart contracts upgradeable. They work by separating the contract’s logic and storage. A proxy contract acts as the user-facing interface, while the actual logic is contained in a separate, upgradeable contract. Users interact with the proxy, which delegates calls to the logic contract. When the logic needs updating, a new version can be deployed, and the proxy is pointed to the new contract without changing the user interface or storage. This structure allows developers to fix bugs, update functionalities, and improve their contracts over time without losing the accumulated state or requiring users to migrate to a new contract address.

Overcoming the Size Limit: Smart Contract Complexity

Ethereum imposes a 24kb size limit on smart contracts, which restricts the amount of code that can be deployed in a single contract. This limitation is meant to prevent overly large contracts from consuming excessive gas and slowing down the network. However, it also limits the complexity and functionality that developers can include in their contracts, potentially stifling innovation and making it challenging to build sophisticated decentralized applications (dApps).

Solutions:

• Diamonds (EIP-2535): The Diamond pattern, formalized in EIP-2535, is a design pattern that allows for modular smart contract development. It introduces the concept of “facets,” where a single “diamond” contract can have multiple facets, each containing its own set of functions. This structure enables developers to bypass the 24kb size limit by splitting the contract’s functionality across multiple facets, each deployed separately but accessible through the central diamond proxy.

Implementing Upgradeable Smart Contracts Using Proxy Patterns | Talentica.com

The Ever-Growing Chain: Managing Blockchain Bloat

The continuous growth of the Ethereum blockchain leads to significant storage and efficiency challenges. As more transactions occur and more data accumulates, the size of the blockchain becomes larger, making it increasingly difficult for nodes to store and manage the entire chain. This growth can lead to slower transaction processing times, higher storage requirements, and reduced accessibility for new participants, especially those with limited resources.

Suggested Solution:

• State Expiry : State expiry is a proposed mechanism to manage blockchain bloat by expiring or pruning old state data that is no longer relevant. Under this system, data that has not been accessed or used for a predefined period could be archived or removed from the active state, reducing the storage burden on nodes.
• Verkle Trees: Verkle trees are an advanced cryptographic data structure proposed to enhance the efficiency of state storage and retrieval. They are a type of commitment tree that combines the properties of Merkle trees and vector commitments, allowing for more compact proofs and efficient verification. Verkle trees reduce the size of proof data needed for verifying transactions and state changes, which can lead to faster sync times and lower bandwidth usage.
• State Expiry & Verkle Trees Integration with Shard Chains: Integrating state expiry and Verkle trees with shard chains, as part of Ethereum 2.0, could further enhance the scalability and efficiency of the network. Shard chains are designed to distribute the data and processing load across multiple parallel chains, each handling a portion of the network’s transactions and state. This combination can manage growth more effectively by localizing data and reducing the load on any single part of the network.

A Vision for the Future

Ethereum’s journey has been a testament to the resilience and ingenuity of its community. From navigating scalability issues and security breaches to pioneering energy-efficient consensus mechanisms and improving interoperability, Ethereum has continuously evolved. As we look to the future, the ongoing advancements promise to further solidify Ethereum’s position as a leading blockchain platform, capable of meeting the evolving demands of the decentralized world.

Join us as we continue to explore Ethereum’s transformative journey, witnessing how it overcomes new challenges and seizes emerging opportunities in the ever-evolving landscape of blockchain technology.

The Transformative Journey of Ethereum: From Inception to Innovation was originally published in iobuilders on Medium, where people are continuing the conversation by highlighting and responding to this story.

Hashgraph protocol

The Hedera Hashgraph protocol uses “events” which are basically small blocks of information, containing one or many transactions that have been submitted to the network alongside some overhead containing signatures, timestamp and hashes of previous events.

Nodes forming the network will constantly exchange these events with each other. These events, as mentioned before, contain hashes of previous events, which allow nodes to transfer to each other not only information about new transactions reaching the network, but also information about previous transactions (process known as “gossip about gossip”), effectively generating a “graph” of events that will allow nodes to reach a common consensus on events timestamp and ordering by virtual voting.

The Hedera Hashgraph protocol is quite complicated and honestly beyond the scope of this blog, but you can find a nice explanation in the following video :

Core Concepts

Hedera, at its core, consists of the following entities :

• Accounts: They can be compared to ethereum accounts, because they are in charge of delivering transactions to the network. However, they are technically very different. Hedera accounts have one or many keys associated to them. These keys (or some of them, depending on the account configuration) have to sign the transactions the account is submitting to the network. Accounts can hold any Hedera Token, but they need first to associate to it (only HBARs can be held without any previous association). To make it simple for ethereum users, an Account can be understood as an integrated multi-signature smart contract…
• Tokens: Hedera has taken the ERC20 and ERC721 standards a step further, embedding them into its core. In order to create a token you do not need to deploy a smart contract, just tell Hedera what kind of token you want and pay for the creation fees. Hedera fungible and non-fungible tokens offer the classic functionality (transfer, transferFrom, approve, …) plus some extra one like associating/dissociating and freezing/unfreezing accounts, pausing/unpausing the token…
• Smart Contracts: Since Hedera is EVM-compatible, any ethereum smart contract can be executed in Hedera. However Hedera’s smart contract are not just the byte code, storage and balance associated to it (like in ethereum), they also have administrators, they can stake their tokens automatically etc…
• Files: Hedera lets users store files (no more than 1KB per file) in a decentralized manner. As a matter of facts, smart contract’s byte codes are stored in multiple files. Files have administrator than can update the file’s content.
• Topics: We can also use the Hedera DLT as a queue where messages can be submitted and latter retrieved. Hedera guarantees proper ordering security (we can limit who can send messages) and availability.
• Scheduled transactions: Accounts are supposed to submit transactions to the network, however accounts can have multiple keys associated to them which means that multiple signatures are required for the account’s transactions to be accepted by the network. Normally, these signatures must be added off-chain then, when the transaction is ready, submit everything to a consensus nodes. To make this multi-signature process simpler, Hedera offers the possibility to send transactions that do not have yet all the required signatures attached to it, the network will store that transaction in a queue, waiting for the remaining signatures to arrive before the transaction can finally be submitted.

Fees

Fees in Hedera are paid using its native token “HBAR” although the amount to pay depends on the current HBAR to USD exchange ratio, the idea is for users to pay a fixed fee calculated in USD (the amount of HBAR will always be different though).

There are two categories of fees in Hedera:

• Transaction fees: paid once by the account submitting the transaction (to create an entity or operate with it).
• Storage fees: entities are not deployed on the DLT “forever”, they have an expiration time. Once an entity expires, it will be automatically removed from the DLT unless a renew fee is paid by the account defined as the renew account.

Governance

The Hedera network is, for the time being, fully managed by the Hedera governing council, an organization of up to 39 very well-known companies (currently only 27), each one running a node. Nevertheless, the goal is to completely decentralize the network at some point, letting anyone run a node.

Consensus protocol

The consensus protocol uses Proof-of-Stake, where nodes must have a minimum amount of HBAR to be allowed to validate events but cannot have more than a maximum amount (in order to prevent a node from taking over the network). Voting is proportional to the amount of staked HBAR. A transaction is validated and placed into consensus after it is validated by nodes representing an aggregate stake of over two thirds of the network’s total number of hbars (fixed at 50 billions).

Accounts and Smart Contracts can stake their HBAR to a node (or another account/smart contract) and get rewards when events are added to the hashgraph. Staking in Hedera, as opposed to staking on other DLTs, does not require the staked tokens to be locked, and slashing is not implemented in the protocol either, there is no “punishment” whatsoever for rogue nodes, at least for the time being…

There is a special account in Hedera (0.0.800 on mainnet) that centralizes the reward allocation. It holds all the rewards and distributes it proportionally to the accounts/contracts.

Accounts and contracts can be set to decline rewards.

Accounts

Hedera Accounts must be created (as opposed to ethereum where any public key is technically an account) and fees must be paid when doing it.

In order to create new accounts in Hedera you can use an official wallet provider :

https://docs.hedera.com/guides/mainnet/mainnet-access,

or the Hedera portal if you need a testnet account :

https://portal.hedera.com/.

You can also obtain a Hedera Account by asking anyone to transfer funds to your ethereum public address. The transfer operation will automatically create your Hedera account and creation fees will be deducted from the transfer amount.

Scans

If you need to scan Hedera’s transactions, accounts, smart contracts… you can use hashscan on every network:

mainnet : https://hashscan.io/mainnet/dashboard

testnet :https://hashscan.io/testnet/dashboard

The Hashgraph and consensus protocol is open-source.

API

Hedera exposes an API (HAPI) that allows for anyone to interact with its core entities (tokens, accounts, …). The HAPI communication protocol is gRPC over HTTP and data is serialized using protobuf. However Hedera provides an SDK for multiple programming languages like JavaScript, Java, Go… allowing a seamless integration of its HAPI in already existing applications.

The HAPI is subdivided into services, each one dedicated to a specific core entity (HTS for Token creation and management, HSCS for for Smart Contract creation and management etc…).

The two big advantages of the HAPI is that it gives the possibility to developers to interact with Hedera’s core functionality without implementing a smart contract and it offers a huge throughput (thousands of transactions per second) since transactions do not need to be executed by the EVM.

Network

Hedera currently has three public networks:

• Mainnet: Main Hedera network where HBARs have actual value.
• Previewnet: Pre-mainnet network, where smart contracts and/or entities can be tested before deploying to mainnet.
• Testnet: A network for developer to test their implementation without any risk. The big difference between this network and the “previewnet” is that Hedera resets its content sometimes, removing all the existing entities, which is why it must be used only for “ephemeral” testing.

Hedera’s networks have two different types of nodes

• Consensus nodes: These are the nodes that process incoming transactions and add them to the Hashgraph. Any interaction with a consensus node costs HBARs, even if it is a transaction that only reads data from the DLT.
• Mirror nodes: These nodes do not take part in the consensus process, they are just like databases that store the current status of the DLT so that anyone can query them for free. Consensus nodes provide state changes in the form of signed files to the mirror nodes, meaning that there can be a tiny delay between the moment a new transaction is added to the DLT and the new state is available in the mirror nodes.

Transactions

A Hedera transaction can contain different fields, depending on which HAPI service and method they are being delivered to, but generally speaking they all contain the following fields:

• Node Account: The consensus node ID the transaction is been delivered to.
• Transaction ID: The Id consists of the sending Account ID followed by the transaction start time (not to be confused with the consensus timestamps calculated by the consensus nodes of the network).
• Transaction Fee: Maximum fee the sending Account is willing to pay for the transaction.
• Valid duration: Number of seconds the user wants the transaction to be valid for, starting at the “starting time” indicated in the Transaction ID.
• Signature: A transaction must be signed at least by the sending account but in some cases, transactions must be signed by multiple accounts.

Hedera’s transactions can trigger further transactions (for instance, when a smart contract method creates a new Token…). Parent and child transactions ID will be the same but child transaction will have an extra nonce indicating the order in which they were executed.

When a transaction is submitted and processed by the network, users can ask for the following confirmations:

• Receipt: receipts contain basic information about the transaction, they are free and only available for 3 minutes after the transaction gets validated.
• Record: records contain more information about the transaction than receipts, they are also available for only 3 minutes after the transaction gets validated but are not free.
• State Proof: This is a document signed by the consensus nodes that contains all the information related to the transaction, the big difference between state proofs and receipts/records is that state proofs could be use to cryptographically validate a transaction.

Compatibility with ethereum

Hedera is becoming more and more compatible with ethereum.

To begin with, consensus nodes run an EVM, allowing developers to deploy smart contracts implemented using Solidity or any other EVM compatible language.

Then, more recently, Hedera has added a new type of node to its networks : “relay nodes”. These nodes expose the ethereum JSON-RPC API, so that ehtereum-compatible wallets (metamask, …) can interact with them. Relay nodes act as a bridge between these ethereum wallets and the Hedera network, the way they do it is relatively simple, they receive ethereum transactions and they encapsulate them into Hedera transactions that are sent to the HSCS (Hedera Smart Contract Service).

Each relay node has an account which is the one that pays the transaction delivery fees, however transaction execution fees are paid by the account signing the ethereum transaction. For the time been, relay nodes are opened to anyone but at some point it is expected for these nodes to charge some kind of fee to compensate for the transaction delivery fees that are automatically charged to the relay node’s account.

New to trading? Try crypto trading bots or copy trading on best crypto exchanges

Hedera Hashgraph DLT Overview was originally published in iobuilders on Medium, where people are continuing the conversation by highlighting and responding to this story.

Here is our monthly summary of enterprise blockchain related news in May 2022

Digital Assets / Securities

• JPMorgan Dips Into DeFi With Singapore Pilot on Asset Tokenization - BeInCrypto
• Fidelity Digital Assets Plans to Double Headcount This Year: Report
• South Korea Sets Up Digital Asset Committee, Fast Tracks Crypto Regulation Efforts | Bitcoinist.com
• Binance Gets a Digital Asset Provider License in Italy

Digital Currencies / CBDC’s

• Financial institutions respond to Federal Reserve CBDC paper - Ledger Insights - enterprise blockchain
• Governments pushing for CBDCs smell blood as Terra Classic struggles
• Fed paper looks at the potential effects of CBDC on monetary policy
• SWIFT Is Experimenting With Decentralized Technologies to Allow CBDC Interconnection
• India to roll out CBDC using a graded approach: RBI Annual Report

NFTs

• NFTs: Palm NFT launches beta version of marketplace
• Prada Adds NFTs to Timecapsule Project
• Audi launches novel fractional NFT - UNLOCK Blockchain
• UK's Wembley Stadium adopts blockchain ticketing TIXNGO starting with Sheeran concert - Ledger Insights - enterprise blockchain
• Binance NFT head: 'Real value creation of the NFT is not really here yet'

Blockchain Industry

• Honda, Ford participate in blockchain consortium MOBI's first EV battery standard - Ledger Insights - enterprise blockchain
• Philippines to explore blockchain use cases, launches training program
• Brazilian Development Bank Launches Blockchain Network
• DMG Invests USD $1 Million in The INX Digital Company

Institutional Crypto

• Copper.co receives Swiss regulatory approval
• TECHFUND has established its third footprint by establishing a basis in Europe to accelerate security token-related startups
• Los inversores institucionales pierden la fe en Ethereum mientras aumentan la asignación a XRP y ADA
• 'Consistently Strong' Institutional Crypto Demand Stayed Despite Price Slump - WisdomTree

May 2022- Enterprise blockchain monthly review was originally published in iobuilders on Medium, where people are continuing the conversation by highlighting and responding to this story.

Here is our monthly summary of enterprise blockchain related news in April 2022

Digital Assets / Securities

• Paraiso Real Estate Introduces Tokenized Vacation Rental Portfolio
• SIX Digital Exchange Inks Partnership with Daura
• Dallas Cowboys' partnership with Blockchain.com signals more mainstream crypto exposure
• Deloitte and TaxBit Form Alliance to Meet Exponential Market Demand for Digital Asset Tax Information and Cost Basis Reporting Support

Digital Currencies / CBDC’s

• EMTECH, HaitiPay Demo CBDC Proof of Concept
• Number of Central Banks Involved in CBDC Projects Almost Doubles in One Year
• The European Central Bank Published Privacy Options for CBDC
• Argentinian Government Advances the Creation of a National CBDC - News Bitcoin News

NFTs

• Archie Comics and Palm NFT Studio are inviting Fans to help Define the Next Series of Comic Books " coin.news
• Warner Bros. Announces Unique Features For Upcoming Bat Cowl NFT Collection
• Starbucks plans a "global digital community" around coffee with an NFT loyalty program
• Cannabis-focused crypto startup is launching an NFT community
• Mercedes reveals new F1 art rear wing NFT design for Miami
• OpenSea top-10 NFT projects soar as new liquidity enters the market

Blockchain Industry

• World's first regulatory radar to monitor the blockchain-based asset token space
• HSBC, DBS trial blockchain trade platform GSBN for trade finance - Ledger Insights - enterprise blockchain
• Media: Samsung Asset Management to Launch Asia's First Blockchain ETF - The Times Hub
• Diamond traceability added to the Aura blockchain, of which Cartier and Bulgari are members - Ledger Insights

Institutional Crypto

• First Mover Asia: Singapore's Distaste for Retail Crypto Spooks Institutional Money
• Institutional Investors Cooling on Crypto as Weekly Outflows Top $120M
• 80% of Institutional Investors Expect Crypto to Overtake Traditional Investments, Survey Shows - Featured Bitcoin News
• 7 in 10 Retail and Institutional Investors Plan to Buy More Crypto, Bitstamp Survey Finds

April 2022- Enterprise blockchain monthly review was originally published in iobuilders on Medium, where people are continuing the conversation by highlighting and responding to this story.

Here is our monthly summary of enterprise blockchain related news in March 2022

Digital Assets / Securities

• IX Swap Lists Security Token of World's Most Valuable Sapphire
• Nearly half of crypto owners first bought digital assets in 2021: Survey
• Executive Order on Ensuring Responsible Development of Digital Assets | The White House
• The Growing Digital Asset Lifeline in Ukraine

Digital Currencies / CBDC’s

• ECB official suggests importance of physical stores accepting digital euro
• Bank of Canada and MIT to Conduct a Joint Research Project on CBDC
• Bank of England sketches out first regulatory approach to crypto
• PwC: More Than 80% of Central Banks Are Considering a CBDC

NFTs

• NFT LA: Attract the mainstream, focus on Web3 and use cases
• DC Comics Believes Batman NFT Drop Will Be a "Watershed Moment"
• Mark Zuckerberg says NFTs are coming to Instagram soon
• Citi report values metaverse at $10 trillion plus by 2030 - Ledger Insights - enterprise blockchain
• Nifty partners with Samsung for smart TV NFT platform - Ledger Insights - enterprise blockchain
• Bulgari is the latest brand to launch an NFT. What does it mean for the fashion world?
• WeChat suspends NFT accounts to 'avoid speculation in digital assets' - CoinGeek

Blockchain Industry

• Bitbond Launches Token Tool for Web3 Powered Asset Tokenization
• Japan's trade blockchain Trade Waltz goes into production this week - Ledger Insights - enterprise blockchain
• Oil and Energy Tokenization Model Provides a New Capital Raising Instrument Utilizing Blockchain
• Bitcoin to the rescue: Cryptocurrencies' role in Ukraine

Institutional Crypto

• Nueva casilla de la Renta para las criptomonedas: por qué la incluye Hacienda y qué tenemos que hacer con ella
• Institutional crypto funds see largest capital inflows for 3 months
• Bitcoin Surges Past $47,000, And Institutional Investors May Not Be Far Behind
• Nexo and Amber Group executives claim 'exponential' growth in crypto institutional investment

March 2022- Enterprise blockchain monthly review was originally published in iobuilders on Medium, where people are continuing the conversation by highlighting and responding to this story.

Here we bring you the latest news of the blockchain industry of February 2022

Digital Assets / Securities

• Talos Adds Access to OSL's Global Digital Asset Exchange
• Credit Market Leader Wizkey Leverages Algorand to Power its Fixed Income Financial Asset Tokenization Tools
• InCore Bank expands its Digital Asset Brokerage to a 24/7 Banking Service with AlgoTrader
• Security token startup Securitize acquires Pacific Stock Transfer - Ledger Insights - enterprise blockchain

Digital Currencies / CBDC’s

• La urgencia de regular las criptomonedas
• The Future of Money: Gearing up for Central Bank Digital Currency
• Central Bank of Kenya seeks public input on potential CBDC
• Central bank digital currencies: defining the problems, designing the solutions
• After Zambia, Kenya explores possibility of a digital currency

NFTs

• Puma registers ENS domain, changes name to Puma.eth on Twitter
• NASCAR partners with WAX blockchain for race day NFTs - Ledger Insights - enterprise blockchain
• OpenSea planned upgrade stalls as phishing attack targets NFT migration
• Are NFTs coming soon to your favorite video games?
• These Display Startups Are Bringing NFTs Into the Real World - Decrypt

Blockchain Industry

• ADB partners with ConsenSys on blockchain project | ConsenSys
• Block, Circle, Coinbase create decentralized identity solution for KYC'd blockchain transactions - Ledger Insights - enterprise blockchain
• Google Launches Blockchain Division - Newblock
• zkSync 2.0: Public Testnet is Live!

Institutional Crypto

• Staking in 2022: Ethereum's Merge, Institutions, Layer-2, and Liquid Staking
• What's shaping the future of the institutional crypto market?
• America's oldest bank to launch institutional crypto custody service
• Institutional Crypto Services Firm BCB Group Acquires Digital Asset Shop LAB577

February 2022- Enterprise blockchain monthly review was originally published in iobuilders on Medium, where people are continuing the conversation by highlighting and responding to this story.

New year, new monthly updates! Here we bring you the latest news of the blockchain industry of January 2022

Digital Assets / Securities

• Renta 4 and Allfunds complete first orders of new tokenized Spanish fund
• DeFi Technologies Inc. Featured in Syndicated Broadcast Covering Investment into SEBA Bank, a Swiss Global Digital Assets Pioneer
• UnionBank of the Philippines Selects METACO and IBM to Orchestrate its Digital Asset Custody Operations
• Update: Prometheum Marks Major Milestone for Digital Asset Securities, Meets SEC Requirements to Operate an "Alternative Trading System" for Digital Assets for Subsidiary "Prometheum ATS"

Digital Currencies / CBDC’s

• Germany's 2021: New regulations, the digital euro and NFTs on the rise
• Thailand restricts use of digital assets for payments - Ledger Insights - enterprise blockchain
• Bank of America Says US CBDC Would Preserve Dollar's Status as World's Reserve Currency
• Bank of Korea completes first phase of digital currency pilot
• Japan must cooperate with Europe, US on CBDC, BOJ says

NFTs

• Twitter comienza a ofrecer NFTs: por ahora para fotos de perfil y solo para suscriptores de Twitter Blue
• Making it easier for everyone to buy NFTs
• Atari is celebrating its 50th anniversary by combining NFTs with lootboxes | VGC
• The Beatles and John Lennon memorabilia to be sold as NFTs
• Picasso heirs launch NFTs of never-before-seen ceramic work by famed artist

Blockchain Industry

• Warner Music partners with Sandbox blockchain game for music events - Ledger Insights - enterprise blockchain
• Google Cloud wants to help more companies adopt and use the blockchain
• Blockchain-enabled digital fashion creates new business models for brands
• BSTX Receives SEC Approval for Blockchain-Powered Securities Exchange

Institutional Crypto

• Facebook is slowing down its cryptocurrency venture
• Shift Markets Continues to Revolutionize Institutional Crypto Solutions - FinanceFeeds
• Flushing it: $8B New York commercial bank to offer Bitcoin services
• Aave launches its permissioned DeFi platform Aave Arc

January 2022- Enterprise blockchain monthly review was originally published in iobuilders on Medium, where people are continuing the conversation by highlighting and responding to this story.

We bid farewell to 2021 with a recap of all the most outstanding news of the blockchain industry of December!

Digital Assets / Securities

• Renta 4 hará banca universal y lanzará activos digitales en su nuevo plan estratégico
• Coinstreet And Somerley Collaborate To Form New Venture To Provide Professional Services In Security Token Offerings ("STO") In Hong Kong
• Cloud Security Alliance reviews Corda blockchain security - Ledger Insights - enterprise blockchain
• Digital assets outlook 2022: All eyes on regulations as capital pours in | Alternatives | AsianInvestor
• One Big Regulatory Question Holds Advisors Back From Crypto

Digital Currencies / CBDC’s

• HSBC and IBM create successful multi-ledger CBDC demo
• Kazakhstan Piloting a CBDC on R3′s Corda Platform
• UK has no plans for a wholesale CBDC, envisages banks enabling synthetic - Ledger Insights - enterprise blockchain
• Mexico central bank plans to launch CBDC by 2024
• Nigerian Experts: CBDC Still Unattractive to Users Despite Claim of 'Excellent' Adoption Rate - Emerging Markets Bitcoin News
• WhatsApp begins offering Novi money transfers to some users in the US
• Siemens taps JP Morgan's Onyx for blockchain-based payments - Ledger Insights - enterprise blockchain

NFTs

• Michael Jordan Jumps Into Web3 via Solana App for Athletes - Decrypt
• L'Oréal calls out lack of female representation in NFT space
• DraftKings Marketplace plans to launch gamified NFT collection next NFL season
• Adidas sold more than $22 million in NFTs, but it hit a few snags along the way
• Chinese Tech Giants Ready Metaverse, NFT Moves Despite Regulatory Scrutiny

Blockchain Industry

• Microsoft Leads $27M Funding Round for Palm NFT Studio
• Blockchain-powered breakthrough on mutual fund
• ConsenSys Collaborates With Mastercard on New Ethereum Scaling System
• Paris Blockchain Week Summit Returns April 12-14, 2022 - The Daily Hodl
• Hedera, a Distributed Network Targeting Businesses, Jumps Into Metaverse Fray

Institutional Crypto

• More businesses offer pay in cryptocurrency in a bid to lure younger workers
• 100 Companies Fail to Obtain Crypto Licenses in Singapore Due to Tough Regulation - Regulation Bitcoin News

December 2021- Enterprise blockchain monthly review was originally published in iobuilders on Medium, where people are continuing the conversation by highlighting and responding to this story.