A zero to 100 explanation of how Ethereum rollups work

This guide is intended to cover everything you need to know about rollups and how they work, in one place, with as little assumed knowledge as possible. We'll start with knowledge that > 90% of you already know, such as why scaling is needed, and very quickly delve into details that < 1% of the community fully grasps.

Because the guide is intended to cover everything all in one place, it's long. If you feel as though you already have a grasp on the basics, feel free to skip to some of the more advanced sections.

As the number of people using Ethereum has grown, the network has reached capacity. When this happens, costs for using the network go up, creating the need for scaling solutions.

The Ethereum network's (target) capacity is currently ~14 transactions per second (TPS). Any time there are more than ~14 TPS on the network, users will get into a bidding war to ensure that their transaction is prioritised. Only the top ~14 transactions each second, when ranked by how much they are willing to pay in fees, will have their transactions processed. In times of high congestion, this can lead to very high transaction fees as demonstrated in the graph below.

Ethereum cannot achieve its goal of becoming the world computer when it charges $20 per transaction. Vitalik claims that “the internet of money should not cost 5 cents a transaction,” implying that a transaction fee of even $0.05 is too high. Consider if you wanted to use Ethereum to buy a coffee, would you pay a $20 fee to purchase a $5 coffee?

The narrative used to be that blockchains could never scale and the industry was doomed. Fortunately, the narrative has shifted away from “whether or not blockchains can scale” to “which scaling solution will win.” We'll examine what's emerging as a potential winner: Rollups. Ethereum needs scaling solutions, like rollups, to bring its transaction fees way down or it risks being replaced by a more scalable competing blockchain network.

The Ethereum block gas limit sets the capacity of Ethereum by capping the maximum units of computation in each block. The block gas limit on Ethereum currently targets 15,000,000 units of gas per block. Each transaction on Ethereum costs a number of units of gas. A simple ETH transfer costs 21,000 units of gas, the more complex the transaction, the more units of gas it costs. The average gas cost of a transaction on Ethereum is currently ~90,000 units of gas.

The average Ethereum block can fit 15,000,000 / 90,000 = ~167 transactions. Blocks are produced on Ethereum every 12 seconds so we can calculate TPS as ~167 / 12 = ~14 TPS.

If the block gas limit sets the limit for Ethereum's scalability, why can't you just increase it? The short answer is you can, and we have. The long answer is 

When Ethereum first launched in 2015, it had a block gas limit of 5,000 units of gas. It has since been increased on 13 different occasions to where it sits today with a target limit of 15,000,000 units of gas and can increase to 30,000,000 units of gas during very high congestion. You can also increase Ethereum's capacity by keeping the block gas limit the same but reducing the units of gas it costs for a transaction.

the blockchain can process lots of transactions, measured in TPS.

Scalability

the blockchain is run by many “trustless” nodes across the world, not run by a small group of centralised “trusted” nodes.

Decentralisation

the blockchain is resistant to attack even if there are malicious nodes in the network. Ideally, it should be able to handle up to 50% of nodes being malicious.

Security

Most blockchains can achieve at least two of three desired properties but achieving all three is extremely difficult. Generally, optimising for one property comes at the cost of another.

Ethereum optimises for security and decentralisation but is poor at scalability. Optimising for scalability by increasing the block gas limit comes at the cost of decentralisation. Ethereum is decentralised because the cost to run a node is minimal - you can run an Ethereum node on a Raspberry Pi. Increasing the block gas limit requires the nodes to verify transactions more quickly and store more data over time, raising the computational power and storage requirements to run a node. If the block gas limit is increased too much, you might no longer be able to run an Ethereum node on a Raspberry Pi, instead, maybe only large companies with access to enterprise-grade hardware can run nodes. This would mean less decentralisation.

Many blockchains have been willing to make these trade-offs. Binance Smart Chain is a blockchain that optimises scalability and security at the cost of decentralisation. Polkadot and Avalanche are blockchains that optimise scalability and decentralisation at the cost of security.

Ethereum has been unwilling to trade-off either its decentralisation or security and has instead focussed on developing scaling solutions capable of optimising for all three.

Another way to scale a blockchain on-chain is sharding. Sharding is the process of splitting a database horizontally to spread the load. In an Ethereum context, sharding could reduce network congestion and increase TPS by creating new chains, known as “shards”. This would lighten the load for each validator who is no longer required to process the entirety of all transactions. This, in theory, achieves scalability without sacrificing security or decentralisation.

Ethereum's initial scaling roadmap proposed the creation of 64 shard chains, each with separate execution, state, smart contracts, balances, etc… However, this solution introduces unnecessary complexity, a worse user experience and new attack vectors. Additionally, shuffling validators between shards is very difficult.

Ethereum has abandoned the concept of sharded execution chains from its scaling roadmap in favour of Danksharding (named after its creator Dankrad Feist), where there is only one execution chain and the other Shards are for storing blobs of data only.

However, even Danksharding is incredibly complex. For now, Ethereum will focus on even simpler solutions such as Proto-Danksharding (named after its creators Protolambda and Dankrad Feist). Vitalik jokingly asked at ETHCC 2022 “should we cancel sharding?” after demonstrating how much TPS could be achieved with Proto-Danksharding alone. Proto-Danksharding stores blobs of data on Beacon nodes instead of separate shard chains and introduces a separate fee market for storing the blobs.

Sharding is its own complex topic which we won't cover in this research piece.

Off-chain scaling is the concept of achieving scalability without modifying the main blockchain protocol and therefore without compromising the core protocol's scalability or security.

From now on we will refer to the main Ethereum blockchain / mainnet as Layer 1 (L1).

State Channels, Optimistic Rollups and Zk-rollups derive their security directly from the Layer 1 and will now be referred to as Layer 2 (L2) solutions.

Sidechains, Validiums and Plasma chains derive their security separately from the Layer 1 and whilst they are off-chain scaling solutions, they are not considered Layer 2 solutions.

State Channels and Plasma chains are mostly outdated scaling solutions as newer, better solutions have been developed. We won't focus much on these. The Raiden Network is an example of a State Channel on Ethereum and Omise Go was an example of a Plasma chain.

Sidechains were one of the first Ethereum scaling strategies and are still extremely popular today. Let's take a look at sidechains.

The most popular sidechain network is Polygon POS. Sidechains are completely separate blockchains connected to Ethereum via a 2-way bridge. Sidechains have their own consensus, block production, validators and design considerations. The purpose of sidechains is to help scale Ethereum and so their focus is on maximising throughput. Sidechains are willing to make the tradeoffs in decentralisation and security that Ethereum is not.

Sidechains put users in control of the tradeoff-making decision. If you value security and decentralisation, stick to mainnet, if you're willing to make the tradeoff, use the sidechain.

Sidechains are by design less secure than mainnet Ethereum. They might not be best for billion-dollar DeFi protocols but for low-value transactions, the popularity of Polygon POS has demonstrated that many users are willing to make the compromise in exchange for lower transaction fees. As one of the first scaling strategies, sidechain networks have had a first-mover advantage. Polygon POS is still the most popular and transacted on Ethereum scaling solution.

What makes sidechains less secure than Ethereum?

Polygon POS is a Proof of Stake blockchain. It relies on the assumption of an honest majority of validators, if this assumption is broken, the network is open to a series of attacks including double-spending. Polygon POS at the time of writing has $3 billion worth of Matic at stake securing the network across 100 validators. This is compared to Ethereum's beacon chain which has $21 billion worth of ETH securing the network across ~500,000 validators. The cost of a 51% attack on the Ethereum beacon chain is ~$10.7 billion and would require control of 250,000+ validators. The cost of a 51% attack on Polygon POS would cost ~$1.5 billion and would require control of as few as 6 out of the 100 current validators.

Polygon's staking implementation is done at the smart contract level. All $3 billion securing the Polygon chain is held within a single upgradable smart contract. Upgrade permissions to the contract are controlled by a 5 of 8 multisig wallet, four key holders are from Polygon with the other four key holders chosen by Polygon. In theory, Polygon would only need to collude with one external party or the 4 external parties would only need to collude with one keyholder from Polygon, to drain the network's entire security budget making off with at least $3 billion in the process.

Additionally, moving assets between Ethereum and Polygon POS requires cross-chain bridging which is notoriously insecure. Many of the largest blockchain hacks have been a result of vulnerabilities discovered in cross-chain bridges. If a vulnerability was exploited on the Polygon POS bridge any assets you had bridged between the networks could be lost.

All of the above security compromises are by design in return for an increase in TPS. Polygon has received much criticism for the security tradeoff choices they have made. However, Polygon POS is not the only Ethereum scaling solution that Polygon offers. Polygon has utilised the capital they have obtained from their success with the Polygon POS chain to push forward the entire Ethereum scaling ecosystem including the development of the first zkEVM rollups. The Ethereum scaling ecosystem and rollups would not be as advanced as they are today without Polygon. Polygon gives users the choice to decide for themselves which scaling solution to use based on their judgement of how much security they are willing to trade-off.

But what if scaling could be achieved without compromising on security? Enter rollups.

As we saw with sidechains, as soon as you take block production and consensus of the chain's state off of Ethereum, the sidechain needs to rely on its own security model which is almost always going to be less secure than Ethereum.

But what if your new blockchain and each of its blocks were contained inside of Ethereum and validated by Ethereum's L1 validators with the full strength of Ethereum's $21 billion security budget, whilst still moving execution of transactions within blocks off-chain? This is rollups.

making sure that the transaction data is available to users and block producers (consensus nodes).

Data availability

ensuring nodes agree on the order of transactions included in a block.

Consensus

where execution layers verify proofs, resolve disputes, and transfer assets between execution layers.

Settlement

the layer where applications live and state is updated.

Execution

Ethereum is considered a monolithic blockchain. An Ethereum client like (pre-merge) Geth will handle all four key functions of the Ethereum blockchain. Rollups are modular blockchains that split the four key blockchain functions up between different blockchains depending on their implementations. We'll look at smart contract rollups.

Rollups rely heavily on the concept of compressing transactions. To understand rollups, we need to understand how an ETH L1 transaction looks. Below, we'll break down a randomly chosen ETH transfer transaction. If you know how to do this, you can skip to the next section.

Let's break down the following real transaction from the Ethereum blockchain. This transaction was chosen at random. This is a simple ETH transfer from one address to another. You can see the chosen transaction on Etherscan here:

https://etherscan.io/tx/0xe9ab7969753ac82c2135d57059989fd74b1bbc226142f98a66106bcbf2886596

First, we need to gather the raw transaction data for this transaction. This can be done for this transaction by providing the transaction hash to Etherscan's API using the following URL:

https://etherscan.io/getRawTx?tx=0xe9ab7969753ac82c2135d57059989fd74b1bbc226142f98a66106bcbf2886596

The raw transaction data (stored as hexadecimal) for this transaction is:

We'll convert it to JSON format to make it more human-readable as below:

{
    nonce: 0,
    gasPrice: 22400000000,
    gas: 21000,
    to: 0x76a031c079a0482b573eb53db867f3991d564d7f,
    value: 2032025600000000000,
    data: 0x0,
    V: 38,
    R: 0x1165e2adb7d5a1c3b26d872e0314019220139f3b42c2f10029e818e9654bc8b2,
    S: 0x337b4110eb2f65bc2afea40b36740ae6b162a68afe9dcd711fc8d46dfdf947f2,
}

A transaction counter that reflects how many transactions this address has previously sent. The nonce value is required to prevent replay attacks.

nonce

the amount of ether (in wei) willing to be paid for each unit of gas.

gasPrice

the maximum gas the originator is willing to buy for this transaction.

the amount of ETH to transfer from sender to recipient (in wei).

value

an optional field to include arbitrary data. 0x0 means no data.

data

the V, R & S fields form the signature and are generated when the sender's private key signs the transaction and confirms the sender has authorised the transaction.

V, R & S

together form the signature. Sig = (r , s).

R & S

the recovery identifier. Multiple (r, s) values on the elliptic curve can be derived without it. Also specifies the chain ID to prevent replay attacks on other chains. Calculated as CHAIN_ID*2+36. A value of 38 is used for Ethereum transactions (ETH mainnet CHAIN_ID = 1).

For the sake of demonstration, we'll convert from hexadecimal to binary to break the transaction down into its individual components and measure its size (you can use any hexadecimal to binary converter):

This transaction is 880 bits or 110 bytes which is approximately the size of any standard ETH transfer transaction. The binary is encoded using 

 (RLP) serialisation. You can use an RLP decoder to decode the transaction, however, we will decode the binary step by step to show the process below. If you don't care about understanding the breakdown you can skip to the Size Summary Table.

The first two bytes of an RLP encoded transaction are put there by the RLP encoder to assist in decoding the transaction.

The third byte will specify the size (in bytes) of the next value. The size is determined by taking the decimal value of the third byte and subtracting 128. For this transaction, the third byte equals 128 meaning that the nonce value is 128 - 128 = zero bytes or just 0.

The fourth byte specifies the size (in bytes) of the gas price. For this transaction, the fourth byte equals 133, meaning 133 - 128 = 5. Thus the gas price takes up the next 5 bytes worth of data.

The above process is repeated for the transaction as follows below.

If the value is only 1 byte long (e.g. V in our transaction), no size specifier precedes the value. You can know if the value is only 1 byte long as its value will be less than 128.

RLP encoded transactions are of the order: nonce, gasPrice, gas, to, value, data, V, R, S.

We can summarise the size of each value, including its RLP encoding component, of the transaction above as follows:

Understanding breaking down an Ethereum transaction is important as generally the larger the transaction size the more expensive it is to execute on the Ethereum network. Rollups can achieve the same Ethereum transaction whilst only sending ~12 bytes of data to the Ethereum network allowing for much cheaper transactions. We'll find out how this is possible later on.

Rollups are blockchains inside of a blockchain - hence the name rollup. Rollups store blocks for their blockchain within smart contracts on the L1. There are two types of smart contract rollups:

. Each rollup block contains transaction data for the transactions executed on the rollup chain. However, the transaction data is only stored as callData within the rollup smart contract on Ethereum, rather than being executed like a regular transaction. Execution of transactions is done on the rollup chain according to the transactions defined in the rollup blocks on Ethereum.

The minimum cost to conduct a transaction on the Ethereum blockchain is set at the protocol level as 21,000 units of gas (“the base gas fee”). Even the simplest of transactions, an ETH transfer, will cost 21,000 units of gas. However, storing bytes of data as callData on the Ethereum blockchain only costs:

16 units of gas per byte of non-zero data

4 units of gas per byte of zero data (i.e. 00000000)

As we recall, a simple ETH transfer is ~110 bytes of data. Storing a single ETH transfer transaction as callData rather than executing it only costs 110 * 16 = ~1,760 units of gas.

To create a rollup block with the above transaction, the base gas fee of 21,000 units of gas still needs to be paid, as writing the callData to the blockchain is executing a transaction. The rollup can produce a block with only one transaction in it, however, this will cost a total of 21,000 + ~1,760 = ~22,760 units of gas which is more expensive than just executing the transaction on Ethereum mainnet. However, most rollup blocks will contain more than 1 transaction per block and 

the genius of rollups is that the 21,000 gas base fee only needs to be paid once per block.

A rollup block with just 100 ETH transfer transactions would cost a total of 21,000 + ((110 * 16) * 100) = ~197,000 units of gas or just ~1,970 units of gas per transaction. Executing each transfer on mainnet would cost 21,000 * 100 = 2,100,000 units of gas in total or 21,000 gas per transfer. 

A basic rollup delivers a ~10x increase in TPS on ETH transfer transactions 

(equivalent to a 90% reduction in fees) whilst still relying on the full security and decentralisation of the L1.

Rollups can achieve much more than a 10x increase in TPS. The table below shows a comparison between storing an ETH transfer in a basic rollup vs a compressed rollup.

If we don't need to execute transactions on L1, we can remove redundant data and apply some clever compression tricks. We'll outline a theoretical transaction compression strategy originally proposed by Vitalik below.

- Rollups don't need RLP encoding and can save 10 bytes. RLP transactions ‘waste' two bytes with the RLP header and a byte specifying the size for each transaction parameter (even for parameters that don't exist). This can reduce the transaction size to ~100 bytes.

- Rollup transactions don't need a nonce. As the nonce is incremented by 1 for each transaction, it can be recomputed when needed for execution by looking at the prior state of the blockchain. Our transaction doesn't save any data by nonce omission as its nonce value is 0 (bytes). Any transaction with a nonce value greater than 0 would save data.

- Gas prices are stored in wei and are generally large numbers. In our transaction, it took 5 bytes of data to store a gas price of 22400000000. Instead, we could set gas based on a fixed range of prices. For example, choosing a Gas Price as 16 consecutive powers of two. By limiting Gas Price to only 16 possible values, you could store the gas price for only 0.5 bytes or less. This would reduce the transaction size to ~95.5 bytes.

- As above, this field could be limited to a small range of options. This saves a further 1.5 bytes, reducing the transaction size to ~94 bytes.

- The address field takes up a lot of data (20 bytes). Instead of storing the full address, rollups can store an index for a mapping of addresses stored elsewhere. E.g. send to the 1034th address in the mapping. By only storing the address index in the transaction, we can reduce the to field to ~4 bytes. The transaction is now ~78 bytes.

- The value field in an Ethereum transaction is priced in wei, making it a large number. We cannot omit the value field or reduce it to a fixed set of values. However, we can write it in scientific notation instead of wei to save on data. Using scientific notation will save a further ~5 bytes bringing the total transaction size down to ~73 bytes.

- The data field does not apply to an ETH transfer so it can be emitted entirely (however, it would be required on more complex transactions). This field was already omitted on our mainnet transaction, so no savings are recorded here.

The comprehensive guide to scaling Ethereum & Rollups

The most common mistakes that teams make when it comes to building a web3 platform.

During the past year I've had to look at, consult for, put together a commercial proposal and/or been involved in the Product Definition of around 100 web3 projects and would like to share the most common mistakes that teams make when it comes to building a web3 platform.

The content of this post is my personal opinion and not necessarily that of my employer.

Some of the examples I describe below are projects of founders that have become Labrys' clients, and some are not.

The examples below are related to projects building their first web3 platform and not of web3 native established projects.

Most, if not all, projects are successfully delivered when there's a well defined scope, requirements and product definition in general. Some clients would want a quote produced from a pitch deck, mockup or google doc with a vague description and some bullet points.

When it comes to web3, or software development in general, the 

phase of the project is perhaps the most critical. By skipping PD, there's always surprises that end up with scope creep, blown-out budgets and delayed delivery. Spending time on User Journeys, defining (and prioritizing!) requirements, and having a complete set of User Stories (plus other techniques) will set the foundation of the platform.

Interestingly, it's often the case that, while going through this phase, disagreements between project team members (usually founders) arise and, needless to say, it's better to iron out things at the beginning instead of in the middle of the project.

Product Definition is a paid service that Labrys can provide to its clients and whilst most will tell you that they understand the importance of it, many opt not to pay for it, instead hoping to maximize their budget on direct development. In my experience, this does not save costs in the long run and only leads to more expensive mistakes during development.

I'll start by saying that not every single web3 platform needs a token. And those platforms where a token is required, should spend a great deal of time defining the token economics (aka tokenomics).

In order to justify the existence of a token, some projects force demand with use cases such as “buy my product/service with my $TOKEN” and then they get into this scenario:

Lack of token utility

In this scenario, the users looking to procure the platform's product or service only need to obtain the token just so they can spend it (often right away) without needing to hold it, which means the token demand is temporary at best.

Another inefficient token use case is “Staking”. The original purpose of staking was to secure POS networks, validate blocks and be rewarded for doing so. These days, a lot of platforms have “staking programs” with the sole objective of reducing circulation, guaranteeing team and early investors the possibility of selling their tokens with less sell pressure. Good read on the topic 

Some teams issue a token (before having a platform) with distributions not only skewed in favor of the team and early investors but also badly designed Vest Schedules which typically generate the below price action:

Unfair Token Distribution

While this might be good for early investors and founders, now you have a community pissed off and that will probably not only give the project bad marketing on social media but also 

We recommend our clients to spend time defining their token economics with specialized teams, such as our partners at 

Here are some good resources for further reading on tokenomics:

If the platform needs a token, founders must make sure the tokenomics are designed correctly;

If the platform does not need a token (at least from the get-go), it's always better to first find product-market fit, and launch the token at a later stage. This way, the team has the opportunity to reward early adopters with airdrops, which by the way is a great way to market the project and grow the community organically;

3. Building a bigger-than-needed platform

While it is important to have a product roadmap, some clients are tempted to include way too many features on their initial product release. Web3 is a highly experimental industry which moves at a neck-breaking speed and by wanting to build platforms with all the bells and whistles founders could end up burning a lot of money for a platform that might not end up finding product-market fit.

The best approach is to build either a Proof-of-Concept or a Minimum Viable Product in an Agile fashion and release it to the market to see what the reception is. Most platforms will require several iterations and some of them will end up pivoting to different use cases down the track.

Let's define these concepts so everyone is on the same page:

: aims to demonstrate the feasibility or potential value of your idea or approach to validate it before committing significant resources to its development. 

Ultra low cost entry to validate product concept;

Usually best for early-stage and self-funded teams;

Tool to secure venture funding or demonstrate product value to stakeholders;

: a cost-effective way to validate market demand and gather feedback on your product or service, it's a great way to showcase your value proposition to target customers and improve chances of success.

Suitable for teams with seed funding, ready to launch their first live product;

Establish a foundation for future iterations;

Only then teams should focus on a fully fledged Production platform that is released at scale.

If you are part of a team building a web3 platform, put some consideration into these topics in order to maximize the chances of success of your product. Questions and feedback are always welcomed, feel free to reach out.

3 Common Mistakes When Building a web3 Platform

Labrys celebrated its 6th anniversary with optimism, reflecting on its resilience through market challenges, steady revenue growth, and a fun team-building event, including the Labrys Infinity Saga NFT treasure hunt.

Last Friday 29th of September, we celebrated our 6th anniversary and it was a fantastic opportunity for the team to reflect on Labrys’ beginnings and also get excited about the future.

During his address, Lachlan Feeney, our CEO, shared some insights on historical company performance, the remarkable correlation between inbound leads and crypto market cycles, and how Labrys is positioning itself for the next phase of growth.

While we cannot reveal our secret sauce, we are extremely proud of not only having persevered through two long bear markets, but being fortunate enough to grow our revenue during the last 2 years, all in an industry that suffered a significant number of collapsed businesses, bankruptcy filings, budget cuts and lay-offs. We like to think of this as a testament to the team’s hard work and our commitment to delivering awesome web3 products and keeping client satisfaction as a top priority.

After Lachlan’s presentation, we knocked off early and headed to New Farm Park to enjoy drinks, snacks and games on a sunny Brisbane afternoon.

, an NFT treasure hunt organised by our Product Lead, James, where teams of 3 raced to find and mint six Infinity Stone NFTs hidden around the park.

The Reality Stone was well-hidden in the rose gardens.

The first team to find and mint all six stones NFTs had to then burn them to obtain 

, a commemorative NFT that grants the winning team bragging rights for the next 12 months  (plus a bonus gift card prize).

Seb, Emilio and captain Dan - winners of the Labrys Infinity Saga

 (a no-code solution for deploying and minting NFTs). The mechanism for combining the stones to craft the Infinity Labrys makes use of Manifold’s Burn-Redeem app. Check it out 

All in all, a great day of celebrations and team-building that left everyone excited for the future of both the company and our industry. Six years building blockchain-enabled products feels like decades if we compare to other industries, which makes us extremely proud and motivated to keep thriving.

We’d like to thank our past and present clients as well as our hard-working and dedicated staff of developers, PMs, BAs, and across our Sales, Legal and HR departments.

Labrys Turns 6

Read the latest Web3 and blockchain industry insights from CEO Lachlan Feeney.

The team at Labrys recently ventured to Melbourne for the last large crypto conference of the year, AusCryptoCon. The weekend was full of valuable insights, networking and connections. We’re big believers that these events are really important for new and established Web3 businesses alike, to keep their finger on the pulse of Web3 trends and developments.

Lachlan Feeney (Labrys CEO) shared some of his key takeaways from the weekend. Read on to learn more about the things that impressed him the most, and what he’s expecting in 2024.

What impressed you the most about AusCryptoCon?

“This year we had a big booth, which was a first for us. I was super impressed last year as I’d never seen anything that big for a crypto conference in Australia. AusCryptoCon is the first event where we are actually competing or on par with international crypto events, and this year was bigger and better. We went to meet new clients, look for new business opportunities. This is honestly the best networking opportunity for our industry in the country.”

Industry health check: how is 2024 looking?

“The industry is super hot at the moment. Better than I expected it to be, to be frank, because the last 12-18 months have been hard. No one really wanted to talk about crypto or blockchain for a while, even the sentiment within the industry was generally negative. However in the last few months, there has been a shift and a lot of interest is returning to the industry. There’s a difference between price and sentiment; Bitcoin was up by mid-year but the sentiment in the industry lagged until the most recent months. I think 2024 is going to be really strong for the industry now. Currently, we’re fully booked out, which is great.”

“We are a smaller [Web3] market and population in Australia, with that being said, I do believe we punch above our weight in terms of the projects that are based here or were originally founded here. We have some of the biggest blockchain projects in the world right here in Australia. For example, Immutable, Rocket Pool, Synthetix, Illuvium, just to name a few. I’m looking forward to seeing more projects and innovation in 2024.

I also think SocialFi applications will rise in 2024. We’re seeing some great projects come through that are focussed on monetising networks and combining social media with DeFi. I am certain the future for blockchain is very positive and that many more use cases will move on chain and into Web3. Which industry or use case is next? That’s like asking someone when the internet was created, which industries would be the most impacted. It’s hard to make predictions, but I think sooner or later, every industry will be impacted.”

As we prepare to close the chapter on a momentous and challenging year in Web3, we set our sights now on the task ahead: mass adoption and further shaping the new world with cutting edge applications and solutions. 

Keen to learn more about what we can do for your project or big idea? Get in touch with our dedicated crypto-native team today.