* For the Umami web wallet, click **Settings > Save backup** and follow the steps to save an encrypted backup file to your computer.
This file is encrypted with a password, so you must also keep the password in a safe place.
* For the Kukai browser wallet, click **Settings > Reveal seed words**.
For other wallets, see the documentation for the wallet or its settings.
## Transferring tokens
Most wallets allow you to transfer tokens directly in the wallet application.
In most cases, all you need to do is click **Send**, select the token and amount to send, and enter the address of the target account.
For example, this is what a simple transfer of 10 tez looks like in the Temple wallet mobile application:
## Connecting a wallet to an application
You can work within the wallet itself to see your tokens and account history.
You can also use it to make transactions, including sending tokens to other accounts.
Another primary use of a wallet is to connect to and use decentralized applications (dApps).
These applications typically provide a web application user interface and use Tezos for background tasks such as user authentication, data storage, and payment processing.
You must connect your wallet to the application, like logging in to a web site, before it can access your account information.
Then, when the application wants to send a transaction to Tezos on your behalf, it sends the transaction to your wallet application for you to approve.
If you approve the transaction, the wallet signs it with your private key and submits it to Tezos.
For an example of a dApp and how you interact with it in your wallet, see [Staking](/using/staking).
After you approve the transaction, you can see it in your wallet's history.
:::warning
Examine transactions thoroughly before approving them.
Malicious dApps may send misleading transactions, and transactions cannot be reversed after you sign them.
:::
# Using Tezos applications (dApps)
Decentralized applications (dApps) are programs that, at their core, run independently, without any person or group in charge of them.
These applications are:
* **Transparent**, because the core of the application (what developers call the *backend application*) runs on Tezos, and data on Tezos is public, although this data can be very complicated
* **Persistent**, because the backend applications cannot be shut down or blocked
* **Pseudonymous**, because Tezos accounts are not linked to any public information about users and therefore users can use these applications anonymously
* **Secure**, because users are authenticated through the private keys in their wallet applications instead of passwords
## Common types of dApps
dApps can do almost anything that ordinary web applications can do and more.
In particular, Tezos dApps can:
* Use your Tezos account as your authentication to the application and save data that is tied to that account
* Accept tez tokens as payment like you might use a credit card online
* Perform tasks on Tezos on your behalf, like writing data and transferring tokens
Here are some common types of dApps:
* **E-commerce sites** that accept cryptocurrency tokens as payment
* **Decentralized Finance (DeFI)** applications that provide loans and currencies for specific purposes
* **Distributed exchanges (DEXs)** that trade tokens for other tokens
* **Games** that use Tezos as the backend for game logic and tokens to represent game items
* **Art marketplaces** that allow creators to advertise and sell their work as digital tokens
For an example of a Tezos dApp, see [Staking](/using/staking).
## Using dApps safely
Like any other web application, you must interact with dApps with care.
Here are some safety tips:
* Verify that the application is authentic before using it.
For example, make sure that the URL is correct; instead of clicking a link in an email or on social media, type the address of the application into a web browser manually to ensure that you are not on an impostor site.
Beware of social engineering tactics that may try to get you to use fraudulent dApps by making promises that are too good to be true or tricking you into giving them your private key or wallet recovery information.
You can also check user reviews of applications or verify on social media that other users are using the dApp.
* Examine all actions that a dApp takes on your behalf before signing them in your wallet.
For example, a malicious e-commerce site could offer to sell you something for 10 tez but send a transaction to your wallet for 100 tez.
If you don't review the transaction in your wallet application carefully and approve it without seeing the mistake, it's unlikely that you can get your tez back.
You can also view the transaction fees in your wallet before approving the transaction.
* Use a secure wallet and manage your wallet information carefully.
Consider using a hardware wallet for the best security.
Whether you use a hardware wallet or software wallet, follow its instructions carefully to ensure that your private key and recovery information are not exposed when you use the wallet.
* Verify transactions after they complete.
Many wallets show the hash of transactions that dApps create on your behalf.
You can copy this hash and look it up on a block explorer to see its details.
* Use the correct account with a dApp.
dApps may not provide a way to change accounts like traditional web applications may allow you to change the email address that you use to log in to the site.
Therefore, you must be sure to connect to the dApp with the correct account.
# Staking
Staking is the process of temporarily locking tez on the Tezos platform.
Staking contributes to the economic security of the network.
As an incentive for staking, stakers receive rewards proportional to how much they stake.
Staked tez stays in the staker's account, but the staker cannot transfer (or spend) that tez.
Stakers can unstake the tez at any time, which makes the tez spendable again after a delay; see [Staking periods and delays](#staking-periods-and-delays).
Two main groups stake on Tezos:
* Bakers, the creators and validators of new blocks in Tezos, must have a baking power of at least 6,000 tez to receive the right to "bake" blocks, validate other bakers' blocks, and receive rewards for baking and validating.
A baker's baking power includes the tez that the baker stakes and the tez that users stake with them.
The staked tez ensures that they bake correctly, because part of their baking power is taken ("slashed") if they misbehave.
In this way, staking provides an economic incentive to keep Tezos running properly.
For more information about staking for baking purposes, see [Bakers](/architecture/bakers).
* Any Tezos user can stake tez with a baker and earn rewards.
In exchange for staking tez with a baker, users automatically receive a portion of the baker's rewards in proportion to how much they stake.
Users can stake any amount of tez, but there is a limit to how much staked tez a given baker can accept, and bakers must opt in to allow users to stake with them.
:::note How much tez do I receive in return for staking tez?
The amount of tez that you receive for staking tez depends on how much you stake, but also on how well your baker performs.
If your baker misses opportunities to bake blocks, they don't get rewards for those blocks, which decreases rewards for you, too.
You can look up an estimated rate of return on [block explorers](/developing/information/block-explorers).
:::
## Staking with a baker
The process of staking with a baker (without being a baker yourself) has these main steps:
1. You select a baker as a delegate for your account.
As described in [Delegating to a baker](/architecture/bakers#delegating-to-a-baker), delegating tez to a baker puts that tez toward the baker's voting and baking power.
Delegating incurs no risk to you; you retain full control of the tez, you can spend it at any time, and you are not punished if the baker misbehaves.
2. You choose an amount of tez and stake that tez with the baker.
Staking the tez locks them temporarily, but the tez stay in your account.
You can stake any amount of your tez, up to the limit of what the baker can accept.
However, you should always retain at least a small amount of unstaked tez to pay for transaction fees.
If the baker misbehaves, their punishment also affects tez staked with them, so it's important to choose a responsible baker.
3. You can leave your tez staked for as long as you want.
During this time the rewards are added to your account automatically.
The process of unstaking has these main steps:
1. When you want to stop staking, you decrease the amount that you have staked or unstake all of your staked tez.
2. After a delay of up to 4 days (3 blockchain cycles plus the time remaining in the current cycle), the tez are unfrozen, but they are not actually available in your account until the request is finalized.
3. An automated system watches for unstake requests and automatically finalizes them, so in most cases you don't need to do anything at the end of the delay; the tez are automatically made available in your account.
If this system does not finalize your unstake request, you can finalize the request yourself with the Octez client `finalize unstake for` command.
:::note Finn, the unstake finalization system
The system that automatically finalizes unstake requests is known as Finn.
At the beginning of each cycle, it checks for requests that are ready to be finalized and submits a batched operation for them.
On Mainnet, it uses the account 
4. Click **Start Earning**.
5. In the popup window, click the option to delegate or stake; in most cases, click **Stake**.
6. Click **Select Baker**.
The window shows bakers and information about their fees and free space for staking:
For more information about bakers, you can look them up in a block explorer by their addresses.
For example, the block explorer tzkt.io has information on bakers at https://tzkt.io/bakers.
Evaluate bakers by comparing information about them, including:
* The fees they charge (commission) on rewards
* Their capacity for additional staked funds (free space)
* How reliable they are as a baker (how often they bake blocks when they have the opportunity)
* Whether they have been penalized (slashed) in the past
For example, the bakers in this picture all have free space for staking:
7. Choose a baker and click **Select** next to them.
The application prompts you to delegate your account to that baker, as in this screenshot:
8. Click **Continue** and approve the operation in your wallet to delegate to that baker.
It may take a few seconds for the operation to be final.
When the transaction is final, the Stake Amount window opens.
9. In the Stake Amount window, specify the amount to stake.
:::note
Don't stake all of the tez in the account; you need some liquid tez to pay transaction fees.
For this transaction, the application deducts the transaction fee from the amount that you stake.
However, you will need liquid, unstaked tez later to unstake the tez.
Leaving 1 tez in your liquid balance is enough.
:::
10. Click **Stake**, confirm the terms of use for the staking application, click **Stake** again, and confirm the transaction in your wallet.
This operation may also take a few seconds.
When the staking operation is complete, a confirmation page shows how much you have staked and provides a link to tzkt.io that you can use to see information about your account.
The web application also shows the current status of your account, as in this screenshot:
## How to unstake
You can unstake any amount of staked tez at any time, but you must wait for the 4-day delay for the unstaked funds to be made available in your account.
:::note Why do I have to wait to finalize the unstake request?
Staked funds are part of the security deposit of the chosen baker, so they must remain frozen while they remain at stake.
Tezos calculates how much is staked with a baker at the end of blockchain cycles, and it requires tez staked at the end of the current cycle to be frozen for the next three cycles.
For this reason, you must wait three cycles to finalize an unstake request, which can take up to 4 days (including three cycles plus the time remaining in the current cycle).
For more information, see [Staking periods and delays](#staking-periods-and-delays).
:::
1. Go to https://stake.tezos.com in a web browser and connect your wallet.
2. Click **Unstake**, read the notice about the delay, and click **I Understand**.
3. Select the amount to unstake, up to the total amount that is currently staked, as in this screenshot:
4. Click **Unstake** and confirm the transaction in your wallet.
When the unstaking operation is complete, a confirmation page shows how much you have unstaked and provides a link to tzkt.io that you can use to see information about your account.
Then, the application shows the pending unstake request and the cycle in which the request can be finalized, as in this screenshot:
5. Wait for the unstaking delay and for your tez to become available in your account.
You can check your unstaked balance with many tools including block explorers.
Now the application shows your liquid balance and any tez that remain staked.
## Viewing your rewards
The Tezos protocol distributes staking rewards automatically, without requiring any manual action.
To see them, look up your account on a block explorer such as [TzKT](https://tzkt.io).
If your baker pays delegation rewards (this concerns the amount of liquid, non-staked tez in your account), the baker distributes those rewards to you using transactions.
## Staking periods and delays
The following diagram shows the reason for the unstaking delay.
The diagram shows cycles as a timeline and assumes that the user has already staked tez with a baker at the start of the timeline.
The system calculates rights for bakers two cycles ahead, so at the end of cycle 1, the system calculates rights for a baker in cycle 4 based on the amount staked with that baker as of the end of cycle 1.
The example user in the diagram submits an unstake request in the middle of cycle 2.
When cycle 2 ends, the system calculates rights for bakers in cycle 5, so the baker will have reduced staking rights in cycle 5 depending on how much the user requested to unstake.
During this time, the funds in the unstake request are no longer considered staked to tbe baker, but they are still delegated to the baker, so they still affect the baker's baking rights.
The diagram also shows why users must wait to unfreeze their staked tez.
Because the rights in cycles 3 and 4 were computed before the unstake request, the funds being unstaked must still guarantee the honest behavior of the baker during that period.
The diagram shows a baker misbehaving in cycle 4.
Other bakers have the remainder of cycle 4 and all of cycle 5 to denounce the misbehaving baker, which results in that baker being slashed.
Therefore, funds staked with that baker stay frozen until the end of cycle 5 in case they need to be penalized.
Then, Finn (the unstake bot) or any user can finalize the unstake request.
## More information
For technical information about delegating, staking, and rewards, see these pages in the Octez documentation:
* https://octez.tezos.com/docs/active/staking.html
* https://octez.tezos.com/docs/active/adaptive_issuance.html
# Architecture
The Tezos blockchain is composed of many Tezos nodes running around the world, complemented by other programs such as bakers and accusers.
These processes collaborate with the overall goal of maintaining the blockchain data in a decentralized manner.
The Tezos nodes are the most important piece in this architecture because they maintain the system and the blockchain data.
Users interact with nodes through many different clients, including command-line clients, wallets, and web applications.
For more information about nodes, see [Nodes](/architecture/nodes).
This diagram shows a high-level view of the Tezos system:
## Tezos layer 1
When people talk about Tezos, they usually mean the primary Tezos network, which is referred to as Mainnet, and the fundamental processing layer, known as *layer 1*.
Tezos also has other networks used for testing, referred to as testnets.
Anyone can create new test networks if needed.
For example, before new versions of the Tezos protocol are enabled, users create networks that use that protocol so they can test it.
Other systems run on top of Tezos layer 1; these systems are referred to as *layer 2*.
These systems, based on [Smart Rollups](/architecture/smart-rollups), complemented by the [Data Availability Layer](/architecture/data-availability-layer), allow Tezos applications to scale, running transactions and using data at a much higher rate than layer 1.
For more information about layer 2, see [Layer 2](#layer-2).
### The blockchain data
Although people often use the word "blockchain" to mean the entire system, strictly speaking, a Tezos blockchain is a series of blocks of data, each connected to the previous block in the chain, beginning with the genesis block.
The blockchain data is maintained by a network of Tezos nodes.
Nodes reach consensus on the next block before adding it to the chain.
As shown in the diagram, the data inside a Tezos block includes the hash of the previous block in the chain and many operations, such as transactions that transfer tez or call smart contracts.
Blocks also include operations that are necessary for the management of the chain, including nodes' attestations that blocks are valid, called *consensus operations*, and votes on changes to the protocol, called *voting operations*.
For more information on the operations that can be included in blocks, see [Blocks and operations](https://octez.tezos.com/docs/active/blocks_ops.html) in the Octez documentation.
### Tezos clients and servers
In addition to the functions of the [protocol and shell](/architecture/nodes#protocol-and-shell), a Tezos node also acts as a server to respond to queries and requests from clients.
A client can query the chain’s state and can inject blocks and operations into a node.
Nodes share operations with each other, so the node that includes an operation in a block may not be the node that the client originally sent the operation to.
Tezos uses this client-server architecture for these main reasons:
* It improves security by separating the node, which is exposed to the internet, from the baker, which has access to the client keys.
The node and the baker can be on different computers, which allows the node to manage communication and shields bakers from network attacks.
* It allows bakers to have different implementations.
For example, different bakers may implement different transaction selection strategies.
* It allows clients and other tools to interact with the node and inspect its state.
The node accepts calls from clients through its RPC interface.
It has control over which clients to accept calls from, which calls to accept, or whether to accept RPC calls at all.
Anyone can run a node and select which clients to run and which requests to accept from clients.
Some typical use cases for nodes are:
* A node running by itself, which maintains a copy of the blockchain data and enhances the distribution of the network without actively baking blocks.
Optionally, this node can open its RPC interface to serve different kinds of requests.
* A node along with a baker, an accuser, and a signer can be used to bake new blocks, activity which ensures that the blockchain progresses and yields rewards in tokens.
Here is a summary of the main Tezos clients:
* **Bakers**: The baker is an Octez program that is responsible for creating and proposing new blocks based on the operations proposed by different clients.
For more information, see [Bakers](/architecture/bakers).
* **Accusers**: The accuser is an Octez program that monitors new blocks and looks for problems, such as when bakers try to add more than one block at a time.
When it finds a problem, it submits a denunciation to other nodes to refuse the new blocks and punish the offending node.
For more information, see [Accusers](/architecture/accusers).
* **The Octez client**: The Octez client is a command-line tool that developers can use for many Tezos-related tasks, including:
* Deploying, calling, testing, and interacting with contracts
* Deploying and interacting with Smart Rollups
* Working with accounts
* Calling RPC endpoints directly
* Running Sapling transactions
* Setting up baking operations for testing contracts
For more information about the Octez client, see [The Octez client](/developing/octez-client).
* **External clients**: Many external clients can add operations to the network of nodes or use nodes to inspect the state of the blockchain, including:
* Web applications that use SDKs such as Taquito to send and receive information from Tezos
* Wallet applications
* **Indexers and block explorers**: Indexers are off-chain applications that retrieve blockchain data, process it, and store it in a way that makes it easier to search and use.
They are an important part of block explorers, which are applications that provide data about the blockchain.
## Layer 2
Layer 2 consists primarily of nodes that run [Smart Rollups](/architecture/smart-rollups).
These nodes run logic that is separate from the layer 1 protocol logic; they can behave differently from how the Tezos protocol works, run at a different pace, use more data via the [Data Availability Layer](/architecture/data-availability-layer), and communicate with layer 1.
Smart Rollup nodes post data to layer 1 for verifiability with a bond for security; other systems can challenge the data to ensure that the Smart Rollup is running honestly.
One major use of Smart Rollups is to enable [Etherlink](https://etherlink.com), which is a Smart Rollup that runs an EVM-compatible protocol.
Users can work with Etherlink like any other EVM chain while taking advantage of the high scalability of Tezos layer 2.
Etherlink can also communicate with Tezos layer 1 and other EVM chains, allowing users to bridge assets in and out of Etherlink.
This diagram shows a high-level view of Tezos layer 2, including Etherlink:
## References
For more information about the architecture of Tezos, see:
* [Accounts and addresses](/architecture/accounts)
* [Tokens](/architecture/tokens)
* [Smart Optimistic Rollups](/architecture/smart-rollups)
* [Governance](/architecture/governance)
* [Indexers](/developing/information/indexers)
* [Block explorers](/developing/information/block-explorers)
* [Etherlink](https://docs.etherlink.com)
# Nodes
Tezos nodes are peer-to-peer programs running the Tezos protocol to participate in the Tezos network.
Anyone can run a Tezos node.
A Tezos node has three main roles:
* It validates blocks and operations
* It broadcasts blocks and operations to other nodes and receives them from other nodes over a peer-to-peer network
* It maintains a copy of the blockchain data and its associated state (also known as the ledger), which includes accounts and their balances, among other things
Beside these technical roles, nodes must satisfy two other important requirements:
* Support the governance of the blockchain
* Ensure the extensibility of the blockchain with new clients of different kinds
In order to meet these requirements, the software that nodes run is structured according to two major principles:
* It is separated into a protocol and a shell to make it easier to upgrade.
* It implements a client/server architecture, to allow composition with many other tools in a safe way.
Nodes cooperate with clients and with each other through an [RPC interface](#the-rpc-interface).
The Octez suite, which is an implementation of the Tezos node and other executables, instantiates these principles in the [Octez software architecture](https://octez.tezos.com/docs/shell/the_big_picture.html).
For instructions on running a node, see the tutorial [Run a Tezos node in 5 steps](/tutorials/join-dal-baker).
## Protocol and shell
The software that runs Tezos nodes is split into two main parts:
* The protocol, which interprets transactions and other operations in each block (also known as the *economic protocol*)
* The shell, which handles low-level functions like data storage and peer-to-peer network communication
The relationship between the shell and the protocol is like the relationship between an operating system and an application.
The operating system stays stable while the application can update itself.
In this way, Tezos can update how it works (its protocol) without requiring nodes to accept major changes to the software that they run (the shell).
For example, nodes can update to a new protocol version without restarting the shell.
### The protocol
The Tezos protocol is responsible for interpreting the operations in each block.
It also provides the logic that identifies erroneous blocks.
Unlike many other blockchains, Tezos is self-amending.
Its nodes can update the protocol that controls the possible operations and how they are processed; updates are performed via an online governance process.
These updates allow Tezos to adapt to new technologies and respond to user needs.
For example, protocol upgrades have added new features like Smart Rollups and have reduced the amount of time between blocks.
Users propose updates to the protocol through a voting process, using dedicated voting operations such as protocol proposals and protocol upvotes.
For information about the voting process, see [Governance](./governance).
### The shell
The shell is responsible for the fundamental functions of a distributed software application, including:
* Peer-to-peer communication that lets nodes exchange information
* Storage functionality that lets nodes store blocks, operations, and the current state of the chain
* A synchronization heuristic that starts nodes and keeps them in sync with the network
* A validator that checks that blocks are valid with help from the rules in the economic protocol
In particular, the validator is responsible for resolving the available blocks into a single linear sequence of blocks.
It chooses between the various blocks that baking nodes create, uses the protocol to verify and score them, and selects the tree head with the highest score.
Then it uses that linear chain in all of its work with the protocol, so the protocol is never aware of multiple branches.
## The RPC interface
The Tezos RPC (Remote Procedure Call) interface is a specification for a REST API that clients use to interact with Tezos nodes and nodes use to communicate with each other.
You may want to know this RPC interface if you are developing tools that need to query the Tezos blockchain or to interact with it, such as wallets, indexers, or Web3 libraries.
Clients use this interface to submit transactions and get information about the state of the blockchain, such as account balances and contract storage.
Tezos nodes act as servers and accept HTTP requests from clients and other nodes via this interface.
Tezos RPC uses JSON to send and receive data, but it does not adhere to the JSON-RPC specification.
All the RPCs served by the Tezos node are described as an OpenAPI specification at [Octez Node RPCs](https://octez.tezos.com/docs/api/openapi.html#octez-node) in the Octez documentation.
### Public and private RPC nodes
All Tezos nodes run RPC servers, but the RPC interface is subject to an access policy.
By default, RPC servers are private and do not accept all requests from every client.
When you work with a Tezos client, such as the Octez command-line client or the Taquito SDK, you select a public RPC node to send transactions to, or you can use a private RPC node that you have access to.
If you're using a testnet, you can get a list of public RPC nodes for that network at https://teztnets.com.
Other sources of public nodes include:
* [Community RPC Nodes](https://tezostaquito.io/docs/rpc_nodes) listed by ECAD Labs.
* [SmartPy nodes](https://smartpy.io/nodes)
* [RPC nodes](https://tezostaquito.io/docs/rpc_nodes) in the Taquito documentation
# Bakers
Baking is the process of creating new blocks in the Tezos blockchain.
Bakers are executables running alongside Tezos nodes that cooperate to achieve consensus about the next block to add.
Bakers validate pending operations, package them into a block, sign the block, propose the new block to other nodes, and verify that the blocks that other bakers propose are valid.
Baker executables are run on behalf of user accounts.
By extension, bakers also denote the users running baker daemons on behalf of their user accounts.
For instructions on becoming a baker, see [Run a Tezos node in 5 steps](/tutorials/join-dal-baker).
## The baking process
The baking process includes many steps that Tezos users and developers don't need to think about, but at a basic level, baking a block follows these steps:
1. The protocol selects in advance a list of bakers for each block to create in a *cycle*, which is a certain number of blocks.
2. It also selects a list of bakers to act as validators.
These bakers are responsible for validating the blocks that other bakers create and publishing *attestations* that the block is valid.
3. The first baker on the list has a certain amount of time (called a round) to create the next block.
It packages pending operations from the mempool into a block, signs it, and distributes it to other nodes.
4. If the first baker doesn't publish a block in time, the next baker on the list has a certain amount of time to bake a block (a new round), and so on until a block is created.
5. The validators verify the block and publish their attestations in future blocks.
6. The next list of bakers create the next block, until the end of the cycle.
Note that:
* The presentation above is somewhat simplified; in reality, validation is done in two phases, called pre-attestation and attestation.
* For any given block and round, only one baker has the right to create the block, and several bakers have the right to (pre-)attest the block.
## Becoming a baker
To become a baker, you must create an account to act as a *delegate*, which is an account that is authorized to bake blocks and attest blocks that other accounts bake, and also to receive delegations (and stake) from other accounts, as explained later.
Delegates temporarily stake tez as a security deposit to ensure that they are acting according to the rules of the protocol.
Deposits can be "unstaked" later, either partially (at any time) or totally (when bakers stop baking).
There is a delay of a certain number of cycles from the moment when the tez are staked until the delegate can begin baking.
Similarly, when tez are unstaked, they are unlocked after a certain number of cycles.
Staked tez may be slashed by the protocol if the baker misbehaves (e.g., proposes or attests two different blocks for the same level).
A delegate participates in consensus in proportion to their *baking power*: the more baking power a delegate has, the more likely it is to be selected to bake or to validate blocks and thus receive the rewards.
The baking power of a delegate is computed from the amounts of tez staked (by its own and by all its stakers) and owned (by its own and by all its delegators), knowing that non-staked tez are weighted one-third as much as staked tez in the sum.
The delegate must have a baking power of at least 6,000 tez to be allowed to bake.
A delegate also participates in [governance](/architecture/governance) in proportion to their *voting power*.
The voting power of a delegate is computed in a similar way to the baking power except that no distinction is made between tez that are staked or not staked.
Bakers must run at least one Tezos node, a baker daemon, and a [Data Availability Layer](/architecture/data-availability-layer) node.
These daemons must run at all times with a stable power source and internet connection, because periods of inactivity for a baker entail losses of rewards, and eventually being marked as inactive and temporarily excluded from baking.
## Staking with a baker
If you don't have enough tez to become a baker or don't want to run a baking node, you can choose a baker as your delegate, which makes you a *delegator*.
Then you can stake tez with that baker and receive a share of the baker's rewards.
For instructions on staking, see [Staking](/using/staking).
## Delegating to a baker
In older versions of the Tezos protocol, before users could stake with a baker, delegating was the primary way that users earned rewards for their tez.
Users delegated their accounts to a baker and in return the baker could choose to share some of their baking rewards with their delegators.
The rewards to delegators were distributed by the bakers, with no guarantee from the Tezos protocol.
Delegating still works in this way, but currently, it's mostly seen as a preliminary step required for staking.
In return, the Tezos protocol provides stakers with rewards automatically.
## Summary
In summary, here is a comparison between the staking and delegating options above:
| Staking | Delegating
--- | --- | ---
Increase baking power | 100% | 33%
Increase voting power | 100% | 100%
Reward delay | None | 2 cycles (about 2 days)
Reward route | Direct to staker | To baker who manually sends to delegator
Funds availability | Frozen (locked) | Liquid (unlocked)
Unlock delay | 2 cycles (about 2 days) | None
Slashing exposure | Yes | No
## References
To start delegating and staking, use the app at https://stake.tezos.com.
To start baking, use our [tutorial for bakers](/tutorials/join-dal-baker).
For more information about the different options to participate to the Tezos network (baking, staking, or delegating), see [Running Octez](https://octez.tezos.com/docs/introduction/howtorun.html) in the Octez documentation.
To learn more about baking and the related concepts, see [Node and Baking](https://opentezos.com/node-baking/baking/introduction/) on opentezos.com.
# Accusers
Accusers are programs that monitor new blocks, look for problems, and denounce bakers that introduce blocks with problems.
Accusers ensure that bakers play by the rules and do not abuse the reward mechanism of the Tezos protocol.
Accusers look for:
* Bakers that sign two blocks at the same level
* Bakers that inject more than one attestation for the same baking slot
When they see one of these problems, they emit a double-baking or double-attesting denunciation operation, which cause the offending baker to lose some of its stake.
Some of the slashed stake goes to the accuser.
Anyone can run an accuser, and they don't have to stake any tez like bakers must.
# Accounts and addresses
## Accounts
Tezos uses these types of accounts:
* User accounts (sometimes known as *implicit accounts*) store tez (ꜩ) and tickets.
Any wallet application or the Octez command-line tool can create user accounts.
* Smart contract accounts (sometimes known as *originated accounts*) store immutable code, mutable storage, tez (ꜩ), and tickets.
See [Smart contracts](/smart-contracts).
User accounts are *unrevealed* until they make a transaction.
They can store tez and tickets, but some services such as indexers may not see them.
To reveal an account, send any transaction from it, such as calling a smart contract or sending tez to any account, including itself.
You can also send a dedicated reveal operation as described in [Revealing accounts](/developing/octez-client/accounts).
## Addresses
* User accounts have addresses that start with "tz1", "tz2", "tz3" or "tz4."
* Smart contracts have addresses that start with "KT1."
* Smart Rollups have addresses, but are not accounts because they cannot store tez.
Their addresses start with "sr1".
They have a tree of commitments attached to them.
See [Smart Optimistic Rollups](/architecture/smart-rollups).
## Multi-signature accounts
Multi-signature accounts are a specific kind of user account that require each operation to be signed by several other user accounts before running it.
They are a native counterpart of [Multi-signature contracts](/smart-contracts/multisig), which can be found in many blockchains (including Tezos).
Multi-signature accounts provide several important benefits, including:
* Enhanced security: If an attacker gets control of one key, it is not enough to control the entire account
* Shared responsibility: Multiple users can manage the account collectively
* Versatility: They can be used like any other user account, including for collective staking or baking (which is not the case for multi-signature contracts)
For information about setting up multi-signature accounts, also known as "multisig accounts," see [Creating multi-signature accounts](/developing/octez-client/accounts#multi-signature-accounts) or the tutorial [Staking and baking with native multisig accounts](/tutorials/native-multisig).
Built-in multi-signature accounts were introduced in the Seoul protocol and use addresses that start with `tz4`, which are created with the BLS signature scheme.
These accounts can delegate, stake, and bake just like other accounts.
They can also take advantage of efficiencies of aggregating attestations into a single operation.
Bakers wanting to take advantage of aggregated attestations should use `tz4` addresses for their consensus key (or their baker key, if they are not using a consensus key).
For more information, see [tz4: BLS](https://octez.tezos.com/docs/active/accounts.html#tz4-bls) in the Octez and protocol documentation.
# Tokens
In a blockchain ecosystem, a digital asset that can be transferred between accounts is called a *token*.
Like other blockchains, Tezos relies on a native token in which transaction fees are paid.
The native token of Tezos is tez (also known as XTZ or represented by the symbol ꜩ).
Internally, Tezos tracks tez balances in mutez, or one-millionth of one tez.
For example, if you get an account balance with the RPC request `/chains/main/blocks/
2. Above the list of tokens, click the display options button:
3. Under **Filter by network**, expand **All Networks**.
4. Select **Shadownet**:
5. Click the `X` button at top right of the Select Network page to close the list of networks.
6. Click the `X` button next to the search box to close the display options.
Now the wallet displays your tokens on the testnet and sends transactions on the testnet instead of Mainnet.
If the wallet does not have built-in support for the testnet that you want to use, you may need to add the test network manually.
For example, these steps are for the Temple wallet:
1. Go to https://teztnets.com/, which lists Tezos testnets.
2. Click the testnet to use.
3. Copy one of the public RPC endpoints for the testnet.
These URLs accept Tezos transactions from wallets and other applications.
4. In the Temple app, click **Settings > Networks**.
5. Click the plus `+` symbol to add a network.
6. On the Add Network page, enter the name of the network, the RPC URL that you copied, and any other information about the testnet, as shown in this picture:
7. Click **Save**.
Now you can see your balances and send transactions to the network.
You can also filter transactions to show only those on this network.
## Funding a wallet
Follow these steps to get testnet tez for the wallet:
1. From your wallet, get the address of your account, which starts with `tz1`.
This is the address that applications use to work with your wallet.
2. Go to the faucet for the testnet, such as https://faucet.shadownet.teztnets.com for Shadownet.
3. On the faucet page, paste your wallet address into the input field labeled "Fund any address" and click the button for the amount of tez to add to your wallet.
It may take a few minutes for the faucet to send the tokens and for those tokens to appear in your wallet.
You can use the faucet as much as you need to get tokens on the testnet, within the limits of what the faucet allows, but those tokens are worthless and cannot be used on Mainnet.
# Testing locally
Tezos smart contracts are immutable after deployment, so you must rigorously test them before deploying them to ensure functionality, prevent errors, and avoid potential financial losses. Importantly, contract testing doesn't require any tokens or a wallet account to execute.
## Tools for local testing
* The Michelson interpreter is an OCaml function that can be used by tools to simulate a call to any entry point of any smart contract, given an initial value of the storage and parameters. Some programming languages like LIGO or SmartPy use this as part of their testing frameworks.
* The mockup mode of `octez-client` can be used to test contract calls and other features such as some RPC calls, all without running an actual node, saving the time of going through the consensus mechanism and waiting to get blocks created and validated. Find out more in the [documentation of the mockup mode](https://octez.tezos.com/docs/user/mockup.html).
For example, when you compile the contract in the tutorial [Create a smart contract](/tutorials/smart-contract) to Michelson, its first line defines the parameter type that the contract accepts:
```
parameter (or (unit %reset) (or (int %decrement) (int %increment)))
```
You can call this contract in mockup mode by passing the compiled contract file, the storage value as a Michelson expression, and the parameter value to pass as a Michelson expression.
For example, this command sets the storage to 4 and passes 5 to the `Increment` entrypoint:
```bash
octez-client --mode mockup run script Counter.tz on storage 4 and input "(Right (Right 5))"
```
The response in the console shows the new value of the storage and any operations emitted.
## Testing in high-level languages
High-level languages come with tools to help write tests locally, and some testing tools can be used independently of the language used to write the smart contract.
For example, SmartPy includes syntax dedicated to testing; see [Test scenarios](https://smartpy.tezos.com/manual/scenarios/test_scenarios.html).
The following SmartPy test code snippet is for a Tezos smart contract that acts like a calculator. The code defines a series of tests to check the functionality of the calculator contract.
```bash
if "templates" not in __name__:
@sp.add_test()
def test():
c1 = main.Calculator()
scenario = sp.test_scenario("Calculator")
scenario.h1("Calculator")
scenario += c1
c1.multiply(x=2, y=5)
c1.add(x=2, y=5)
c1.add(x=2, y=5)
c1.square(12)
c1.squareRoot(0)
c1.squareRoot(1234)
c1.factorial(100)
c1.log2(c1.data.result)
scenario.verify(c1.data.result == 524)
```
The test scenario runs these operations sequentially and would check if all operations execute as expected and if the final result matches the expected value.
## Structure of a test scenario
A test scenario usually consists of the following steps:
1. Decide the smart contract's initial storage and `balance`
2. Valid calls to entrypoints, with different parameters and context information such as:
* the address of the `caller`
* the amount of `tez` sent
* the `timestamp` of the block (value of `now` during the call)
* the `level` of the block
3. Verify the contract's storage or `balance` changed the way you expected.
4. Invalid calls to entrypoints, and they are expected to fail.
5. Verification of the error caused by these invalid calls, making sure the error messages are the ones you thought would come up.
When executed, the test scenario is successful if all verifications are correct, and all invalid calls fail with the expected errors.
More advanced scenarios may involve a local sandbox deployment and calls to multiple contracts to test interactions.
## Programming languages for testing
The test scenarios are usually written using a full classical programming language, such as JavaScript or Python, with a library that gives you access to special features to:
* Deploy contracts
* Make calls to entrypoints
* Manipulate all the types/values supported by Tezos
* Generate testing accounts, to simulate calls from multiple accounts
* Perform cryptographic computations similar to the ones available in the contract
## Rules for testing
Testing a contract thoroughly is not easy and requires experience.
Here are some tips to follow when getting started:
* Write tests without looking at the implementation of the contract to avoid copying mistakes.
* If possible, have another developer write the test to avoid testing semantic errors incorrectly.
* Make sure to cover every possible execution path, whether it's valid or invalid.
* Create many small tests, each checking something very specific, rather than a long test that tries to do many things at once.
* Test around the limits
For example, if a value should be always above 10, include a call with the value 10 that should fail and a call with the value 11 that should succeed.
* Test extremes
For more information about avoiding flaws in contracts, see [Avoiding flaws](https://opentezos.com/smart-contracts/avoiding-flaws/) on opentezos.com.
## Implementation details
* Michelson: [Mockup mode](https://octez.tezos.com/docs/user/mockup.html)
* SmartPy: [Test scenarios](https://smartpy.tezos.com/manual/scenarios/test_scenarios.html)
* LIGO: [Testing LIGO](https://ligo.tezos.com/docs/testing)
## Next steps
When you're done testing contracts locally, you can deploy them to a test network and test them there.
See [Testing on testnets](/developing/testnets) and [Using a local sandbox](/developing/sandbox).
# Testing on testnets
:::note
The current testnets and details about them are at https://teztnets.com/.
:::
If you are a smart contract developer, testing contracts is a big part of your work. More time is spent testing contracts than writing them. You will often need to test new versions of your contracts and run many tests starting from their deployment to calling every entrypoint in all kinds of ways.
After you have tested contracts locally as described in [Testing locally](/developing/testing), you can deploy them to test networks to test them in a realistic environment.
Similarly, bakers often test their setups on test networks to ensure that they will work on new versions of the Tezos protocol.
## Testing with public test networks
If you want to test your development in conditions that are close to those of Tezos Mainnet, you can use one of several public test networks.
These networks behave like Mainnet with a few differences:
* You can use faucets to obtain tez for free on these networks, so you don't need to (and can't) spend actual tez.
* They use different constants than Mainnet, such as reduced block times and shorter cycles for faster testing and reduced windows for inserting rejections in rollups.
* Tools like public block explorers or indexers may or may not be available, depending on the network.
* Tools such as wallets may or may not support testnets.
* They either use a modified version of the amendment process or don't use it at all.
* In some cases, you must use specific versions of tools such as the Octez suite to work with them.
Regardless of the type of network, if you intend to make many requests or transactions, you can run your own nodes on these networks to avoid availability issues and rate limits.
## Types of test networks
Type | Longevity | Target users | Examples
--- | --- | --- | ---
[Permanent test networks](#permanent-test-networks) | Permanent | dApp developers and bakers | Shadownet, Ghostnet
[Protocol test networks](#protocol-test-networks) | During the protocol amendment process | Protocol developers | Seoulnet, Tallinnnet
[Periodic test networks](#periodic-test-networks) | Short-term | Protocol developers and bakers | Weeklynet
### Permanent test networks
Permanent test networks are networks that are meant to run for a long time.
Typically, they migrate to a new protocol version during the Adoption governance period, which is after the last round of voting but before the new version activates on Tezos Mainnet.
Developers can then use the test network to verify that their applications will work on Mainnet with the new protocol.
Similarly, bakers can use the test network to verify that their baking setups will work.
These test networks are available:
* **Shadownet** is the new primary test network.
Shadownet is intended to be a true pre-production environment, as similar to Tezos Mainnet as possible.
For example, the stake of the largest bakers on Shadownet is distributed to mimic the distribution of the largest bakers on Mainnet.
For this reason, users should treat Shadownet not as a place for early tests and experiments but as a staging environment prior to using Mainnet.
In particular, bakers should maintain reliable setups to help ensure that the test network behaves in a way very similar to Mainnet, such as with similar uptime and availability.
:::note
Because Shadownet is new, not all wallets and tools support it yet.
:::
* **Ghostnet** is the legacy test network that will be removed soon.
:::note
Developers who use Ghostnet should migrate to Shadownet.
:::
For information about current test networks, including links to their faucets, RPC nodes, and block explorers, see https://teztnets.com/.
For developers, using a permanent test network is convenient compared to other public test networks because they can keep contracts running for a long time without having to set things up on a new network when the previous one gets shut down.
Services such as indexers, explorers, or public nodes also tend to run more reliably on these networks than on periodic networks because periodic networks change frequently to test new features.
### Protocol test networks
Protocol test networks are created for a specific version of the protocol.
They allow developers and bakers to anticipate the changes brought by upcoming protocol amendments.
When an amendment is proposed, a corresponding network is created. This network gets joined by more bakers as the proposal is selected and moves through the different periods of the self-amendment process. If the protocol passes the 3 votes of the amendment, joining a test protocol early gives you about 2.5 months to test all the changes that will be made to Mainnet. If the protocol is not adopted the network is discarded or sometimes remains active until a different protocol is adopted.
This means there is usually one or two such running networks: one for the current version of the protocol running on Mainnet, and possibly one for the proposed protocol that is going through the amendment process, if there is one.
Whether you are a developer or a baker, testing on the network for a new proposal before it gets activated enables you to check that all your software, smart contracts, dApps, and other tools work well with this new proposal.
It also enables you to test any new features of this proposal. Trying the features can help you form your own opinion about this proposal and discuss it with the community before voting on it.
When the protocol is activated, the corresponding protocol test network can be a good network for a baker to run tests with the current version of the protocol, because these networks are lightweight to bootstrap and have reduced context sizes.
On the other hand, these networks may be less convenient for smart contract or dApp developers to use because they have a limited life span and tend to be less supported by services like indexers and other tools.
### Periodic test networks
Periodic test networks allow developers to test new features that are under development before those features become part of a proposal or reach Tezos Mainnet.
These networks are based on Alpha development versions of the Tezos economic protocol and the Octez suite.
The periodic network currently available is Weeklynet, which is named this way because it restarts every Wednesday, with the latest Docker build as a reference. It is the place to test upcoming new features. It is also a network to use if you are a big baker or a BaaS provider and you want to test tailored infrastructure.
### Working with periodic test networks
To work with the periodic test networks, you must use exactly the same version of the Octez suite as the network.
For this reason, common wallet apps typically don't work with these networks.
For example, you can look up information about Weeklynet at https://teztnets.com/weeklynet-about.
This page shows the URL of a Weeklynet RPC endpoint to use and instructions for connecting to the network in different ways.
There are two main ways to use periodic test networks:
* Run the Docker image with the correct version of the Octez suite
* Build the Octez suite from the specific Git commit that is listed on the test network page
In either case, you must connect the Octez suite to the test network RPC endpoint.
For example, if the Weeklynet endpoint on https://teztnets.com/weeklynet-about is `https://rpc.weeklynet-2024-01-17.teztnets.com`, you can connect the Octez client by running this command:
```bash
octez-client -E https://rpc.weeklynet-2024-01-17.teztnets.com config init
```
Then you can create a local wallet by running `octez-client gen keys my_account` and fund it with the network faucet.
For convenience, teztnets.com provides information about the test networks at https://teztnets.com/teztnets.json.
You can use the data from this file to set up your environment, such as setting environment variables.
For example, to get information about Weeklynet, install the `curl` and `jq` programs and run this command:
```bash
curl https://teztnets.com/teztnets.json | jq '.[] | select(.human_name == "Weeklynet")'
```
You can use the response to set environment variables like the RPC endpoint, as in this code:
```bash
curl https://teztnets.com/teztnets.json | jq '.[] | select(.human_name == "Weeklynet")' > weeklynet.json
export WEEKLYNET_ENDPOINT=$(jq -r .rpc_url weeklynet.json)
export WEEKLYNET_COMMIT=$(jq -r .git_ref weeklynet.json)
export DOCKER_IMAGE=$(jq -r .docker_build weeklynet.json)
```
Here are some other tips for using the Docker images for periodic test networks:
* The Docker images for each instance of the periodic test networks are listed on the information page for the network.
For example, Weeklynet information is here: https://teztnets.com/weeklynet-about.
* The Docker images are based on Alpine Linux, which uses the `apk` package manager.
For example, to install the `curl` program, run `sudo apk add curl`.
* The shell interpreter path is `/bin/sh`, not `/usr/bin/bash` as on many Linux distributions.
## Public nodes and faucets
To connect to existing public nodes for these networks, or to get some testnet-only tez on these from a faucet, check [https://teztnets.com](https://teztnets.com/).
Other sources of public nodes include:
* [Community RPC Nodes](https://tezostaquito.io/docs/rpc_nodes) listed by ECAD Labs.
* [SmartPy nodes](https://smartpy.io/nodes).
## Testing with your own private network
In some special cases, you may want to run your own private network for your testing. This could be true if you are developing tools that you want to keep confidential until you put them into production, and if the sandboxed mode is not sufficient for your situation.
See the [Private blockchain](https://opentezos.com/private) section on OpenTezos to learn how to set up your own network.
## More information
* [Test networks](https://octez.tezos.com/docs/user/multinetwork.html#test-networks)
# Using a local sandbox
Local sandboxes allow you to test your work without sending any transactions to Tezos Mainnet or testnets.
They run a simulated version of the Tezos protocol locally so you can test contracts, dApps, or other projects while interacting with actual nodes, but without using a public test network or creating your own private network.
Sandboxes can be convenient if you want to run all your tests locally but still need a realistic Tezos environment, such as if you need to interact with nodes and the consensus mechanism.
Testing locally can also keep your work confidential until you decide to put it into production.
However, sandboxes lack some features that [testnets](/developing/testnets) have, such as indexers and block explorers.
If you want an indexer or block explorer for your sandbox, you must run it yourself.
Here are some options for running local Tezos sandboxes:
## Octez sandboxed and mockup modes
The Octez client sandboxed and mockup modes run a local version of the Tezos network.
* [Sandboxed mode](https://octez.tezos.com/docs/user/sandbox.html) runs a local network with one or more nodes.
* [Mockup mode](https://octez.tezos.com/docs/user/mockup.html) runs a light version of the network without nodes.
## Tezbox
[Tezbox](https://github.com/tez-capital/tezbox) is a simulated Tezos environment that runs in a container.
Tezbox provides different images that mirror versions of the Octez suite.
For example, to run Tezbox with Octez version 19.1 and the Paris protocol, run this command:
```bash
docker run --rm -it --name tezbox -p 0.0.0.0:8732:8732 ghcr.io/tez-capital/tezbox:tezos-v22.1 riobox
```
The container runs in the background and provides an RPC node at http://localhost:8732.
Then you can use the sandbox through that RPC node.
For example, you can configure the Octez client to use the sandbox by running this command:
```bash
octez-client -E http://localhost:8732 config update
```
Then you can use your local installation of the Octez client to interact with the sandbox, such as deploying contracts and sending transactions.
Tezbox provides sample accounts in the `/tezbox/context/accounts.json` file.
## Flextesa
[Flextesa](https://tezos.gitlab.io/flextesa/) is also a simulated Tezos environment that runs in a container.
The Flextesa image has different scripts that start different versions of the Tezos protocol.
For example, to start a Flextesa sandbox with the Oxford protocol, run this command:
```bash
image=oxheadalpha/flextesa:latest
script=oxfordbox
docker run --rm --name "$script" --detach -p 20000:20000 \
-e block_time=3 \
"$image" "$script" start
```
Then you can see the accounts that are available by running this command:
```bash
docker exec $script $script info
```
The Flextesa image comes with the Octez client pre-configured, so you can use it directly from the image.
These commands create an alias for the installation of the Octez client in the image and uses it from the host system:
```bash
alias tcli='docker exec my-sandbox octez-client'
tcli get balance for alice
```
Now you can use the Octez client to deploy contracts and send transactions to the sandbox.
Flextesa allows you to control baking manually, so blocks are only backed when you trigger them.
For more information, see the [Flextesa documentation](https://tezos.gitlab.io/flextesa/).
# Storing data and files with IPFS
Because storage space on blockchains is expensive, developers don't put large files or large pieces of static data on Tezos.
Instead, they configure off-chain storage for the files or data and put a link to that data on Tezos itself.
There are different ways to store data in this way, but many blockchain developers use the InterPlanetary File System (IPFS) protocol because it is decentralized.
Some examples of files or data that developers often store on IPFS are:
* Smart contract metadata
* Token metadata
* Token media, such as thumbnails and preview images
One way to upload (or *pin*) data to IPFS is to use Pinata's IPFS provider.
Follow these steps to set up a Pinata account and use it to pin data to IPFS:
1. Create a free Pinata account at https://app.pinata.cloud/developers/api-keys.
2. Go to the API Keys tab and click **New Key**.
3. On the Create New API Key page, in the **Key Name** field, give the key a name, such as `My Key`.
4. Under **Customize Permissions > V3 Resources**, for the **Files** permission, select **Write**:
5. Under **Legacy Endpoints**, in the **Pinning** section, select all of the permissions:
6. Click **Create**.
The API Key Info window shows the API key and secret, which you must copy immediately, because it is not shown again.
7. Copy the API Key and API Secret fields and save the values on your computer.
You need these values in the next section.
You can see the new API key on the API Keys tab:
Now you can upload data to IPFS via Pinata in many different ways, including:
* Directly on the Pinata web site
* The SmartPy `sp.pin_on_ipfs` function; see [Creating and publishing metadata](https://smartpy.tezos.com/manual/scenarios/metadata.html) in the SmartPy documentation and the tutorial [Create a fungible token with the SmartPy FA2 library](/tutorials/smartpy-fa2-fungible)
* The Pinata API and SDK; see https://docs.pinata.cloud
:::warning
Keep your Pinata API Secret private; do not expose it in a frontend web application.
If you want to pin data to IPFS in a web application, you may need to work with Pinata in a backend application to keep your Pinata information secret.
:::
# Avoiding common mistakes
Because of how different blockchain programming is from other types of programming, new blockchain developers often make certain mistakes.
This section covers some functional and security problems that developers should know about working with Tezos and other blockchains:
## Keeping contracts from becoming blocked
Because the code of a contract cannot be changed after it is deployed, it's important to test contracts thoroughly before deploying them.
This includes testing all points in its life cycle, including its initial deployment and storage, its behavior throughout its lifespan, and how it is removed from use.
One simple mistake that happens surprisingly often is not providing a way for an administrator to withdraw tez that are in the contract.
Without an explicit way of making the contact send tokens to another address, any tez intentionally or mistakenly sent to the contract are locked in it forever.
Here are some other ways that contracts can become blocked and unusable:
:::note
Remember that a contract can become unusable because of mistakes by the developer, sometimes exploited by malicious activities by bad actors.
:::
* **Storage becomes too large**: As described in [Staying within resource constraints](/developing/security/resource-constraints), a contract's storage can become too large, making it impossible to load the contract and its storage in a single transaction.
When this happens, it becomes impossible to use the contract, even to call entrypoints to reduce its storage.
For this reason, ensure that the size of the contract's storage is limited, such as using big-maps for data instead of standard maps.
* **Computation requirements become too large**: Similarly, there is a limit to the amount of computation that can happen in a single transaction.
If the contract contains loops or other iterative logic, ensure that no future change to the contract could cause it to require more computation than the limit.
* **Failures in logic**: Examine the logic of your contracts closely to ensure that they cannot get into a blocked state.
For example, if a contract requires a user to call one entrypoint and then another, ensure that the contract does not become blocked if the user calls the first entrypoint and then never calls the other.
* **Overflows of large numbers**: Tezos can handle arbitrarily large integers and natural numbers.
However, amounts of tez are limited to a 64-bit signed integer.
This limit usually comes into play only in intermediate values, amounts that are used in mathematical calculations.
You must ensure that calculations that use large amounts of tez don't overflow and cause operations to fail and block the contract.
If necessary, you can use integers or natural numbers for large numbers in calculations.
* **Dependencies on other contracts or accounts**: If the contract depends on other contracts, make sure that failures in those contracts do not block the contract permanently.
You may need to include a way to modify the contract to account for changes or failures in other contracts.
For example, if the contract calls another contract, consider including a way to change the address of the target contract so you can change it later if necessary.
Similarly, if the contract has an administrator account, consider including a way to change it.
Contracts can also become blocked by waiting on some interaction.
Suppose a contract holds an auction for one item at a time, and when the auction completes, it waits for the winner to pay and claim the item.
If the winner does not do anything, the contract may become blocked.
In this case, make sure there is another way to unblock the contract that does not depend on a single account.
In the same way, remember that if one operation in a chain fails, the entire chain fails.
For example, imagine that a contract creates multiple operations to send rewards to a group of beneficiaries as the result of a single transaction.
If any one of those operations fail, they all fail.
A better way to handle this use case is to allow the beneficiaries to call an entrypoint to claim their own rewards.
## Differences in blockchain programming
Here are some notable ways in which blockchain programming on Tezos is different from other types of programming:
* **Error handling**: As described in [Handling errors](/smart-contracts/logic/errors), exception management on Tezos is very different from other programming platforms.
Instead, Tezos uses *failures*, which immediately cancel operations and revert the entire chain of operations that led to the failure.
In this way, even if an operation succeeds, it can still be reverted if future operations in the chain fail.
* **Options and variants**: Partly as a way of preventing errors, Tezos, its Michelson base language, and its higher-level languages use option and variant types, which some programmers may not be familiar with.
Check the documentation for the [language](/smart-contracts/languages) that you are using for more specific information.
For example, division by zero is not defined.
Some languages throw an exception if you try to divide by zero.
By contrast, Tezos languages return an option type as the result of division.
The option is the `None` option if the result is undefined or the `Some` option with the result of the division.
Even if you are confident that your code will never divide by zero, you must still handle both options.
For more examples, see [Options](/smart-contracts/data-types/complex-data-types#options)
* **Rounding and decimals**: To prevent rounding errors, Tezos does not use floating-point numbers.
All numbers, including amounts of tez (stored internally as mutez, or one-millionths of a tez), are stored as integers or natural numbers.
For more information, see [Numeric data types: int and nat](/smart-contracts/data-types/primitive-data-types#numeric).
Nevertheless, even when using integer amounts, it can be tricky to do mathematical operations like splitting amounts between participants.
For example, if you want to split an amount of tez 60%-40% between two accounts, don't give one account 60% of the amount and the other 40%, because remainders may make the totals inaccurate.
In cases like this, send the first amount and then use subtraction to determine the remaining amount to send to the second account.
* **Bitwise instructions**: Bitwise instructions change the individual bits of a binary value.
For example, some bitwise instructions shift bits to the left or right by a certain number of positions, filling the vacated bits with zeroes.
However, left shifting can cause an overflow, which can cause unexpected results or errors when the contract runs in Michelson.
To avoid this problem, check the size of the input and the shift amount before applying bitwise instructions.
# Avoiding common attacks
Here are some other common attacks that blockchain developers must be aware of:
* **Replay attacks**: A replay attack allows an attacker to reuse a signed valid transaction multiple times.
Tezos prevents most instances of this type of attack by requiring a transaction to be signed by a nonce, which changes each time the transaction is executed.
Still, be aware that transactions on Tezos are publicly visible and the data in them can be seem by anyone.
* **Re-entrancy attacks**: Re-entrancy attacks take advantage of the asynchronous nature of blockchain transactions.
Attackers call a contract repeatedly and quickly to take advantage of flaws in a contract or make a denial of service attack.
One of the most well-known examples of a re-entrancy attack occurred in 2016 when an attacker exploited a [vulnerability](https://crypto.news/the-dao-attack-understanding-what-happened/) in the DAO (Decentralized Autonomous Organization) contract on the Ethereum blockchain.
These types of attacks are more difficult on Tezos because of how it puts operations in a specific order, as described in [Operations](/smart-contracts/logic/operations).
However, you must still ensure that your contracts cannot be manipulated by re-entrancy attacks.
For example, some re-entrancy attacks take advantage of applications that store logic in multiple contracts.
Attackers may send multiple transactions to a single contract before it can update other contracts or get information from them.
If a group of contracts that store tokens use one contract to accept withdrawal requests and another to store balances, an attacker might be able to submit multiple withdrawals before the balance is updated.
* **Sandwich attacks**: Also known as MEV attacks or front-running, sandwich attacks take advantage of the fact that incoming transactions are publicly visible.
If an attacker sees a large cryptocurrency trade, they may be able to insert transactions before and after it to make a profit.
In some cases, bakers can make a profit by ordering transactions in a certain way or inserting their own transactions in blocks that they create.
To avoid this kind of attack, use Tezos timelocks or another way to order transactions fairly, or use [Etherlink](https://etherlink.com), which has a fair sequencer.
* **Using centralized oracles**: Because smart contracts can't access data from outside the blockchain, including calling external APIs, they use oracles to provide the data.
For example, some contracts use oracles to provide random values; see [Using randomness safely](/developing/security/randomness).
It's important to use oracles that are secure and trustable, otherwise they open your contract to manipulation.
Trustable oracles average multiple sources of data like currency prices to ensure that the information does not rely on a single source.
Then they use encryption to sign data and prove that it is authoritative.
For ways to set up oracles to be trustable, see [Using and trusting oracles](https://opentezos.com/smart-contracts/oracles) on opentezos.com.
# Handing authorization
When developing a contract, you may want to restrict who can call a certain entrypoint or perform a certain action.
In this case you must ensure that:
* The request comes from an authorized entity
* The authorized entity cannot be tricked into sending the request
To determine which account sent a request, you may be tempted to get the source of the transaction.
In Tezos, the source of the transaction is the address of the account that submitted the operation that started a chain of operations, but not necessarily the account that sent the immediate transaction that the contract is running now.
Relying on the source of the transaction can allow a malicious contract to impersonate an account when it calls another contract.
:::warning
For this reason, contracts should never use the transaction source for authorization purposes.
:::
Remember:
* **Source**: The address of the account that created the first operation in a chain of operations
* **Sender**: The address of the account or smart contract that created the most recent transaction in the chain
For example, assume that account A calls smart contract B, which generates an operation to call smart contract C.
When C runs, in Tezos terms, account A is the *source* of the transaction and smart contract B is the *sender* of the transaction.
Therefore, if it uses the source to determine which account calls it, contract B could trick it into thinking account A called it.
In this way, a malicious contract can invite accounts to make seemingly innocent transactions and use the operation chain to impersonate those users in other transactions.
```mermaid
sequenceDiagram
Account A->>Contract B: Transaction tx1Source: Account A
Sender: Account A Contract B->>Contract C: Transaction tx2
Source: Account A
Sender: Contract B ``` Checking whether the sender (the address of the immediate caller) is authorized to perform an operation is better. Because the request comes directly from an authorized entity, contracts can be more confident that the call is legitimate. This approach is a good default choice if both conditions hold true: 1. The sender contract is well secured against emitting arbitrary operations. For instance, it must not contain a certain kind of ["off-chain view" entrypoint](https://gitlab.com/tezos/tzip/-/blob/master/proposals/tzip-5/tzip-5.md#view-entrypoints). Ordinary on-chain views do not have this vulnerability because they cannot create operations. For more information about views, see [Views](/smart-contracts/views). 2. You need to authorize only an immediate caller and not the contracts somewhere up in the call chain. ## Using tickets for security If either of these conditions is not met, you may need to use tickets to authenticate requests. Tickets can be transferred, but they always have the address of the contract that created them as their ticketer. In this way, tickets allow you to verify that requests came from a certain contract. For example, you can set up a contract that authenticates requests by requiring a ticket with the request, using the address of the ticketer to determine the permissions for the action, and using the data in the ticket as the parameters or input for the request. In general, sender-based authorization is appropriate only for simple scenarios, such as when the contract has a single "owner" address controlled by a user account. In more complex scenarios, ticket-based authorization is often better. # Staying within resource constraints Tezos limits the size of an operation so that nodes can broadcast operations over the network in a reasonable time. It also places a limit on the computations that bakers need to perform to validate an operation to keep the network running smoothly. This limit is called the *gas limit* because it is the maximum amount of computations (measured in *gas units*) that a single operation can require. Of course, developers make their contracts efficient to save on gas fees, but they must also keep the gas limit in mind because it can lead to security vulnerabilities. For example, look at this seemingly innocent JsLIGO wallet contract that stores an event log: ```jsligo import Tezos = Tezos.Next; import Test = Test.Next; namespace WalletWithFlaw { // Variant for two types of transactions export type transaction = ["Deposit", [address, tez]] | ["Withdrawal", [address, tez]]; export type storage = { owner: address, transactionLog: list
| Storage | Entrypoint effects |
|---|---|
|
|
| Contract A | Contract B | Contract C |
|
|
|
This object allows you to set an RPC node to use for each of Mainnet and a test network of your choice and switch between them with the **Network** drop-down list.
# Connecting accounts
Connecting to a user's wallet allows your application to see the tokens in it and to prompt the user to submit transactions, but it does not give your application direct control over the wallet.
Users still confirm or reject all transactions in their wallet application, so you must handle both of these use cases.
Using a wallet application in this way saves you from having to implement payment processing and security in your application.
Game developers can also use the wallet and its account as a unique account identifier and as the user's inventory.
For more information about Tezos wallets, see [Installing and funding a wallet](/developing/wallet-setup).
## Best practices
When working with wallets, be sure to follow the advice in [Best practices and avoiding flaws](/dApps/best-practices) for wallet connections.
For example, don't force the user to connect their wallet as soon as the application loads.
Instead, let them see the application first.
Also, provide a prominent disconnect button to allow users to disconnect one account and connect a different one.
## Connection methods
This table shows the ways that the SDK can connect to wallets and which platforms they are appropriate for:
Connection method | Description | Web platform (WebGL) | Mobile apps | Standalone applications
--- | --- | --- | --- | ---
QR code | Users scan a QR code with a wallet app | Yes | No | Yes
Deep link | The application opens the user's wallet app directly | Yes | Yes | No
Social wallets | The application opens the user's Kukai web-based wallet | Yes | No | No
When wallets connect or disconnect, the SDK runs the `WalletConnected` or `WalletDisconnect` events for non-social wallets and the `SocialLoggedIn` and `SocialLoggedOut` events for social wallets.
## Wallet types
The SDK supports three types of wallets:
* Wallets that use the Tezos blockchain and connect to applications through the octez.connect protocol, such as Temple
* Wallets that use the Tezos blockchain and connect to a federated identity login through [Kukai](https://wallet.kukai.app)
* Wallets that use the Etherlink blockchain and connect to applications through the WalletConnect protocol, such as MetaMask
## Connecting to octez.connect wallets
Unity applications can connect to octez.connect wallets by showing a QR code that the user scans with a wallet app or by opening that app directly through the octez.connect protocol.
For an example of this method, see [Quickstart](/unity/quickstart).
This method for connecting follows these general steps:
1. The Unity application calls the `TezosAPI.ConnectWallet()` method and passes the octez.connect wallet type:
```csharp
var walletProviderData = new WalletProviderData { WalletType = WalletType.BEACON };
try
{
var result = await TezosAPI.ConnectWallet(walletProviderData);
_infoText.text = result.WalletAddress;
}
catch (WalletConnectionRejected e)
{
_infoText.text = "Wallet connection rejected";
Debug.LogError($"Wallet connection rejected. {e.Message}\n{e.StackTrace}");
}
catch (Exception e)
{
Debug.LogException(e);
}
```
2. The Unity application connects in different ways depending on the platform:
* On WebGL applications, the SDK uses the octez.connect SDK to open a popup window that prompts the user to select a compatible wallet via a deep link or to show a QR code:
* On mobile applications, the application attempts to open a octez.connect wallet on the same device directly.
* On mobile applications, you can also generate a barcode yourself.
On mobile applications, the `TezosAPI.ConnectWallet()` method triggers the `PairingRequested` event, which you can use to make the `Tezos.QR.QrCodeGenerator` class generate a QR code and show it on the interface for the user to scan with a wallet app.
3. Regardless of the connection method, the SDK runs the `WalletConnected` event and the `TezosAPI.ConnectWallet()` method returns information about the connected account.
## Connecting to WalletConnect wallets
Unity applications can connect to EVM wallets such as MetaMask by showing a popup window that helps users connect.
The popup window can show a QR code for wallet apps to scan or open wallet apps on devices directly.
Follow these steps to connect to a wallet with the WalletConnect protocol:
1. Install the Tezos Unity WalletConnect SDK:
1. Make sure the Tezos Unity SDK is installed as described in [Installing the SDK](/unity/quickstart#installing-the-sdk).
2. In your Unity project, in the Package Manager panel, click the `+` symbol and then click **Add package from git URL**.
3. Enter the URL `https://github.com/trilitech/tezos-wallet-connect-unity-sdk.git` and click **Add**.
The Package Manager panel downloads and installs the WalletConnect SDK.
2. In the Unity project, add a button that users click to connect their wallet and a button that users click to disconnect their wallet.
You will add code to these buttons in a later step.
You can also use a single button and change its behavior to connect or disconnect based on whether there is a currently connected wallet.
3. Add a TextMeshPro text field to show information about the connection, such as the account address.
The scene looks similar to this example:
4. In your Unity project, add a class in a script file to hold the code for the connection operations.
The class must inherit from the Unity `MonoBehaviour` class, as in this example:
```csharp
using System;
using Netezos.Encoding;
using Tezos.API;
using Tezos.Operation;
using Tezos.WalletProvider;
using TMPro;
using UnityEngine;
using UnityEngine.UI;
public class MyScripts : MonoBehaviour
{
[SerializeField] private TMP_Text _infoText;
[SerializeField] private Button _connectButton;
[SerializeField] private Button _disconnectButton;
private async void Awake()
{
await TezosAPI.WaitUntilSDKInitialized();
// Check for prior connections
if (TezosAPI.IsConnected()) _infoText.text = TezosAPI.GetConnectionAddress();
// Run functions when users click buttons
_connectButton.onClick.AddListener(OnConnectClicked);
_disconnectButton.onClick.AddListener(OnDisconnectClicked);
}
private async void OnConnectClicked()
{
// Connect to an EVM wallet such as MetaMask
var walletProviderData = new WalletProviderData { WalletType = WalletType.WALLETCONNECT };
try
{
var result = await TezosAPI.ConnectWallet(walletProviderData);
_infoText.text = result.WalletAddress;
}
catch (WalletConnectionRejected e)
{
_infoText.text = "Wallet connection rejected";
Debug.LogError($"Wallet connection rejected. {e.Message}\n{e.StackTrace}");
}
catch (Exception e)
{
Debug.LogException(e);
}
}
private async void OnDisconnectClicked()
{
// Disconnect the currently connected wallet
try
{
var result = await TezosAPI.Disconnect();
_infoText.text = "Disconnected";
}
catch (Exception e)
{
Debug.LogException(e);
}
}
}
```
This code includes:
* Objects that represent the buttons and a text field to show information on the screen
* An `Awake()` (or `Start()`) method that waits for the `TezosAPI.WaitUntilSDKInitialized()` method to complete, which indicates that the SDK is ready
* A check to see if a wallet is already connected, because octez.connect can automatically remember previously connected wallets
* Listeners to run when users click the buttons, in this case a connect button and a disconnect button
5. On the component that represents your script, drag the connection buttons and text information field to bind them to the objects in your script, as in this image:
6. Play the scene.
7. When the scene loads, click the connection button.
The application shows a WalletConnect popup window with an option to open compatible wallet apps or show a QR code.
8. In your Tezos wallet, scan the QR code and connect to the application.
## Connecting to social wallets
Social wallets exist as federated identity accounts managed by web apps such as [Kukai](https://kukai.app/).
To connect to a social wallet, the Unity application calls
To connect to a social wallet, the Unity WebGL application calls `Wallet.Connect()` with the `walletProvider` parameter set to `WalletProviderType.kukai`.
Follow these steps to connect the application to social wallets:
1. For testing purposes, set up a local social login server.
This server acts as the federated identity server that manages user accounts.
1. Run the example server at https://github.com/trilitech/social-login-web-client.
2. Open the server in a web browser at http://localhost:3000.
3. Use the Kukai log in window to log in to a social account:
4. In the browser console, search for the phrase `OPENING DEEPLINK` and copy the URL for the deep link, which starts with `unitydl001://kukai-embed/`.
2. Configure the test script for social logins:
1. In the Unity application, add a script named `DeepLinkTester.cs` with this code:
```csharp
using System.Reflection;
using UnityEngine;
namespace Samples.RefactorExample
{
public class DeepLinkTester : MonoBehaviour
{
public string deepLinkURL = "";
[ContextMenu("Trigger Deep Link")]
public void SimulateDeepLinkActivation()
{
// Use reflection to invoke the internal InvokeDeepLinkActivated method
var methodInfo = typeof(Application).GetMethod("InvokeDeepLinkActivated", BindingFlags.NonPublic | BindingFlags.Static);
methodInfo?.Invoke(null, new object[]
{
deepLinkURL
});
}
}
}
```
2. Add the script to the canvas, open it, and add the URI in the **Deep Link URL** field:
3. In the Unity application, call the `TezosAPI.SocialLogIn()` method and passes the Kukai wallet type:
```csharp
try
{
SocialProviderData socialProviderData = new SocialProviderData { SocialLoginType = SocialLoginType.Kukai };
var result = await TezosAPI.SocialLogIn(socialProviderData);
_infoText.text = result.WalletAddress;
Debug.Log(result.WalletAddress);
}
catch (SocialLogInFailed e)
{
_infoText.text = "Social login rejected";
Debug.LogError($"Social login rejected. {e.Message}\n{e.StackTrace}");
}
catch (Exception e)
{
Debug.LogException(e);
}
```
4. Bind the code that uses `TezosAPI.SocialLogIn()` to a button.
5. Test the application by running it:
1. Run the application.
2. Click the button that triggers the `TezosAPI.SocialLogIn()` code.
3. In the `DeepLinkTester.cs` script, click the properties and then click **Trigger Deep Link**:
6. The deep link provides the connection information to the SDK and the call to `TezosAPI.SocialLogIn()` resolves with the wallet connection.
When you are ready to deploy the Unity app to production, you must run a social login server and make the application use it:
1. Run the social login server using the example at https://github.com/trilitech/social-login-web-client.
2. In the `Assets/Tezos/Resources/TezosConfig.asset` object, in the **Kukai Web Client Address** field, add the URL of your social login server to use.
This is a server that you run tp handle authentication for your application.
For an example, see https://github.com/trilitech/social-login-web-client.
Now when the app is deployed it sends users to your server to log in and the server returns a deep link to the app.
## Checking the connection type
To verify that the application is connected to a wallet, use one of these methods:
* `TezosAPI.IsConnected()`: Returns true if any kind of wallet is connected to the application and false if not.
* `TezosAPI.IsWalletConnected()`: Returns true if a octez.connect or WalletConnect wallet is connected.
* `TezosAPI.IsSocialLoggedIn()`: Returns true if a social wallet is connected.
To distinguish between octez.connect and WalletConnect wallets, use `TezosAPI.GetWalletConnectionData()`.
This method returns a `WalletProviderData` object that includes information about the connected wallet and account.
Its `WalletType` field is `WalletType.BEACON` for octez.connect wallets and `WalletType.WALLETCONNECT` for WalletConnect wallets.
## Disconnecting
It's important to provide a disconnect button so the user can disconnect when they are finished with the application or if they want to connect with a different account.
To disconnect the active wallet, call the `Wallet.Disconnect()` method.
This method triggers the `WalletDisconnected` event and removes the connection from the wallet app.
For octez.connect connections, it removes the connection from the persistent memory.
# Calling contracts with the Unity SDK
Smart contracts are backend programs that run on blockchains.
Smart contracts can do many tasks, but for gaming they have two main purposes:
* They handle tokens, which are digital assets stored on the blockchain
* They provide backend logic that users can trust because it cannot change
For more information about smart contracts on Tezos, see [Smart contracts](/smart-contracts).
The Unity SDK can call any deployed Tezos or Etherlink contract just like any other Tezos or EVM client can.
* To call a Tezos smart contract, the application must be connected to a octez.connect or social wallet
* To call an Etherlink smart contract, the application must be connected to a WalletConnect wallet
## Calling Tezos contracts
Smart contracts have one or more [entrypoints](/smart-contracts/entrypoints), which are the different ways that it can be called, similar to a method or function in programming languages or an endpoint in an API.
Therefore, to call a Tezos smart contract, you need:
* Its address, which starts with `KT1`
* The entrypoint to call
* The parameter to pass to the entrypoint, which must be in the format that the entrypoint expects
* An amount of tez tokens to send with the transaction, which can be zero or more
To call a contract, make sure that you are connected to a octez.connect wallet.
Then create an `OperationRequest` object with that information and pass it to the `TezosAPI.RequestOperation()` method.
To get the result of the operation, you can await the return value of the `TezosAPI.RequestOperation()` method or use the `TezosAPI.OperationResulted` event.
For example, this code calls a contract and passes the parameter `5` to its `increment` entrypoint.
When the transaction completes successfully, it logs the hash of the transaction.
You can use this hash to look up information about the transaction in a [block explorer](/developing/information/block-explorers).
```csharp
private async void Awake()
{
await TezosAPI.WaitUntilSDKInitialized();
_connectButton.onClick.AddListener(OnConnectClicked);
_disconnectButton.onClick.AddListener(OnDisconnectClicked);
_requestOperationButton.onClick.AddListener(OnRequestOperationClicked);
TezosAPI.OperationResulted += OperationResulted;
}
private async void OnRequestOperationClicked()
{
// Verify that the app is connected to an EVM wallet via WalletConnect
WalletProviderData walletProviderData = TezosAPI.GetWalletConnectionData();
if (walletProviderData.WalletType != WalletType.BEACON && !TezosAPI.IsSocialLoggedIn()) {
Debug.LogError("Connect to a Beacon or social wallet first.");
return;
}
try
{
var request = new OperationRequest
{
// Contract to call
Destination = "KT1TMyoTjpCapy1KEmqPhHo3LLvm79RNjq1Y",
// Entrypoint to call
EntryPoint = "increment",
// Parameter to pass, as a Michelson expression
Arg = new MichelineInt(5).ToJson(),
// Amount of tez to send with the transaction
Amount = "0",
};
var response = await TezosAPI.RequestOperation(request);
Debug.Log("Transaction hash: " + response.TransactionHash);
}
catch (Exception e) when (e is WalletOperationRejected or SocialOperationFailed)
{
Debug.LogError($"Operation failed: {e.Message}");
}
catch (Exception e)
{
Debug.LogError($"Unexpected error during operation: {e.Message}");
}
}
private void OperationResulted(OperationResponse operationResponse)
{
Debug.Log("Transaction hash: " + operationResponse.TransactionHash);
}
```
To pass "Unit" (which means no value, as in the case for entrypoints that do not accept a parameter) to the contract, pass the JSON value `{"prim": "Unit"}`, as in this example:
```csharp
var request = new OperationRequest
{
// Contract to call
Destination = "KT1TMyoTjpCapy1KEmqPhHo3LLvm79RNjq1Y",
// Entrypoint to call
EntryPoint = "reset",
// Pass "Unit" as the parameter
Arg = "{\"prim\":\"Unit\"}",
// Amount of tez to send with the transaction
Amount = "0",
};
var response = await TezosAPI.RequestOperation(request);
```
### Encoding parameters
Tezos entrypoint parameters must be in [Micheline](https://octez.tezos.com/docs/shell/micheline.html) JSON format, which is the format that the Michelson language uses for values.
You can use the [Netezos](https://netezos.dev/) SDK to format Micheline parameters or construct them as JSON strings.
#### Encoding parameters with the Netezos Micheline SDK
Micheline primitives include:
* Integers, as in `new MichelineInt(1)`
* Strings, as in `new MichelineString("Hello")`
* Bytes, as in `new MichelineBytes(bytes")`
As described in [Complex data types](/smart-contracts/data-types/complex-data-types), Micheline values are organized as a series of nested pairs in tree and comb formats.
For example, if an entrypoint accepts an integer, a string, and a series of bytes as a nested pair, you can format the parameter like this:
```csharp
string myStringToBytes = "Hello!";
var bytes = new byte[myStringToBytes.Length];
for (var i = 0; i < myStringToBytes.Length; i++)
{
bytes[i] = (byte)myStringToBytes[i];
}
var parameter = new MichelinePrim
{
Prim = PrimType.Pair,
Args = new List
The equivalent C# types look like these examples:
```csharp
private class ParameterType
{
public string owner;
public int token_id;
}
private class ResponseType
{
public Request request { get; set; }
public string balance { get; set; }
}
public class Request
{
public string owner { get; set; }
public string token_id { get; set; }
}
```
This example shows how to use these types to call the view and receive the response:
```csharp
var parameter = new List
Now you can interact with Etherlink contracts with the Reown SDK.
To call a contract, make sure that you are connected to a WalletConnect wallet.
Then use the `AppKit.Evm.WriteContractAsync()` method to call the contract.
For example, this code calls a contract and passes the parameter `5` to its `set` entrypoint.
When the transaction completes successfully, it logs the hash of the transaction.
You can use this hash to look up information about the transaction in the [Etherlink Mainnet block explorer](https://explorer.etherlink.com/) or the [Etherlink Testnet block explorer](https://testnet.explorer.etherlink.com/).
To set the network that the transaction goes to, see [Changing the RPC node](/unity/quickstart#changing-the-rpc-node).
```csharp
using Reown.AppKit.Unity;
public class MyScripts : MonoBehaviour
{
private async void Awake()
{
await TezosAPI.WaitUntilSDKInitialized();
_connectButton.onClick.AddListener(OnConnectClicked);
_disconnectButton.onClick.AddListener(OnDisconnectClicked);
_requestOperationButton.onClick.AddListener(OnRequestOperationClicked);
TezosAPI.OperationResulted += OperationResulted;
}
private async void OnRequestOperationClicked()
{
// Verify that the app is connected to an EVM wallet via WalletConnect
WalletProviderData walletProviderData = TezosAPI.GetWalletConnectionData();
if (walletProviderData.WalletType != WalletType.WALLETCONNECT) {
Debug.LogError("Connect to a WalletConnect wallet first.");
return;
}
try
{
string contractAddress = "0xfac1791E9db153ef693c68d142Cf11135b8270B9";
string ABI = "[ { \"inputs\": [], \"name\": \"get\", \"outputs\": [ { \"internalType\": \"uint256\", \"name\": \"\", \"type\": \"uint256\" } ], \"stateMutability\": \"view\", \"type\": \"function\" }, { \"inputs\": [ { \"internalType\": \"uint256\", \"name\": \"x\", \"type\": \"uint256\" } ], \"name\": \"set\", \"outputs\": [], \"stateMutability\": \"nonpayable\", \"type\": \"function\" } ]";
string entrypoint = "set";
var result = await AppKit.Evm.WriteContractAsync(contractAddress, ABI, entrypoint, "5");
Debug.Log("Result: " + result);
}
catch (Exception e)
{
Debug.LogError($"Unexpected error during operation: {e.Message}");
}
}
private void OperationResulted(OperationResponse operationResponse)
{
Debug.Log("Transaction hash: " + operationResponse.TransactionHash);
}
}
```
The Tezos Unity SDK supports these Reown SDK methods, but only for calls to Etherlink, not any other EVM chain:
* `AppKit.Evm.ReadContractAsync()`
* `AppKit.Evm.WriteContractAsync()`
* `AppKit.Evm.SendTransactionAsync()`
* `AppKit.Evm.SendRawTransactionAsync()`
For more information about using the Reown SDK, see https://docs.reown.com/appkit/unity/core/usage.
## Calling Etherlink views
Calling an Etherlink view is similar to calling an Etherlink entrypoint.
The main difference is that you use the `AppKit.Evm.ReadContractAsync()` method and that you must set the return type to the appropriate Solidity type that the view returns.
This example calls a view that returns a `uint` integer type:
```csharp
using Reown.AppKit.Unity;
public class MyScripts : MonoBehaviour
{
private async void Awake()
{
await TezosAPI.WaitUntilSDKInitialized();
_connectButton.onClick.AddListener(OnConnectClicked);
_disconnectButton.onClick.AddListener(OnDisconnectClicked);
_callViewButton.onClick.AddListener(OnCallViewClicked);
}
private async void OnCallViewClicked()
{
// Verify that the app is connected to an EVM wallet via WalletConnect
WalletProviderData walletProviderData = TezosAPI.GetWalletConnectionData();
if (walletProviderData.WalletType != WalletType.WALLETCONNECT) {
Debug.LogError("Connect to a WalletConnect wallet first.");
return;
}
try
{
string contractAddress = "0xfac1791E9db153ef693c68d142Cf11135b8270B9";
string ABI = "[ { \"inputs\": [], \"name\": \"get\", \"outputs\": [ { \"internalType\": \"uint256\", \"name\": \"\", \"type\": \"uint256\" } ], \"stateMutability\": \"view\", \"type\": \"function\" }, { \"inputs\": [ { \"internalType\": \"uint256\", \"name\": \"x\", \"type\": \"uint256\" } ], \"name\": \"set\", \"outputs\": [], \"stateMutability\": \"nonpayable\", \"type\": \"function\" } ]";
string entrypoint = "get";
var result = await AppKit.Evm.ReadContractAsync
## Properties
* `Network`: A variable that lets you select which network to use, based on the RPC URLs in the following fields
* `Url Mainnet`: The URL of a Tezos Mainnet RPC node to use
* `Url Testnet`: The URL of a Tezos testnet RPC node to use
* `Documentation URL`: The URL of documentation for the indexer that the SDK uses to provide information about Tezos
* `Request Timeout Seconds`: The time in seconds to wait for a response from the indexer
* `Pinata Api Token`: The Pinata JWT (not the API key or secret key) to use to upload files and data to IPFS
# Documentation style guide
## Overall Tezos-related issues
* Tezos is decentralized.
There is no official Tezos documentation, no official Tezos strategy, and no official entity in charge of Tezos.
However, there can be official documentation for a Tezos-related tool.
* Do not compare Tezos to other specific blockchains.
You can say that Tezos has advantages over other blockchains, but don't say that Tezos is better than or does things differently from another specific blockchain.
* In layer 1 docs, use "tez" to describe the currency instead of "XTZ" unless there is a specific reason to use the ISO code/ticker symbol "XTZ," such as in accounting systems, exchange rates with other currencies, and anything that needs a standardized code.
Beyond these technical reasons, exceptions may be justified by common practice in specific contexts or domains. For instance, it seems mainstream to use XTZ in layer 2 systems such as Etherlink when focusing on the DeFi domain where XTZ is used everywhere, such as in price feed documentation.
* Avoid using the ꜩ glyph in text.
* Do not use the term "initial coin offering (ICO)" or refer to Tezos "investors."
Instead, refer to the Tezos fundraiser.
See https://octez.tezos.com/docs/user/key-management.html#getting-keys-for-fundraiser-accounts.
## Blockchain terminology
* Clients that send transactions to contracts are called "senders."
* The fields in a contract's storage are called "properties."
* Use the full forms "layer 1" and "layer 2" when talking about layers.
The abbreviations "L1" and "L2" (always capitalized) are acceptable later after you have introduced the concept of layers.
## Capitalization
Use sentence case for headings, such as "Connecting to wallets."
Capitalize these terms in text:
* Tezos
* Smart Rollups
* Specific network names such as Mainnet, Shadownet, and Seoulnet
* Data Availability Layer
* Sapling
* JSON
* Web3
Capitalize the "A" in "dApp."
Do not capitalize these terms unless they are the first word in a sentence or if the capitalization style requires all major words to be capitalized:
* tez
* blockchain
* proof of stake
* proof of work
* smart contract
* testnet
## Emphasis
Use emphasis sparingly to avoid making the page too visually busy or complex.
* Use backticks for file names, variable names, and command names, not to emphasize words or denote technical terms
* Use bold for:
* Buttons or links that the user must click or interact with
* Very sparingly, to highlight important words and phrases, such as the words at the beginning of a definition list, such as in the [Glossary](/overview/glossary)
* Do not emphasize the names of web sites, pages, or UI elements that the user sees but does not interact with directly
* Use [admonitions](https://docusaurus.io/docs/markdown-features/admonitions) such as notes or warnings sparingly, only to denote warnings and critical issues
* Avoid parenthetical expressions
## Style and clarity
* Use terms and phrasings that are clear to people using translation or to non-native speakers of English.
* Use gender-neutral terminology.
* Use the same word to represent something, instead of varying words for variety.
For example, use "stake" consistently and do not substitute synonyms such as "deposit" and "retainer" to refer to the same thing.
* Do not use "as" or "since" to mean "because," as in "The system shows an error, as you have not connected your wallet yet."
* Do not use "once" to mean "after," as in "Once the system shuts down, you can safely remove the drive."
* Avoid Latinate abbreviations like e.g. and i.e.
* Provide the information about the target of a link.
For example, instead of saying "for information about smart contracts, click [here](https://docs.tezos.com/smart-contracts)," say "for information about smart contracts, see [Smart contracts](https://docs.tezos.com/smart-contracts)."
When linking to an external site, consider mentioning the target site, as in "for more information, see [Blockchain basics](https://opentezos.com/blockchain-basics) on opentezos.com.
* Do not describe documentation in terms of "chapters" or "articles."
* Avoid meta-phrases that don't add information.
For example, instead of "We will see how you can deploy smart contracts to Tezos by...," say "You can deploy smart contracts to Tezos by..."
* When writing steps that the user must follow, make it clear what the user must do by following these guidelines:
* Make each action that the user does a numbered step.
* Cover the action that the user does in the first sentence.
* Use language that makes it clear that the user must do something and what that action is.
For example, instead of "4. In the file `myFile.js`:", say "4. Add this code to the file `myFile.js`."
* Structure lists and headings in a consistent way.
For example, make sure each list item is capitalized and punctuated in the same way.
List items should be all complete sentences or all sentence fragments, not a mix.
## Links
* Use root-relative links, as in `[Target page](/folder/folder/target)`, because the target path of relative links as in `[Target page](./target)` can change based on whether the user's browser has a trailing slash in the URL.
# Text files
To access the documentation on this site for use with an LLM, download these text files:
* All documentation text: [allPageSourceFiles.txt](https://docs.tezos.com/allPageSourceFiles.txt)
* All tutorial text: [allTutorials.txt](https://docs.tezos.com/allTutorials.txt)