Starkware is a ZK-rollup company that pioneered zero-knowledge-based rollups in 2018, launched StarkEx in 2020, and recently released StarkNet in November 2021. StarkEx is a ZK-rollup with less functionality than its StarkNet successor. StarkEx supports the ability for smart contracts to run any arbitrary logic for specific use cases, such as trading and NFTs, while StarkNet enables more general use cases.

Since its creation in 2018, Starkware has raised $110+ million across three equity rounds and received a $12 million grant from the Ethereum Foundation. Not only is the project backed by heaps of money, but prominent crypto and financial figures, including Pantera Capital, Sequoia, Founders Fund, DCVC, Paradigm, ConsenSys, Multicoin, Polychain, Vitalik Buterin, Naval Ravikant, and others, have also invested in Starkware.

StarkEx is the first iteration “scalability engine” from Starkware that now supports two versions: ZK-Rollup mode and Validium mode (discussed below). Validiums can be custom-tailored to offer superior performance for specific dApps and use cases, such as DeversiFi, ImmutableX, and Sorare.

StarkNet is Starkware’s next iteration of a ZK-rollup and the first ZK-rollup to feature general smart contracts on a fully composable network in a permissionless manner. Composability refers to the ability for applications to coordinate, build on top of one another, and interconnect—something for which StarkEx isn’t designed.

Optimistic vs Zk-rollups

Let's first discuss what are Optimistic rollups and ZK-rollups before diving deep into the working of StarkNet and StarkEx and how they’re different from other rollups. There are two rollup scaling solutions: Optimistic rollups (e.g., Optimism, Arbitrum) and ZK-rollups (e.g., StarkNet, zkSync).

Optimistic rollup

In the case of Optimistic rollups, no computation is actually done. ORs “optimistically” assume all state changes are valid and post the off-chain transactions to Ethereum’s layer 1 as calldata, updating the contract with the new state root.

To counter any potentially fraudulent transactions, a challenge/dispute period is put in place for ~one week after posting to L1. During this time, any third party can publish a fraud-proof to verify the validity of the transactions across L1 and L2. If the transactions are found to be invalid, the invalid transactions and all affected transactions will be reverted.

To discuss in a bit more detail, during this dispute period, if any network participant detects an invalid state root was sent to rollup, then any participant can send a fraud-proof to rollup contract. With the help of fraud-proof and batch of transactions, the rollup contract will compute the state root that the participant claims is invalid on the Ethereum chain.

Bonded tokens belonging to the sequencer who sent the invalid batch to the rollup contract will be slashed due to the malicious behavior, and the participant will be rewarded with some tokens for good behavior. If any participant raises no such claim during the dispute period, Ethereum believes the state root to be true and allows the withdrawal of assets according to the current state root of rollup.

This is how fraud proofs are used to point the invalid transactions and incorrect state root, allowing rollup smart contract to revert the incorrect blocks on rollup.

ZK-rollup

In the case of a ZK-rollup, the operator generates a cryptographic proof called validity proofs (SNARK or STARK) for the state root, which proves the rollup smart contract on Ethereum that the received state root was the result of execution of a valid series of transaction. This makes it impossible for the operator to send an invalid state root.

Zero-Knowledge Rollups TLDR

The process works as follows:

Highly-compressed batches of transactions are combined together with the current state root
The combination is sent to an off-chain Prover
Prover computes the transactions, generating a validity proof of the results
Prover sends this to an on-chain Verifier (Ethereum nodes)
Verifier confirms the validity proof
Smart contract on Ethereum’s L1 that maintains the state of the rollup is updated to the new state

ZK-rollups use two types of validity proofs: SNARK and STARK. SNARKs are used by ZK sync, Scroll, Polygon ZkEVM, etc., while StarkNet and StarkEx use STARKs.

ZK-rollups are significantly more computationally intensive than optimistic rollups, but they can scale much greater. This is because optimistic rollups require a witness for each transaction, whereas ZK-rollups bundle transactions into a fixed-size proof. Therefore, optimistic rollups scale linearly with the number of transactions, whereas ZK-rollups scale poly-logarithmically.

StarkEx

StarkEx is a framework used for creating permissioned, application-specific scaling dApps. StarkEx has been deployed on Ethereum since June 2020. Every application deployed on top of StarrkEx has its business logic.

Transactions executed on the applications built on top of StarkEx are sent to the StarkEx service, where a group of transactions is put together in a batch. This batch is then sent to SHARP, i.e., a shared proving service that generates STARK proofs that verify the validity of transactions executed on Cairo programs. The SHARP on StarkEx (as opposed to the version used in Starknet discussed later on) can only generate STARK proofs for a single type of transaction. This gives it limited scope and is why StarkEx is less flexible than Starknet, its next-generation general-purpose successor.

The original Starkware SHARP approach generated one aggregated ZKP1 for the various distinct propositions to be proved. In contrast, in the new SHARP method, the "mother" proposition is subdivided into groups where "children" proofs are generated for each group to create an accumulative ZKP2. Due to the logarithmic compression property, checking ZKP2 is considerably quicker than validating ZKP1 and requires fewer computational resources from the chain. Multiple subsidiary proofs can be computed in concurrently, hence accelerating the process of generating proofs.

A STARK proof generated from SHARP is then sent to the STARK verifier for verification purposes, and then an on-chain state update is sent to a StarkEx contract.

User data can be made available through various data availability modules:

ZK-rollup mode (vault balances are published on-chain as call data, which provides built-in trustlessness)
Validium mode (User balances are stored off-chain with well-known and trusted parties of a data availability committee. Data is accepted only if at least a quorum of the committee members sign on it.)
Volition mode (User gets a choice between ZK-rollup mode and validium mode for every transaction)

Two key differences that make StarkNet and StarkEx different from other rollups are the use of validity proofs called STARKs and the use of Cairo as the native smart contract language. To understand how they're different from other rollups, consider the differences between STARKs used by Starkware scaling solutions and SNARKs used by other ZK-rollups.

SNARKs and STARKs

Under the hood, StarkNet compresses thousands of transactions into a single validity proof called ‘STARKs’ (Scalable Transparent Argument of Knowledge), co-invented by Starkware President Eli Ben-Sasson, that's submitted to the Ethereum L1. Starkware’s STARK technology has two primary advantages over SNARKs (used by ZKR competitor ZkSync): 1) It doesn't require an initial trusted setup (like in zkSync v1), and 2) they’re ~10x faster to compute than SNARKs. Because the computational effort necessary to verify STARK proofs is significantly less than actually proving the computation, StarkNet can increase Ethereum scalability by orders of magnitude.

These are the most popular and widely used non-interactive zk proofs. They're both non-interactive zero-knowledge proofs, meaning there's little interaction between the prover and verifier. Both of these proofs are much smaller in size than an average Bitcoin transaction. They both scale the Ethereum network.

zkSNARK proof sizes are smaller. Therefore, it takes less time to verify and costs less gas. While zkSTARKS proof sizes are bigger and take more time to verify, it costs more gas than zk SNARK. zkSTARK TPS limit is higher than zkSNARK and is more scalable.

Cairo

StarkNet stands out from the numerous other zero-knowledge rollups (ZKR) projects in the space because, despite being a layer 2 project on Ethereum, it has shirked the EVM for its own development environment. This sets StarkWare apart from other ZKRs and indicates that it does not see ZKEVM as the ultimate goal. The company believes that in order to achieve high scalability, it is necessary to create languages and virtual machines that are specifically optimized for ZKRs rather than focusing on compatibility with the EVM. Additionally, they anticipate that the significance and influence of the EVM will decline in the future as more and more decentralized applications will be run on layer 2 solutions.

StarkNet and StarkEX don’t use Solidity, the preferred Ethereum smart contracting language, because it isn’t the best language to compile to STARKs. This is because Solidity can't be efficiently encoded to STARKs and is costly in comparison. Instead, StarkNet uses a new programming language developed by the team at Starkware called ‘Cairo.’ It’s a language for programming STARKs that achieves Turing-completeness with STARKs. A breakthrough of the Cairo language is it lets just one verifier use a single proof to confirm the integrity of many different program executions. This amortizes costs across separate dApps, e.g., a single proof that includes both dYdX trades and SoRare transactions.

Initially, Cairo was designed as an assembly language and was written as a low-level language. This makes it harder to code in Cairo. After various feedback from developers, the Starkware team made Cairo more developer-friendly and continuously improved it.

Cairo is a programming language that is specifically designed to support STARK programs while also providing general computation capabilities. Programs written in Cairo can be verified using the Cairo language itself, and the composability between Cairo-based or StarkNet-based decentralized applications is exceptional. The execution of a Cairo program also produces a proof that can then be sent to a prover. This generates a STARK proof of the validity of the instruction or calculation represented by the Cairo program.

The Cairo language has a similar structure to WebAssembly (Wasm), making it easily accessible for developers who are familiar with Wasm. Additionally, Cairo offers a user-friendly development environment that includes an Integrated Development Environment (IDE) where developers can access a native compiler that converts Cairo code into bytecodes, Cairo-exclusive Virtual Machines, and debuggers all within a single program. Furthermore, Cairo eliminates the need for building new verifier contracts for each decentralized application, as it uses a general-purpose verifier contract.

Therefore, Cairo ameliorates Ethereum’s expensive computation, transmission, and storage fees. To link the Cairo code to the smart contract, a Shared Prover (SHARP) is used. This involves a prover off-chain, a smart contract verifier on-chain, and a fact-logger contract on-chain. The prover proves the code is valid and sends this proof to the verifier, which then sends an attestation of the proof’s validity in the fact register. This fact functions as a seal of approval without trust, certifying the validity of the Cairo program. Now, dApp’s smart contract just needs to verify this fact exists and then it can rely on the computation that performed off-chain.

However, StarkWare acknowledges the importance of the EVM developer ecosystem and is working on providing a service called Warp, a transpiler that will seamlessly convert solidity smart contracts into Cairo to make Starkware EVM-compatible. WARP is the first automated Solidity compiler that allows programs written in Solidity to be deployed on StarkNet. It also provides a smoother transition for companies moving from ETH L1 to StarkNet L2. Finally, as of November 2022, Cairo 1.0 has been open-sourced, allowing anyone to review the code.

StarkNet

StarkNet uses Zero-Knowledge Proofs to achieve fast transaction times and hyper-scaling without compromising security. An alpha version of StarkNet was launched in November 2021 with limited capabilities to allow developers to begin building on top of the protocol. It fully launched in February of 2022 and is now fully functional for transactions and for building applications. StarkNet is designed so that it benefits from economies of scale, i.e., the greater the number of transactions in a batch, the less gas each participant in the batch must pay.

As we know, ZK-rollups enable provable computation, i.e., it allows programs to prove they’ve been executed by providing SNARK or STARK proofs without having to re-run/re-execute the transactions. This leads to tremendous scalability improvements. StarkNet is designed to benefit from economies of scale, i.e., the greater the number of transactions in a batch, the less gas each participant in the batch pays.

StarkNet transactions sent by users are batched and delivered to the STARK prover. This STARK prover has the accurate ledger state prior to and following the processing of these new transactions. The prover generates a STARK proof attesting to the veracity of the new state of the ledger. The new state and STARK proof are relayed to the STARK verifier on Ethereum mainnet where the proof is verified autonomously by a smart contract.

The Starknet L2 node (sequencer) will execute every transaction and periodically update the state to the Ethereum mainnet. StarkNet transaction finality is tied to L1, meaning the L2 node must simultaneously validate StarkNet and Ethereum. StarkNet introduces a solution involving checkpoints to the Ethereum mainnet, enabling it to quickly achieve finality on the rollup side. Therefore, all L2 nodes incorporate an L1 full node.

STARKs improves scalability and privacy since developers can move computations and storage off-chain. Off-chain services can generate STARK proofs, attesting to the integrity of off-chain computations. These proofs are then returned to the chain for any interested party to validate the computation. Moving the bulk of the off-chain computations using STARK allows the blockchain infrastructure to scale exponentially while maintaining the integrity of the computations.

Additionally, since the state transitions are "STARK-approved" by the sequencer, it's mathematically/cryptographically impossible for fraudulent transactions to be accepted on mainnet Ethereum. This removes the need for any "challenge" period that exists in ORs. All data needed to reconstruct the full StarkNet state is published on-chain.

However, Starkware is in control of the sequencer, and all of the transactions are verified by Starkware cloud servers. However, Starkware aims to create a decentralized sequencer set in the future. It's not a fully permissionless system. For example, to deploy a smart contract on StarkNet, you must fill out a form and send it to the Starkware team.

New StarkNet Client

In January 2023, StarkWare introduced a new full node client, known as Papyrus, for StarkNet. Written in the Rust programming language, the implementation of this new client will enable a more diverse range of integrations while also improving the protocol's security and decentralization. The team has stated that the new node, Papyrus, will augment the project's transaction throughput capabilities and will join Pathfinder as the second Rust-coded full-node client.

Additionally, StarkNet already has another full-node client, Juno, that is being coded in the Golang programming language. Furthermore, the Papyrus will reportedly enhance the capabilities of the StarkNet Sequencer, which is responsible for ordering and executing transactions on the network. It will provide an efficient storage layer that will help to improve the Sequencer's throughput. This move is part of the wider efforts to open-source the entire technology stack of the project.

ZK-rollup or “Validity” rollup?

The Starkware team doesn’t use the term “ZK-rollup” but rather refers to their solution as a validity rollup. Below is the definitional difference between the different terms.

Validity Proof: a cryptographic proof confirming that the computation was done correctly
ZK Proof: a validity proof that also conceals information about the computation
Succinct Proof: a cryptographic proof that is fast to verify, thereby helping with scalability

The team explained their position in their Discord the following way:

“Let's start with proofs of computational integrity; one side proves to another that a certain computation was done correctly (validity proof).

An optional additional feature is zero-knowledge, means there's a mathematical reason why you can't learn any information from the proof except for the fact that the computation was done correctly (zero-knowledge proof). Most of the STARKs we’re building (the one in StarkNet included) don't have this feature (but it's going to be extremely hard if not impossible to extract information from the proof, nevertheless). We've decided to focus on scalability for now rather than privacy.

Another important thing is that a ZK proof is not enough for privacy. It doesn't help if you have a ZK proof, but you tell your secret inputs to the sequencer as part of the protocol... So the protocol must be adapted to make sure no information is leaked. One good example of such a protocol (which uses a ZK proof) is Zcash.”

Role of StarkNet Foundation and StarkNet Token

On July 13th, 2022, Starkware announced in a Medium post that StarkNet would have its native token and a StarkNet foundation would be set up. The StarkNet Foundation will be a non-profit organization, and StarkNet tokens will be allocated to it to help achieve its goals. Its primary goal will be to maintain StarkNet as a public good. The Foundation will also maintain ongoing protocol development, testing, documentation, and software publication.

The StarkNet Foundation and its native token will play a key role in making the StarkNet network decentralized. The StarkNet Foundation will follow these four principles to maintain StarkNet’s decentralization: Livness, Censorship resistance, Transparency, and Creativity.

On November 10th, 2022, Starkware announced StarkNet Foundation’s official launch. Foundation priorities will be making StarkNet more decentralized by developing a governance mechanism and making the process of sequencing and proving decentralized. Additionally, this will include overseeing the continued development of the StarkNet network, fostering a community of users and developers, educating people about StarkNet and its technology, and helping developers gain the skill to maintain and build dApps on StarkNet as well as StarkNet infrastructure.

A seven-member board will govern the StarkNet Foundation, whose members come from diverse backgrounds and bring a multidisciplinary range of skills.

The board members are Andrew McLaughlin, Prof. Eli Ben-Sasson, Eric Wall, Heather Meeker, Prof Shubhangi Saraf, Tomasz Stanczak, and Uri Kolodny.

StarkNet Token

StarkNet token will be used for three purposes (payment, staking, governance):

1) Network payment - Paying network transaction fees. For a good user experience, users will also have the choice to pay in ETH.

2) Staking - Various services will require staking StarkNet tokens. As for reaching a temporary consensus on the validity of layer 2 transactions before L1 finality’s reached, data availability service, a permissionless Proof-of-Stake leader election mechanism, will be implemented for sequencing and proving STARK-compressed transactions.

3) Governance - Governance decisions regarding starknet operations and updates will be taken by token holders. A minimum voting threshold will be required to pass a governance proposal. Token holders will be able to vote directly or via delegation.

The StarkNet token’s design was made considering the needs of:

1. Users of the network.

2. Operators providing computing resources for various operations, such as sequencing transactions, STARK proof generation, and storage for data availability services.

3. Developers building and maintaining software for the infrastructure of the network and dApps built on top of it.

Starkware minted 10 billion tokens off-chain but, as of November 2022, has deployed the token contract on Ethereum. New tokens will be minted, so the circulating supply of tokens will increase over time. New minting of tokens and a portion of transaction fees paid by users will go to smart contract developers and core developers.

However, the StarkNet protocol may automatically distribute a portion of fees and new minting of tokens to smart contract developers according to the value their smart contracts provide to users. The exact mechanism for distribution has yet to be confirmed.

Initial allocation of StarkNet token

32% - Core contributors (Starkware employees and consultants and StarkNet software developer partners)

17% - StarkNet investors, such as Sequoia Capital, Tiger Global Management, Pantera Capital, IOSG ventures, etc.

50.1% of the token allocation for the StarkNet Foundation will be distributed as follows:

Community Provisions (9%)

To people who performed work for StarkNet and developed its underlying technology and infrastructure and to past StarkEx users. Allocations will be done based on verifiable usage of StarkEx’s technology before June 1, 2022.

To prevent gamification, snapshots from before the announcement date of the token rewards will be referred to distribute tokens, and additional network usage filtering will be done so that airdrop Sybil hunters don’t receive rewards.

Community Rebates (9%)

Rebates in StarkNet Tokens will be done to partially cover the costs of onboarding users to StarkNet from Ethereum. To prevent gamification, community rebates will apply to transactions after the rebate mechanism is announced by the StarkNet Foundation.

12% — Grants for research and work done to develop and maintain the StarkNet protocol.

10% — Strategic reserve will be distributed as ecosystem rewards for the activities that align with the foundation’s mission.

2% — Donations to highly regarded institutions and organizations, such as universities, NGOs, etc., will be decided by StarkNet token holders and the foundation through governance.

8.1% — Unallocated – Foundation’s unallocated treasury tokens will be distributed through governance for the purpose of supporting the StarkNet community.

Tokens allocated to core contributors and investors will be subjected to a four-year lock-up period with the linear release of tokens after a one-year cliff. The vesting schedule for tokens set aside for the StarkNet Foundation has yet to be announced.

Helpful Starknet Links and Wallets

Presently, users can choose between two StarkNet wallet options, with a third option soon to be available:

Argent X: The pioneer StarkNet wallet
Braavos: A self-custodial solution
MetaMask: The popular wallet set to support StarkNet in the near future

Argent X was the inaugural DeFi wallet for StarkNet, boasting over 3.5 million transactions. The wallet offers vaults, allowing users to earn yields on their crypto assets and serves as a custody solution. Argent X is backed by prominent investors, including Paradigm and Index Ventures.

As a native StarkNet DeFi wallet, Braavos features a multimedia NFT reader and self-custodial capabilities. Users can manage their crypto tokens and NFTs in one convenient location.

MetaMask recently announced a strategic partnership with StarkWare, which will make it the first zk-L2 wallet to be supported by the widely used web wallet. This collaboration aims to provide enhanced scalability, trading experiences, perpetual swaps, and derivatives to all StarkNet and Ethereum users through a decentralized node network.

If you liked Layer 2, then you’ll love Layer 3

Layer 2s increase the scalability of Ethereum while getting the benefits of decentralization and security guarantees from Ethereum. However, some dApps have specific needs or can perform better if dApp developers have more control over the execution layer.

Enter Layer 3s, where dApp developers get more control over the execution layer while still getting the benefits of decentralization and security guarantees from Ethereum. Layer 3 can function using validity proofs as long as layer 2 has a verifier smart contract, which can verify the validity proofs sent by layer 3. This setup becomes an elegant recursive structure where the compression benefits of layer 2 proofs are multiplied by the compression benefits of layer 3 proofs.

Recursive zk proofs are constructed by combining many proofs into a single proof. The single proof is only true if all underlying proofs are correct, and it is significantly simpler and less expensive to check. This is particularly advantageous when proofs are checked on-chain. Thousands of proofs can be condensed into a single proof, significantly reducing costs associated with the verification process. This is due to the fact that a recursive zk proof demonstrates the existence of an earlier valid proof.

Layer 3 fees get reduced by multiples compared to layer 2 while still getting the same benefits from layer 1, which are received by layer 2. StarkEx, which is currently used as a layer 2 solution, will be moved to Layer 3, and several instances of StarkNet will also be available as Layer 3.

Layer 3 Architecture

Benefits of layer 3:

1. Higher scalability than layer 2 from the recursive structure

2. More control over the underlying technology stack

3. Privacy-based applications over a public layer 2

4. Cheaper interoperability between layer 3 to layer 3 and layer 3 to layer 2

5. Layer 3 can be used as a testnet. After a successful run of a dApp over layer 3, it can be made available to the public layer 2 networks

StarkNet Roadmap

In 2023, the primary objective of StarkNet is to enhance the network performance to accommodate the anticipated growth in user and developer numbers. Performance, in this context, is characterized by not only throughput and latency but also by transaction cost. To that end, the imminent release of Starknet v0.12.0 promises substantial enhancements in these areas. These improvements stem from the work to convert the Starknet stack to Rust, resulting in the Rust-based Sequencer developed by StarkWare and the Rust-Cairo VM (cairo-rs) developed by LambdaClass, both of which are open-source projects. The transition is projected to considerably decrease block execution time, thereby increasing throughput. In the absence of congestion, transaction latency is also expected to improve, as the primary cause of latency is block execution time.

In Starknet v0.13.0, transaction costs will undergo a significant reduction. This will be achieved by targeting the primary component of transaction cost: L1 (Ethereum) data cost, which currently accounts for 95% of transaction costs. The introduction of Volition will enable developers to create Starknet applications with hybrid Data Availability (DA) modes, utilizing both on-chain and off-chain data. A forthcoming post will provide comprehensive details on Volition's design and developer interfaces.

As the releases of Starknet v0.14.0 and v0.15.0 approach, the commitment to providing users with a seamless and predictable experience on the network, regardless of congestion levels, remains steadfast. To accomplish this, two key areas of development are being prioritized: fee market and block intervals.

In the context of the fee market, the planned performance improvements will be evident to developers and users, provided that the network remains uncongested. However, when congestion occurs, it will result in increased waiting times for all users. To address this issue, a fee market will be introduced in Starknet v0.14.0, enabling efficient allocation of Starknet's limited resources based on users' willingness to pay for a transaction rather than its position in the queue.

In Starknet v0.15.0, the network will transition to constant and shorter block intervals. At present, each block is proven by its own proof, and block intervals are variable, with the conserved quantity being the block cost. To resolve this, the 1:1 relationship between a Starknet block and its proof will be decoupled. Starting with v0.15.0, a proof will attest to the integrity of one or more Starknet blocks, fixing the block interval and enhancing the Starknet user experience.

The tradeoffs considered in determining this roadmap prioritized performance enhancements, mainly achieved by increasing the Sequencer's throughput beginning with v0.12.0. In v0.13.0, the decision was made to focus on lowering transaction costs rather than improving user experience due to the expectation that v0.12.0 will deliver significantly better latency. The main lever for reducing transaction costs will be the implementation of Volition and, as further details emerge, EIP-4844.

StarkNet Bridge

In general, there are two types of bridges: trusted and trust-minimized. Trusted bridges depend on a counterparty consensus, usually an external validator set, while a single complete node can secure trust-minimized bridges.

Chains require two things to construct trust-minimized bridges: the same data availability (DA) guarantees and a mechanism to read each other's fraud or validity proofs. Because L1s don't meet the previous requirement of shared DA, they can't create trust-minimized bridges with each other. They rely on each other's agreement to communicate, significantly reducing security.

In contrast, rollups connect with Ethereum in a manner that minimizes the need for trust. They are “trust-minimized” because the smart contract on the L1 acts as a light client receiving block headers and validating by fraud/validity proofs. Ethereum has access to a rollup's data and conducts its on-chain fraud and validity proofs. This access and proof process are why rollups can have as little as one node but still maintain the same trust assumptions as the Ethereum base layer.

Rollups don't require validators; instead, a set of sequencers to produce blocks. The base layer provides the secure validator set, circumventing the security bootstrapping problem.

Additionally, rollups that share a settlement layer can build trust-minimized bridges between them because their state transitions can be easily verified through the settlement layer via full nodes.

StarkNet is currently the only general-purpose, composable ZKR on Ethereum, but comes with several limitations as the project is still in its infancy. There is no StarkNet node operating on the Ethereum bridge of StarkNet. Instead, it runs a verifier. To ensure that people are receiving the truth, it examines a mathematical demonstration. The bridge of StarkNet is a MESSAGE bridge. It allows you pass data.

StarkGate is the StarkWare-built Ethereum-StarkNet token bridge. It's comprised of L1 and L2 token bridge contracts that are communicating via StarkNet's messaging mechanism.

The first version of StarkNet Bridge, StarkGate Alpha, is live on Mainnet as of May 2022. The only bridgeable assets are ETH, DAI, WBTC, USDC, and USDT. There's a TVL limit for each token type on StarkNet. There's a limit to the maximum amount sent from layer 1 to layer 2. The team continues to raise the limit from time to time.

To bridge from Ethereum to StarkNet via Starkgate:

Users can send ETH, DAI, USDC, WBTC, and USDT to recipient addresses on StarkNet
The smart contract emits a deposit event on L1, a recipient address on L2, and the amount
The StarkNet sequencer ensures the deposit's valid, processes the transaction and constructs the block
StarkNet’s provers then verify the block’s validity and submit a state update to L1
Once proven valid, transferred funds are now part of the finalized state of StarkNet

Users can use Layerswap to send ETH from centralized exchanges to StarkNet by paying low fees and can use Orbiter to bridge ETH and DAI from StarkNet to other layer 2s, Ethereum, Polygon, and BNB.

Loading...