
Understanding the four Legion Score pillars
What each score represents, how it is calculated, and what it takes to reach the top

Concrete Vaults: the most accessible path to real yield in DeFi
A beginner-friendly introduction to automated DeFi strategies powered by Concrete.

Deploying your first Solidity Contract on Arc Testnet
Deploying your first Solidity Contract on Arc Testnet


Subscribe to Colliseum


Understanding the four Legion Score pillars
What each score represents, how it is calculated, and what it takes to reach the top

Concrete Vaults: the most accessible path to real yield in DeFi
A beginner-friendly introduction to automated DeFi strategies powered by Concrete.

Deploying your first Solidity Contract on Arc Testnet
Deploying your first Solidity Contract on Arc Testnet
<100 subscribers
<100 subscribers
Hello, my name is Heorhii, and in this guide, we’ll explore how to effectively test Leo programs on Aleo. Aleo offers developers various testing approaches that range from local environments to networked test setups. This flexibility enables developers to choose a setup that matches the complexity of their testing requirements, ensuring a robust development workflow. Here’s how you can set up and test Leo programs on Aleo.
1. Local testing without network. Local testing without network interaction provides a straightforward, quick way to validate program logic. This method is especially useful for early-stage testing and debugging without the complexities of network constraints.
Running local tests. To run local tests, navigate to your project directory and execute:
leo run <FUNCTION_ID> <FUNCTION_ARGUMENTS>
This command uses the private key stored in your .env file to simulate the function call, allowing you to quickly test program functionality without network delays or external factors.
Benefits and limitations. Local testing without a network is efficient and provides fast feedback. It effectively tests basic transitions, like record creation and consumption. However, it has limitations:
No async functions: Since there is no active network, async functions can’t be tested.
No mapping state or double-spend protections: Without a network to track states, this setup doesn’t enforce mapping states or double-spending checks.
Local testing works well for simple validation but may fall short for more complex cases where you need network-based validations or asynchronous operations.
2. Local testing with network. For a more realistic testing environment, setting up a Local Development Network (Devnet) allows for isolated network interactions and transaction-based testing. This method validates state transitions and ensures record validation.
Setting up a local Devnet. To set up a local devnet, you’ll need tmux to manage multiple nodes and environments.
macOS: Install via Homebrew:
Ubuntu: Install with apt:
sudo apt update
sudo apt install tmux
Windows: Install via Windows Subsystem for Linux (WSL):
Set up WSL from the Microsoft Store or through the command line.
Open WSL and run:
sudo apt update
sudo apt install tmux
https://learn.microsoft.com/en-us/windows/wsl/install
Running the Devnet environment:
Clone the snarkOS repository if you haven’t already:
git clone https://github.com/AleoHQ/snarkOS
cd snarkOS
Start the devnet by running:
./devnet.sh
Follow the prompts:
Select the number of validators and clients or press Enter for defaults.
Set the network ID or use the default.
Choose "y" to build binaries (first-time setup), otherwise "n" to skip.
Choose "y" to clear ledger history for a clean start, or "n" to retain the previous environment.
Navigating Nodes in tmux:
Move to the next node: Ctrl+b n
Move to the previous node: Ctrl+b p
Find the Validator Node 0 and note its private key. This private key is pre-funded with test Aleo Tokens (AT) for devnet testing.
Use http://localhost:3030 as the API endpoint for all local devnet interactions.
Deploying and testing on Devnet. With the devnet running, you can:
Deploy a program:
Execute transactions:
leo execute
This setup enables a complete testing environment that includes async functions, state transitions, and network-enforced validations like double-spending prevention.
3. Testing with Aleo Testnet. The Aleo Testnet mirrors the mainnet environment closely, making it ideal for production-like testing. Keep in mind that the Testnet assigns unique IDs to each program, so once deployed, you can’t redeploy the same ID.
Setting up Testnet testing. To test on the Aleo Testnet, use REST API calls directed to the following endpoints:
Public API Endpoint: https://api.explorer.provable.com/v1/testnet
Private API Endpoints: Some infrastructure providers may offer private testnet endpoints.
https://api.explorer.provable.com/v1/testnet
Refer to the validator node REST API documentation for additional details on available commands.
https://developer.aleo.org/references/apis/latest_height
More info about this here:
https://developer.aleo.org/guides/leo/testing
Summary. Each testing approach has unique benefits suited for different development stages:
Local Testing without network
Fast and efficient for initial testing
Limited to synchronous functions, with no mapping or state persistence
Local Testing with network
Suitable for comprehensive testing of state transitions and async functions
Enables mapping states and double-spending prevention within a sandboxed network
Testing with Aleo Testnet
Closely mimics mainnet conditions, offering production-grade testing
Program redeployment requires unique IDs for each test iteration
With these options, developers can thoroughly test Leo programs at every stage, ensuring secure and reliable functionality on the Aleo network.
When you're ready to mimic production conditions as closely as possible, the Aleo Testnet becomes essential. By closely resembling mainnet behavior, it offers a reliable environment to assess how your program will perform in a live, decentralized network. Since redeploying programs on the Testnet requires unique IDs for each iteration, it encourages thorough preparation, making it a powerful choice for final-stage testing. This layered approach provides flexibility, allowing developers to test for functionality, security, and reliability at every critical stage of development.
Happy coding!
To know more about Aleo, join now!
Aleo Twitter
Aleo Discord
Aleo Website
List of Aleo and Leo code and resourses
Prepared by Colliseum
Hello, my name is Heorhii, and in this guide, we’ll explore how to effectively test Leo programs on Aleo. Aleo offers developers various testing approaches that range from local environments to networked test setups. This flexibility enables developers to choose a setup that matches the complexity of their testing requirements, ensuring a robust development workflow. Here’s how you can set up and test Leo programs on Aleo.
1. Local testing without network. Local testing without network interaction provides a straightforward, quick way to validate program logic. This method is especially useful for early-stage testing and debugging without the complexities of network constraints.
Running local tests. To run local tests, navigate to your project directory and execute:
leo run <FUNCTION_ID> <FUNCTION_ARGUMENTS>
This command uses the private key stored in your .env file to simulate the function call, allowing you to quickly test program functionality without network delays or external factors.
Benefits and limitations. Local testing without a network is efficient and provides fast feedback. It effectively tests basic transitions, like record creation and consumption. However, it has limitations:
No async functions: Since there is no active network, async functions can’t be tested.
No mapping state or double-spend protections: Without a network to track states, this setup doesn’t enforce mapping states or double-spending checks.
Local testing works well for simple validation but may fall short for more complex cases where you need network-based validations or asynchronous operations.
2. Local testing with network. For a more realistic testing environment, setting up a Local Development Network (Devnet) allows for isolated network interactions and transaction-based testing. This method validates state transitions and ensures record validation.
Setting up a local Devnet. To set up a local devnet, you’ll need tmux to manage multiple nodes and environments.
macOS: Install via Homebrew:
Ubuntu: Install with apt:
sudo apt update
sudo apt install tmux
Windows: Install via Windows Subsystem for Linux (WSL):
Set up WSL from the Microsoft Store or through the command line.
Open WSL and run:
sudo apt update
sudo apt install tmux
https://learn.microsoft.com/en-us/windows/wsl/install
Running the Devnet environment:
Clone the snarkOS repository if you haven’t already:
git clone https://github.com/AleoHQ/snarkOS
cd snarkOS
Start the devnet by running:
./devnet.sh
Follow the prompts:
Select the number of validators and clients or press Enter for defaults.
Set the network ID or use the default.
Choose "y" to build binaries (first-time setup), otherwise "n" to skip.
Choose "y" to clear ledger history for a clean start, or "n" to retain the previous environment.
Navigating Nodes in tmux:
Move to the next node: Ctrl+b n
Move to the previous node: Ctrl+b p
Find the Validator Node 0 and note its private key. This private key is pre-funded with test Aleo Tokens (AT) for devnet testing.
Use http://localhost:3030 as the API endpoint for all local devnet interactions.
Deploying and testing on Devnet. With the devnet running, you can:
Deploy a program:
Execute transactions:
leo execute
This setup enables a complete testing environment that includes async functions, state transitions, and network-enforced validations like double-spending prevention.
3. Testing with Aleo Testnet. The Aleo Testnet mirrors the mainnet environment closely, making it ideal for production-like testing. Keep in mind that the Testnet assigns unique IDs to each program, so once deployed, you can’t redeploy the same ID.
Setting up Testnet testing. To test on the Aleo Testnet, use REST API calls directed to the following endpoints:
Public API Endpoint: https://api.explorer.provable.com/v1/testnet
Private API Endpoints: Some infrastructure providers may offer private testnet endpoints.
https://api.explorer.provable.com/v1/testnet
Refer to the validator node REST API documentation for additional details on available commands.
https://developer.aleo.org/references/apis/latest_height
More info about this here:
https://developer.aleo.org/guides/leo/testing
Summary. Each testing approach has unique benefits suited for different development stages:
Local Testing without network
Fast and efficient for initial testing
Limited to synchronous functions, with no mapping or state persistence
Local Testing with network
Suitable for comprehensive testing of state transitions and async functions
Enables mapping states and double-spending prevention within a sandboxed network
Testing with Aleo Testnet
Closely mimics mainnet conditions, offering production-grade testing
Program redeployment requires unique IDs for each test iteration
With these options, developers can thoroughly test Leo programs at every stage, ensuring secure and reliable functionality on the Aleo network.
When you're ready to mimic production conditions as closely as possible, the Aleo Testnet becomes essential. By closely resembling mainnet behavior, it offers a reliable environment to assess how your program will perform in a live, decentralized network. Since redeploying programs on the Testnet requires unique IDs for each iteration, it encourages thorough preparation, making it a powerful choice for final-stage testing. This layered approach provides flexibility, allowing developers to test for functionality, security, and reliability at every critical stage of development.
Happy coding!
To know more about Aleo, join now!
Aleo Twitter
Aleo Discord
Aleo Website
List of Aleo and Leo code and resourses
Prepared by Colliseum
Share Dialog
Share Dialog
No activity yet