Skip to main content

Moving to Casper from another Blockchain

This page covers various considerations for moving to Casper from another blockchain by comparing Casper to Ethereum, Near, Aptos, and Solana in these aspects:

  1. Smart Contract Platform Overview
  2. Variable Storage and State Management
  3. Contract Functions
  4. Passing Arguments

Since other blockchain projects use different technologies, it is essential to consider how those technologies serve your use case.

When choosing a blockchain, it is also essential to compare consensus mechanisms, tokenomics, cross-contract capabilities, contract upgradability, and software development kits (SDKs) as described here.

Smart Contract Platform

Casper smart contracts are written in Rust.

Variables defined within the smart contract can be stored as either Named Keys or Dictionaries as described in Reading and Writing Data to the Blockchain.

The call function serves as the main entry point of the smart contract. It automatically executes when the smart contract is installed, setting the initial state of the contract and defining all other entry points.

It's worth noting that Casper only supports public entry points for contracts. Additionally, contracts can be defined as upgradable or immutable as described here.

Variable Storage and State Management

Variables can be stored as Named Keys or Dictionaries as described in Reading and Writing Data to the Blockchain.

Additionally, local variables are available within the entry points and can be used to perform necessary actions or computations within the scope of each entry point.

Contract Functions

For Casper smart contracts, public functions are called entry points. To declare them, the following format is used:

pub extern "C" fn counter_inc() {

// Entry point body

It's important to note that entry points do not have input arguments in their definition, but the arguments can be accessed using the RuntimeArgs passed to the contract. Entry points are instantiated within the call entry point.

If a return value is needed, it should be declared using the syntax described in the Interacting with Runtime Return Values tutorial.


Each call to an entry point is treated as a Deploy to the network, and therefore, each call incurs a cost paid in motes (the network's native accounting unit).

Passing Arguments

Named arguments are passed as strings with type specifiers. To provide session arguments to the entry point during a Deploy, you can utilize the following approach:

casper-client put-deploy \
--node-address \
--chain-name casper-test \
--secret-key [KEY_PATH]/secret_key.pem \
--payment-amount 2500000000 \
--session-hash hash-93d923e336b20a4c4ca14d592b60e5bd3fe330775618290104f9beb326db7ae2 \
--session-entry-point "delegate" \
--session-arg "validator:public_key='0145fb72c75e1b459839555d70356a5e6172e706efa204d86c86050e2f7878960f'" \
--session-arg "amount:u512='500000000000'" \
--session-arg "delegator:public_key='0154d828baafa6858b92919c4d78f26747430dcbecb9aa03e8b44077dc6266cabf'"

To understand the context of this example, refer to: Delegating with the Casper Client.

In the contract, you can access the session arguments as follows:

let uref: URef = runtime::get_key(Key_Name)

Use the get_key function to retrieve the desired session argument by specifying the key's name.

If you are uncertain how to use the get_key function to obtain a specific session argument, check how to write a basic smart contract on Casper.

Additional Considerations

When choosing a blockchain, you may also look into the network's consensus mechanism, the tokenomics or economic model, cross-contract communication, smart contract upgrades, and the available software development kits (SDKs).

  1. Consensus mechanism refers to the algorithm the blockchain network uses to achieve agreement on the validity and ordering of transactions. Different blockchains employ various consensus mechanisms such as Proof-of-Work (PoW), Proof-of-Stake (PoS), or Delegated Proof-of-Stake (DPoS). The choice of consensus mechanism impacts factors like security, scalability, and energy efficiency.

  2. Tokenomics relates to the economic model of the blockchain network and its native tokens, involving token distribution, inflation, utility, and governance. Understanding the tokenomics of the network is crucial for evaluating the ecosystem's long-term viability and potential value.

  3. Cross-contract capabilities refer to the ability of smart contracts to interact and communicate within the blockchain network. This feature is essential for building complex decentralized applications (dApps) and implementing inter-contract functionality.

  4. Contract upgradability determines whether the smart contracts installed on the network can be modified or updated after installation. It is essential to assess the flexibility of the chosen blockchain in terms of contract maintenance, bug fixes, and incorporating new features or improvements without disrupting the existing ecosystem.

  5. SDK availability also plays a significant role in the development process. SDKs provide tools, libraries, and documentation to simplify the creation of applications and smart contracts on the blockchain. Evaluating the maturity, community support, and compatibility of the available SDKs is crucial for developers.

Considering these aspects helps when selecting a blockchain that aligns with a project or application's specific requirements and goals.

The Casper ecosystem aims to fulfill all of these aspects, including supporting enterprise-grade projects.