Codestin Search App

Transaction ID	Status	In Block	Type
at17zr3kgnn26zr27tj4fl40d28j7ps5q7cncfwfhhna2sawnvy9ygqefje67	accepted	19,676,282	Execute
at1c2vm6hfknnsaux63u9nc4mjwyttzxt8hf7k2c3suumlack62m5rqsq3x00	accepted	19,676,242	Execute
at1f2kc8zt885lxlvxvjqvvxv2ymtmrx0ngmavaa4nep6yhsuaclgzszqyvda	accepted	19,676,241	Execute
at1v7zzx63h9yayg7hefw76c5fq7u5sgu0n3hxjazcejnu296g5ns9sksm88a	accepted	19,676,178	Execute
at1zqxuqq4enyd7qf2j8rq0sruja0m6nfmkl2z2c7u2ncqjnk9xlcrs646qju	accepted	19,676,176	Execute
at1rsp7ggyq2kfey5vw9sma77mndpu4l42astdyw0y64c8xpdnejvpsjruaf3	accepted	19,676,157	Execute
at1gkfruqkylugtn4l3ds0q777x6hp20wehvsfu0vvn08tjtj72egpqs0juzl	accepted	19,676,137	Execute
at1h5xuncsra3q4dkfxryq28mu53acgdrxy6p3kzpd9x3z6486375zq6ahlck	accepted	19,676,118	Execute
at1cy9n3jnnzg5p54pvct7drcuag2g6zlvy2j8l5r994hl4dedl0vrstqs2e0	accepted	19,676,117	Execute
at1m9zfmzwl7ys08z6t9yjwd98szecp70u44tshh89dglh0cntkrufqsua25m	accepted	19,676,113	Execute

Transaction ID

Status

Program ID

Function

In Block

Type

Age

at17zr3kgnn26zr27tj4fl40d28j7ps5q7cncfwfhhna2sawnvy9ygqefje67

accepted

19,676,282

Execute

at1c2vm6hfknnsaux63u9nc4mjwyttzxt8hf7k2c3suumlack62m5rqsq3x00

accepted

19,676,242

Execute

at1f2kc8zt885lxlvxvjqvvxv2ymtmrx0ngmavaa4nep6yhsuaclgzszqyvda

accepted

19,676,241

Execute

at1v7zzx63h9yayg7hefw76c5fq7u5sgu0n3hxjazcejnu296g5ns9sksm88a

accepted

19,676,178

Execute

at1zqxuqq4enyd7qf2j8rq0sruja0m6nfmkl2z2c7u2ncqjnk9xlcrs646qju

accepted

19,676,176

Execute

at1rsp7ggyq2kfey5vw9sma77mndpu4l42astdyw0y64c8xpdnejvpsjruaf3

accepted

19,676,157

Execute

at1gkfruqkylugtn4l3ds0q777x6hp20wehvsfu0vvn08tjtj72egpqs0juzl

accepted

19,676,137

Execute

at1h5xuncsra3q4dkfxryq28mu53acgdrxy6p3kzpd9x3z6486375zq6ahlck

accepted

19,676,118

Execute

at1cy9n3jnnzg5p54pvct7drcuag2g6zlvy2j8l5r994hl4dedl0vrstqs2e0

accepted

19,676,117

Execute

at1m9zfmzwl7ys08z6t9yjwd98szecp70u44tshh89dglh0cntkrufqsua25m

accepted

19,676,113

Execute

Announcing Aleo Stack v4.6.0

The Aleo maintainers are excited to announce a new version of the Aleo Stack. This update includes changes to the node implementation snarkOS and the high-level programming language Leo - as well as their supporting libraries. This release is one of the largest and most significant upgrades to Aleo since the launch of Mainnet. It introduces three major capabilities: Leo v4.0.0: a complete overhaul of the Leo language, unifying five function-like constructs into a single fn keyword with explicit execution context modifiers. Interfaces and Dynamic Dispatch: compile-time program contracts and runtime function resolution, enabling standardized interfaces, pluggable architectures, and open composability. Leo Libraries: Reusable packages of types, constants, and functions that are shared across programs and fully inlined at compile time Onchain SNARK Verification: new snark.verify and snark.verify.batch opcodes that allow programs to verify Varuna proofs directly onchain. If you want to try it out, you can build from source today or download the mainnet release from Github March 30th. Find the current release schedule at:https://aleo.org/roadmap. Consensus Upgrade: V14 The release schedule and upgrade block heights for v4.6.0 can be found here: https://roadmap.aleo.org/ ATTENTION: Validators and clients that do not upgrade in time will be at risk of forking and require manual intervention to recover. Leo v4.0.0 Leo v4.0.0 is a ground-up rethinking of how Leo programs are written. The previous version of Leo required developers to choose between five distinct function-like constructs — transition, function, inline, async transition, and async function — each with different semantics, calling restrictions, and execution contexts. This release replaces all of them with a single fn keyword. Unified fn Syntax All functions now use fn. Where a function executes depends on two things: whether it is inside a program block (making it an entry point), and whether it uses the final modifier (marking it for onchain execution during finalization). Previous Syntax New Syntax Location transition fn Inside program block function fn Outside program block inline fn (compiler decides) Outside program block async transition fn returning Final Inside program block async function final fn or final { } block Outside program block Future Final Type name .await() .run() Execution operator Before (Leo v3.x): program token.aleo { mapping balances: address => u64; async transition transfer(to: address, amount: u64) -> Future { return finalize_transfer(to, amount); } async function finalize_transfer(to: address, amount: u64) { let current: u64 = balances.get_or_use(to, 0u64); balances.set(to, current + amount); } } After (Leo v4.0.0): final fn update_balance(to: address, amount: u64) { let current: u64 = balances.get_or_use(to, 0u64); balances.set(to, current + amount); } program token.aleo { mapping balances: address => u64; fn transfer(to: address, amount: u64) -> Final { return final { update_balance(to, amount); }; } } The program block now clearly defines the program's public interface — only entry points, record declarations, and storage live inside it. Helper functions and type declarations are placed outside. The final keyword explicitly marks functions and blocks that execute on-chain during finalization, replacing the overloaded async terminology. The result is that the distinction between private ZK proof execution and public onchain finalization is visible at a glance. Automatic Optimization The compiler now makes inlining decisions automatically. Functions called only once are auto-inlined, and functions never called are eliminated. Developers no longer need to choose between function and inline — the compiler handles it. A @no_inline annotation is available for cases where you want to prevent inlining of a specific function. Migration Only the new syntax will be supported going forward from this release. Programs written with transition, function, inline, and async will continue to compile identically. We recommend migrating to the new syntax for all new code. Deprecation warnings for the old syntax will be introduced in a future release. For detailed migration guidance, refer to the Leo documentation. Interfaces Interfaces introduce compile-time contracts for Leo programs. An interface declares what a program must provide — entry point function signatures, record types, and mappings — and the compiler verifies that any program claiming to implement the interface actually does. interface ARC20 { record Token { owner: address, balance: u64, .. } fn transfer(input: Token, to: address, amount: u64) -> Token; } program my_token.aleo : ARC20 { record Token { owner: address, balance: u64, memo: field, } fn transfer(input: Token, to: address, amount: u64) -> Token { // ... } } The Token annotation here is a compile-time obligation. If any required member is missing or has the wrong signature, the compiler rejects the program. Composition and Inheritance Interfaces compose using the + operator and support inheritance: interface Transfer { record Token; fn transfer(input: Token, to: address, amount: u64) -> Token; } interface Balances { mapping balances: address => u64; } interface ARC20 : Transfer + Balances {} program my_token.aleo : ARC20 { // Must implement everything from Transfer and Balances } Record Constraints Interfaces can require that a record has certain fields without fully specifying its structure. The .. syntax means "these fields are required; the implementor may add more": interface ARC20 { record Token { owner: address, balance: u64, .. } } This allows programs to extend the record with additional fields (like a memo or created_at timestamp) while still satisfying the interface contract. Dynamic Dispatch Until now, every cross-program call in Leo was static — the target program was hardcoded in source and baked into the circuit. To support a second token, you wrote a second function. To support an arbitrary token, you redeployed or upgraded your program. fn route_transfer_static(to: address, amount: u64) { return token_a.aleo::transfer(to, amount); // Static } Dynamic dispatch changes this. A single function can now route to any program that implements a known interface, with the target resolved at runtime. // Dynamic: any program that implements TokenStandard can be called fn transfer_dynamic(token_program:identifier, to:address, amount:u64) { return TokenStandard@(token_program)::transfer_public(to, amount); } Dynamic Records Dynamic dispatch solves the problem for program logic. Data has the same rigidity problem — if your function accepts a Token record, it must know the record's exact layout at compile time. The new dyn record type removes this limitation. Programs can accept, inspect, and forward records whose structure is determined at runtime: fn route_private_transfer( token_program: field, input: dyn record, to: address, amount: u64 ) -> dyn record { } Field access on dynamic records is verified by Merkle proof inside the circuit. If a field doesn't exist or has the wrong type, the proof fails. Security Model Dynamic dispatch is opt-in and interface-constrained. Static dispatch remains the default. When a program makes a dynamic call, translation proofs automatically verify that records passed across call boundaries are consistent between their static and dynamic representations. The target program, network, and function name are publicly witnessed — private variables influencing the call target are implicitly revealed. Leo Libraries Leo now supports libraries — reusable packages of types, constants, and functions that are shared across programs and fully inlined at compile time. Libraries have no transitions, no mappings, and no onchain footprint. Every struct, constant, and function call is resolved and inlined by the compiler before bytecode is emitted. Creating a Library A library lives in its own package with a lib.leo entry point (created with leo new --lib). It can define constants, structs (including generic ones), and plain fn functions: // lib.leo (package: math) const PRECISION: u32 = 1000u32; struct Vec2 { x: u32, y: u32, } fn dot(a: Vec2, b: Vec2) -> u32 { return a.x * b.x + a.y * b.y; } fn scale::[N: u32](v: Vec2) -> Vec2 { return Vec2 { x: v.x * N, y: v.y * N }; } Declaring the Dependency Add the library to your program's program.json manifest under "dependencies": { "program": "myapp.aleo", "version": "0.1.0", "description": "", "license": "MIT", "dependencies": [ { "name": "math", "location": "local", "path": "../math" } ] } Using the Library All library items are accessed under the library name as a namespace: program physics.aleo { fn kinetic_energy(vx: u32, vy: u32, mass: u32) -> u32 { let v: math::Vec2 = math::Vec2 { x: vx, y: vy }; let v3: math::Vec2 = math::scale::[3u32](v); // const arg resolved at compile time return math::dot(v3, v3) * mass / math::PRECISION; } @noupgrade constructor() {} } The compiler monomorphizes scale::[3u32] into a concrete function, folds PRECISION to 1000u32, and inlines everything. The resulting bytecode contains no trace of math. Key Properties Because libraries are inlined rather than deployed, there are no cross-program call overhead, no ABI boundaries to cross, and generic parameters (array sizes, loop bounds, etc.) are all resolved at compile time — making them the natural home for shared utilities, data structures, and constants. Libraries Programs Compiled to bytecode No — fully inlined Yes Structs (incl. const generic) ✓ ✓ Constants ✓ ✓ Functions (incl. Const generic) fn only All variants Mappings / storage — ✓ Deployed onchain No Yes Onchain SNARK Verification Aleo Stack v4.6.0 introduces snark.verify and snark.verify.batch; new opcodes that verify Varuna proofs directly onchain within the finalize scope of a program. This implements ARC-0008. In Leo, these are available as: program verifier.aleo { fn verify_proof( vk: [u8; 1024], varuna_version: u8, inputs: [field; 16], proof: [u8; 512] ) -> Final { return final { let valid: bool = Snark::verify(vk, varuna_version, inputs, proof); assert(valid); }; } } snark.verify.batch supports batch verification of multiple proofs, with compile-time enforcement of snarkVM limits (max 32 circuits, max 128 total instances). To accommodate the larger data sizes required for verifying keys and proofs, the maximum array size has been increased from 512 to 2,048 elements. This feature enables proof composition, cross-chain verification, and trustless bridging — any external computation that produces a Varuna proof can now be verified natively by an on-chain Aleo program. Improvements for Developers Leo leo fmt — Code Formatter: Leo now ships with a built-in code formatter. Run leo fmt to format all .leo files in a project, or leo fmt --check for CI integration. The formatter wraps lines at 100 characters and is built on a new lossless Rowan-based parser that preserves comments and whitespace. leo abi — ABI Generation: A new leo abi command generates a JSON ABI from compiled .aleo files. The ABI includes struct and record definitions, mapping declarations, and transition signatures with input/output types and modes. leo build now automatically writes an abi.json alongside main.aleo. Faster Testing: leo test now skips proof generation by default, dramatically speeding up test cycles. Opt in to full proof generation with leo test --prove. Group Generator Access: Two new built-ins — Aleo::generator() and Aleo::generator_powers() — expose the network's group generator point to programs. Aleo::generator() returns the generator as a group, and Aleo::generator_powers() returns a [group; 251] array of precomputed powers, enabling in-program address derivation and other elliptic curve operations. External Structs: Programs can now reference structs defined in imported programs. Two structs with the same name and identical member structure are considered equivalent, resolving a common pain point when working with multi-program deployments. Increased Program Limits: Maximum program size has been increased from 100 KB to 512 KB. Maximum transaction size is now 540 KB. Maximum writes per finalize scope increased from 16 to 32. VK Migration (Amendment Deployments): A new deployment type allows updating a program's verifying keys without changing the program edition, owner, or re-running the constructor. This is essential for adding dynamic dispatch support to existing deployed programs. New REST endpoints support querying amendment counts and transaction history. Structured Error Messages: When an instruction fails, error messages now include the failing instruction index and a formatted instruction string, producing stack-trace-like output for nested calls. SDK Dynamic Dispatch: The DynamicRecord and DynamicFuture types have been added to support dynamic dispatch , Utilities: A stringToField()method has been added for converting program names to field elements Privacy and Security: Proving requests for the Delegated Proving Service can now be encrypted. A KeyStore abstraction has been added for persistent key storage across environments. Zeroizing destructors have been added that scrub private key material from WASM memory. MPC (multi-party computation) support has been added for constructing execution requests. WASM Memory: Maximum WASM memory has been raised to ~4 GB. API Endpoints: The API endpoint has migrated from api.explorer.provable.com/v1 to api.provable.com/v2. Improvements for Node Operators Automated Ledger Checkpoints: A new --auto_db_checkpoints=<path> flag enables rolling RocksDB checkpoint-based ledger backups every 1,000 blocks, maintaining up to 5 rolling snapshots. Filesystem Reorganization: Node-specific data (peer lists, proposal cache) now lives in a dedicated node-data directory, separate from the ledger. Use --node-data for custom paths and --auto-migrate-node-data for automatic migration. Dynamic Validator Whitelist: Nodes now maintain a file listing all currently connected validators, updated with every heartbeat. The format is IP-port pairs for easy scripting and firewall integration. New Metrics: Build info (version, git commit, branch) is now exposed as Prometheus gauge metrics. New gauges track total connected validator stake and the combined stake of validators running the same snarkOS SHA, useful during rolling upgrades. Network Stability: TCP socket configuration has been hardened, connection timeouts relaxed (handshake increased from 1s to 3s, high-level from 3s to 5s), and the BFT communication layer refactored from channel-based to direct callbacks, reducing async overhead and improving error propagation. CDN sync performance is improved through unchecked deserialization and threadpool reuse. New REST Endpoints: New routes for historical staking rewards, connected validator queries (/{network}/connections/bft/…), and amendment deployment metadata (/program/{programID}/amendment_count). Looking Ahead Interfaces, dynamic dispatch, and dynamic records provide the language-level machinery for standardized program contracts, runtime polymorphism, and open composability on Aleo — with privacy guarantees the EVM cannot provide and interface enforcement that extends beyond function signatures to records and mappings. The first major consumer of these features is already in progress: ARC-20, Aleo's interoperable token standard. More on that soon. Closing Notes The full changelogs for the referenced releases can be found here: https://github.com/ProvableHQ/snarkVM/compare/v4.5.0...v4.6.0 https://github.com/ProvableHQ/snarkOS/compare/v4.5.0…v4.6.0 https://github.com/ProvableHQ/leo/compare/v3.5.0…v4.0.0 https://github.com/ProvableHQ/sdk/compare/v0.9.16...v0.10.0 If you want to try it out, you can build from source today or download the mainnet release from Github March 30th. Find the current release schedule at:https://aleo.org/roadmap. Please report any issues you might come across! Contributors A big thank you to all the contributors on Github to this snarkOS, snarkVM, Leo, and SDK release! @AleoAlexander @Antonio95 @aripiprazole @awatts73 @d0cd @damons @dgrkotsonis @eranrund @iamalwaysuncomfortable @IGI-111 @JoshuaBatty @kaimast @ljedrz @marshacb @meddle0x53 @mitchmindtree @mohammadfawaz @raychu86 @Roee-87 @shaaibu7 @tcrypt25519 @tenequm @vicsn

Announcements

Announcing Aleo Stack v4.5.0

Our team is happy to announce a new version of the Aleo Stack! This update includes changes to the node implementation snarkOS and the high-level programming language Leo - as well as their supporting libraries. This release unlocks fast and reliable end-to-end (E2E) testing of Leo programs, streamlines operations for validators, and introduces a limit on the total supply of Aleo credits. If you want to try it out, you can build from source today or download the mainnet release from Github February 13th. Find the current release schedule at: https://aleo.org/roadmap . Please report any issues you might come across! Consensus Upgrade: V13 The release schedule is as follows: Canary (validator test network) Release: January 12th Hard fork: ~January 15th (exact block heights) Testnet (developer test network) Release: March 2nd Hard fork: March 7th (block height 14,905,675) Mainnet Release: March 9th Hard fork: March 14th (block height 16,847,884) ATTENTION: Validators that do not upgrade in time will be at risk of forking and require manual intervention. Clients that do not upgrade will be at risk of halting until an upgrade occurs. Cap on Total Supply of Aleo Credits With the approval of ARC-0047, the Aleo network has now established a hard cap on the total supply of Aleo Credits at 5,000,000,000 ALEO. The cap will be enforced by halting block rewards and proving rewards at a predetermined block height (based on theoretical maximum issuance). Note that the emission rates of these rewards are not being modified. Instead, both reward streams will terminate at a predetermined block height in the far future. With the current average block rate, we expect this to occur at the conclusion of Q4 2049. Improvements for Developers leo devnode One of the most important points of software engineering is testing. While Leo recently added support for unit tests, a good E2E test suite was missing. Existing solutions require running a small development network with multiple validators and clients - slow, expensive, and clunky. leo devnode is a new tool that creates a local lightweight development client to enable developers to rapidly test and iterate through Aleo program design. leo devnode has two commands: leo devnode start will initiate the development client at localhost:3030 leo devnode advance creates a single block and adds it to the ledger. Optionally, this command takes a value n, which advances the ledger by n blocks. By default, broadcasting a transaction to the devnode will automatically produce a block and advance the ledger. However, passing the --manual-block-create flag at startup will allow users to broadcast multiple transactions to a queue without creating a block. In order to advance the ledger in this scenario, users will need to use the leo devnode advance command. Additionally, a --skip-execution-proof flag has been added for the for leo execute command. This flag will create transactions without generating the corresponding ZK proof, further accelerating the testing process. We have provided some examples of how to use the devnode feature alongside the Javascript/Typescript SDK. Program Edition Handling in Leo Leo now handles editions for local and remote programs in a more robust way. As local programs haven't been deployed yet, they do not possess a real onchain edition. We default to edition 1 for certain commands that don’t interact onchain to avoid the check in snarkVM that rejects edition 0 programs without constructors. This keeps local development frictionless. Command Local Programs Network Dependencies leo run Default to edition 1 Fetch edition from network leo execute Default to edition 1 Fetch edition from network leo synthesize Default to edition 1 Fetch edition from network leo deploy N/A Fetch edition from network + V8 constructor check leo upgrade N/A Fetch edition from network + V8 constructor check Additionally if a network dependency is at edition 0 without a constructor, a more verbose error will now be produced with a clear message explaining the program needs to be upgraded onchain. External Structs in Leo This release also introduces an important change to how external structs are handled in Leo. In previous versions of Leo, external structs did not need to be qualified with the program they came from. All imported structs effectively lived in a global namespace. Now, external structs must now be explicitly qualified with the program that defines them. Struct names are no longer globally scoped across imports. For example, given the following program foo.aleo: program foo.aleo; struct Foo { x: u32 } transition main(f: Foo) { .. } Another program (bar.aleo) must qualify struct Foo with foo.aleo in order to use it: import foo.aleo; program bar.aleo; transition main() -> foo.aleo/Foo { return foo.aleo/Foo { x: 42 }; } New --json-output flag in the Leo CLI The Leo CLI now supports a new --json-output flag that writes structured, machine-readable JSON output to disk. This makes it easier to integrate Leo commands into scripts, tooling, and automated workflows. The --json-output flag is available for the following commands: deploy upgrade run execute test query synthesize Save JSON output to the default location: leo deploy --json-output Save JSON output to a custom file path: leo execute main --json-output=my-results.json By default, JSON output files are written to the build/json-outputs/ directory, with one file per command. For example: build/json-outputs/deploy.json build/json-outputs/execute.json build/json-outputs/run.json Changes to snarkos developer execute By default, snarkos developer execute commands will now use the V2 endpoints for api.explorer.provable.com. However, backwards compatibility is still supported for the V1 endpoints. Attempting to use an account with an insufficient balance of credits now produces clearer error messaging. A bug was fixed which prohibited fetching and utilizing the right editions of imported programs. Miscellaneous Updates The size of the compiled program (in kB) will be output by the CLI when calling leo build, leo deploy, and leo upgrade. A --disable-update-check flag has been added to the Leo CLI. This allows for disabling the Leo’s automatic update check, allowing for more consistently reproducible output from the CLI. Various performance improvements have made their way into AleoVM, such as better block caching and better database deserialization. SDK Upgrades to Proving Speed & Proving Key Management 10-20% speedup local wasm-based proving via wasm optimizations made through applying wasm-opt Adds a new KeyStore interface for storing proving and verifying keys on disk for node JS and storing them in IndexedDB for web and wallet applications. This helps developers cache proving keys for later re-use improving wasm proving times a further 30% Miscellaneous Upgrades: Adds support for getting the address of a program from the Program object Improvements for Node Operators Improved Database Organization A new node-data directory has been introduced that contains all node-specific data (essentially everything but the ledger). This is located at ~/.aleo/storage/node-data-{network_id} for production or ./node-data-{network_id}-{dev} for development nodes. Alternatively, users can also pass a value to --node-data and store the data at a custom path. Previously, these files lived in the similarly-named ledger-* folder. At startup, a node will check for any files that indicate that the old storage format is used. In that case, a message is printed on how to migrate, and the node will not start. Alternatively, nodes can also be started with --auto-migrate-node-data to move the appropriate files automatically from the ledger-* folder to the node-data-* folder. Miscellaneous Updates To enhance security, validators will no longer be able to connect to unknown/untrusted peers. This may cause issues for validators who have some managed nodes which frequently rotate. For now, make sure that you pass in peers explicitly via the --peers flag. A discussion is present here for those interested to pass in hostnames. A general UnknownReason type has been added for handling connections between peers. This will now be the default DisconnectReason when encountering an unknown value. This is useful for future compatibility, as adding a new disconnect reason should not require a message version bump or a synchronous update. Nodes will no longer print debug logs when set to the lowest verbosity setting. The amount of stake of unconnected validators is logged and available via the new snarkos_bft_connected_stake_as_percentage metric The latest observed height of other validators is logged to aid debugging. Node restarts are now ~10x faster by cleverly caching the block tree. Good old flamegraphs came to the rescue. Various stability improvements have made their way to make snarkOS nodes ever more robust and to be able to handle a variety of adversarial and benign edge cases in the network, reducing the impact of race conditions in syncing and consensus logic. Closing Notes The work for this release encompassed changes across 500 source code files and touched 20.000+ lines over 350+ commits by the amazing contributors listed below. The full changelogs for the referenced releases can be found here: https://github.com/ProvableHQ/snarkVM/compare/v4.4.0...testnet-v4.5.1 https://github.com/ProvableHQ/snarkOS/compare/v4.4.0…testnet-v4.5.1 https://github.com/ProvableHQ/leo/compare/v3.4.0…testnet-v3.5.0 If you want to try it out, you can build from source today or download the mainnet release from Github February 13th. Find the current release schedule at:https://aleo.org/roadmap. Please report any issues you might come across! Contributors A big thank you to all the contributors on Github to this snarkOS, Leo, SDK and snarkVM release! @AleoAlexander @antonio95 @copilot @d0cd @kaimast @iamalwaysuncomfortable @IGI-111 @ljedrz @meddle0x53 @mohammadfawaz @niklaslong @tenequm @raychu86 @Roee-87 @vicsn

news

Explorethe AleoNetwork

Ecosystem News

Ecosystem News

Want to build cryptographically secure dApps at scale?

Products

Explorethe AleoNetwork

Ecosystem News

Ecosystem News

Want to build cryptographically secure dApps at scale?

Products

Latest Transactions

Announcing Aleo Stack v4.7.0

From Leo to Shield: A Stronger Privacy Wallet on Aleo

Interfaces and Dynamic Dispatch in Leo

Announcing Aleo Stack v4.6.0

Introducing Shield: The Privacy-First Wallet for Aleo

Announcing Aleo Stack v4.5.0

Fuzzing the Aleo VM: Two Approaches to Bulletproof Security

Announcing Aleo Stack v4.4.0

Provable Acquires Leo Wallet with Commitment to Support & Expand Product Offering

Introducing the New and Improved Provable Explorer

Latest Blocks