# Contracts live in their own solution, and releases are rare

> AElf is a C# layer-1 blockchain whose design claim is extensibility through side-chains, and the repository makes that claim concrete in a way most chain projects do not: the node and the contracts are separate Visual Studio solutions, the wire format is protobuf, there is a docker directory, and the default branch is dev while pull requests target dev and releases land on master months apart. The README also promises multi-language support eventually, and today the whole thing is C#.

**AElfProject/AElf** — An AI-enhanced cloud-native layer-1 blockchain network. 

- Repository: https://github.com/AElfProject/AElf
- Website: https://aelf.com/
- Stars: 1,267 · Forks: 259
- Language: C#
- License: MIT
- Published: 2026-09-30 · Updated: 2026-09-30 · Language: en
- Canonical page: https://hysenlabs.com/projects/aelfproject-aelf

## Two solutions, and that is the extensibility claim

The README's case for the project is scalability and extensibility through side-chains and a flexible design, and the claim is that aelf makes it as easy as possible to extend or customise the system by providing tools and frameworks for customising the chains and writing smart contracts. The repository layout is the evidence. There are three solution files, one for the node, one for contracts, and an all-in-one that presumably spans both, and there is a separate contracts targets file, a contract directory, a templates directory and a scripts directory. Putting contracts in their own solution is not cosmetic. It means a chain's contract code compiles and tests independently of the node, it means a node operator can upgrade the client without touching a contract, and it means the contract surface has to be versioned deliberately rather than by accident. That is the difference between a chain that expects to be customised and one that expects to be copied. If you are evaluating on modularity, this is the file to look at before you read a word of the white paper.

## The default branch is dev, and that explains the release dates

The repository's default branch is dev, not master, and the build table tracks both with separate workflow, test and coverage badges. The contributing section then says pull requests should be made against the dev branch, that a non-trivial change should be associated with an issue that was discussed first, that a work in progress pull request should carry a prefix in its title, and that it should include tests. Remove the prefix when it is ready and the core team reviews it. So the shape of the workflow is the standard trunk-based arrangement with a long-lived release branch, and the release numbers make the consequence visible. There are three recent tags: v1.11.0 in September 2024, v1.12.0 in January 2025, and v1.12.1 in September 2026. Twenty months separate the last two. A project that ships a patch release that rarely is not a project that has stopped; it is a project where the branch is active and the release line is conservative, which is a defensible choice for a chain where a release is a consensus-affecting event. It does mean you should read the changelog yourself, because the release notes will not tell you what has changed since the version you last deployed.

## Continuous integration across three operating systems, twice over

The CI story is specific and worth reading, because it is the part that tells you whether this is a working system. The README says the Azure Pipelines CI system makes sure every pull request is built for Windows, Linux and macOS, and that unit tests are run automatically, and that CI passing is a precondition for the pull request being merged as well as approval from the core team. Two preconditions, not one, which is the correct arrangement for consensus code. The repository carries three pipeline definitions, one for the general build, one for publishing to a private feed and one for AppVeyor, plus a build script in Cake form with both a shell and a PowerShell entry point, a shared properties file, a global JSON pinning the SDK, a code coverage runsettings file and a codecov configuration. A benchmark directory and a Better Code Hub configuration sit alongside them, which suggests performance is measured and review is systematic rather than informal. None of this tells you whether the chain is fast. It does tell you that a change that breaks a Linux build does not reach master, which for a project you might run in production is the more important property.

## Stable on NuGet, prereleases on MyGet

Packaging follows the same conservative-release logic. The README carries a NuGet badge for the AElf.OS package and a second badge pointing at a MyGet gallery explicitly labelled as including prereleases, which is the standard arrangement for a .NET project that publishes stable versions publicly and nightly or pre-release builds to a private feed. For a consumer this is the practical fork in the road. If you want the release line, you take the stable package and accept a twenty-month-old patch level. If you want to track current development, you point your package source at the MyGet gallery and accept that a build can change under you without a version bump that tells you so. The repository also carries a nuget configuration file, which is what makes those two feeds work from a clone. The ecosystem table in the README points at three other tools, a JavaScript SDK for application developers, a command line tool for interacting with a node and a wallet, and a smart contract and application template framework, all with documentation links. None of those are in this repository, so evaluating aelf as a platform means reading four projects, not one.

## Protobuf, docker, and the shape of the node

Two directories tell you about the engineering. The protobuf directory, sitting at the root, means the node's interface is defined with protocol buffers, which for a network node is a deliberate choice about a compact binary wire format and a generated client library in every language the project supports. That last clause is the interesting part, because it explains the future multi-language statement: with a protobuf interface, a JavaScript or Rust client is a code generation problem, while a smart contract language is a much larger one. The docker directory means there is a containerised path to running a node, which matters for anyone deploying this rather than reading it. Beyond those, the source directory holds the node itself and the test directory holds what the README describes as a centralised set of unit tests, which is a structure that lets the test project see everything without the projects seeing each other. None of this is exotic, and all of it is the ordinary discipline of a large C# codebase, which is the honest characterisation of what this repository is.

## Three documentation systems in one repository

The file list shows book.json, a docs-sphinx directory, a docs directory and a readthedocs configuration, which means the project carries three documentation arrangements at once. A book configuration points at a Jupyter Book style project that renders notebooks into a book, a sphinx directory is a Python documentation toolchain with its own requirements and its own hosting story, and a plain docs directory is where markdown lives. Read that as an accident of history rather than a plan: documentation accretes, and a project that has existed long enough accumulates two publishing toolchains and a directory of markdown. The user-facing documentation is elsewhere regardless, at the documentation site linked from the README, and the white paper has its own address under the documentation resources. If you are evaluating this project, the documentation site and the white paper are the material to read, and this repository's documentation directories are for contributors. The README's own instruction is direct on the point, that it strongly recommends following the official documentation, which guides you through installing dependencies and running the node.

## The description says AI, the README does not

The repository description calls aelf an AI-enhanced cloud-native layer-1 blockchain network, and the word AI is the only place it appears. The README's own framing is a decentralised cloud computing blockchain network, and it says nothing about artificial intelligence, about machine learning, or about any feature you could point at and evaluate. That gap is worth naming rather than glossing over, because a description field is what a search result shows and what a press release quotes. What the README does commit to is extensibility, side-chains, tools and frameworks for customising chains and writing contracts, and eventually support for several programming languages so developers can use the one they know. That last commitment is also a plan rather than a feature, and it is the one that bounds the project today, since the node, the contract framework, the SDK and the command line tool are all C#. If you are non-C#, the honest reading is that you would be waiting, and the tools you would wait for do not exist yet in a form you can evaluate.

## Against a chain with a mature ecosystem, and against plain cloud infrastructure

Two alternatives, and they are the two anybody in this space weighs. The first is deploying a contract on a chain with an existing ecosystem, which gives you a wallet library, an explorer, a test network, an audit trail of tooling and a developer community, none of which you have to build. The cost is that you do not control the chain, and if your requirement is customisable side-chains or a client in your own language, that platform cannot offer it. AElf's case is strongest exactly there, where the contract and the node are both C# and both yours. The second alternative is not a chain at all. If the goal in the description is decentralised cloud computing, then a conventional cloud with a well-understood runtime, a mature orchestration story and a billing model you can predict will beat a blockchain for almost every workload except the ones where you specifically need a shared, trustless ledger. That is a blunt way to put it, but it is the question the description raises and the README does not answer, and for most teams the answer is that the ledger is the expensive part of the design.

## Conclusion

Adopt AElf if you are a C# shop evaluating a chain whose contract and client code can stay in one language, and if you intend to run your own chain rather than deploy to a shared one. Do not adopt it because of the AI claim in the repository description, because the README never mentions it, and do not adopt it expecting a release every few months, because the last two tags are twenty months apart. Verify four things first: which package feed you want, since stable versions are on NuGet and prereleases are on a MyGet gallery, which branch you build from, since the default is dev and releases are cut on master, whether the contract framework in the separate templates repository gives you what you need, and that a C# toolchain is the only language you need, since the multi-language support is described as something the project will eventually do. The licence is MIT, the last release is v1.12.1 from 2026-09-02, and the last push to the default branch is the same day.

## FAQ

### What is AElf?

A layer-1 blockchain written in C#, aiming at scalability and extensibility through side-chains and a flexible design, with tools and frameworks for customising chains and writing smart contracts. This repository is the code that runs an aelf node, plus a tests folder holding the unit tests.

### What programming language does AElf support?

C# today, for the node, the contract framework and the tooling. The README says the project will eventually support various languages so developers can use the one they are most comfortable with, which is a plan rather than a shipped feature, and the interface is defined with protobuf.

### Where do I get AElf packages?

Stable versions are on NuGet as AElf.OS, and prereleases are on a MyGet gallery. The repository carries a NuGet configuration that wires up both feeds, and there is a docker directory for running a node in a container.

### How does AElf handle pull requests and testing?

Pull requests go against the dev branch, which is the default branch, and should be linked to a previously discussed issue and include tests. Azure Pipelines builds every pull request for Windows, Linux and macOS and runs the unit tests, and CI passing plus core team approval are both required before a merge.

### How often is AElf released?

Not often. The three recent tags are v1.11.0 from 2024-09-30, v1.12.0 from 2025-01-14 and v1.12.1 from 2026-09-02, with the last push to the default dev branch on the same day as the most recent release. Versioning follows Semantic Versioning.

## Sources

- [AElfProject/AElf on GitHub](https://github.com/AElfProject/AElf)
- [License: MIT](https://github.com/AElfProject/AElf/blob/dev/LICENSE)
- [Project website](https://aelf.com/)
- [README](https://github.com/AElfProject/AElf/blob/dev/README.md)
- [Releases](https://github.com/AElfProject/AElf/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/aelfproject-aelf