Ethereum Towers needed its apartments and in-game items to be owned, used and traded. Aetsoft built the digital ownership and asset economy layer, from the contracts to the Game API.
Ethereum Towers needed its apartments
and in-game items to be owned, used and traded
Aetsoft built the digital ownership and asset economy layer, from the contracts to the Game API.
Apartments and in-game items became assets players could own, use and trade, and the game could act on. The Unity game was built by the client's studio partners, and it queries the Game API we built for what a player owns and may do.
- 3,403 apartment NFTs minted on Ethereum mainnet
- Two Aetsoft-authored contracts independently reviewed by Hacken
- 10/10 on the ERC-20 token contract
- 9.9/10 on the NFT staking contract
Ethereum Towers issued its virtual apartments as ERC-721 tokens on Ethereum. 3,403 of a designed 4,388 had been minted when we last read the contract, in September 2026. Between Q4 2021 and Q2 2024, Aetsoft built the digital ownership and asset economy layer that made those tokens usable inside the game. The Unity game and the web portal query it for what a player owns and may do. It covers the apartment ownership contract, an NFT staking contract, wallet-linked accounts, an access and identity model, an asset catalogue, the operator console and the Game API. Apartment ownership is live on Ethereum mainnet. The ERC-1155 item marketplace was built and demonstrated on a Polygon test network. The contracts are public on GitHub.
001
ClientEthereum Worlds Limited, the company behind Ethereum Towers, two 101-storey towers of resident-owned apartments in the Ethereum Worlds game. Aetsoft is listed among its industry partners.
002
ChallengeApartments and items existed as tokens on one side and as game objects on the other, with nothing joining them. The client needed ownership the game could read and act on, an economy built around it, and controls its own staff could operate without a developer.
003
SolutionThe digital ownership and asset economy layer: smart contracts, wallet-linked accounts, an access model, an asset catalogue, the web portal, the operator console and the Game API. Token vesting and staking were integrated from a specialist provider.
004
Aetsoft's roleUX and UI design, software requirements (SRS), software architecture (SAD), backend, the asset and economy layer, and the Game API.
Engagement lead
Artem Kirylin
Commercial Director, Aetsoft Inc
Led the commercial relationship and the product consulting.
The problem
People bought the apartments. Inside the game they were still just rooms
Ethereum Towers issued its apartments as tokens on Ethereum, and 3,403 of a designed 4,388 have been minted. Each one was also a room in a Unity game, and the two had no connection.
The people were a third thing again. Players registered on the web portal with an email address, verified it, and picked a display name. That account knew who somebody was. It did not know what they owned. The chain knew what an address held, and nothing about the person holding it.
So when a player walked up to a door, nothing in the product could answer:
- Is this the owner, a tenant, a guest, or a member of the club that meets here?
- May they walk in, redecorate, or host tonight's event?
- Which items do they hold, and which are already applied to this apartment?
- What has changed since we last looked: a sale, a stake, a tenancy, a new friend?
A token records that an address holds an asset. It says nothing about the person, and a game engine has no way to read it. So an owner could prove the apartment was theirs and still not decorate it, let it, or keep anyone else out.
So when a player walked up to a door, nothing in the product could answer:
- Is this the owner, a tenant, a guest, or a member of the club that meets here?
- May they walk in, redecorate, or host tonight's event?
- Which items do they hold, and which are already applied to this apartment?
- What has changed since we last looked: a sale, a stake, a tenancy, a new friend?
A token records that an address holds an asset. It says nothing about the person, and a game engine has no way to read it. So an owner could prove the apartment was theirs and still not decorate it, let it, or keep anyone else out.
Selling apartments was one line of income. Everything the client planned after it needed ownership the product could act on
- In-game items. Furniture, finishes and wearables bought with the world's token, with spend recycled into a player reward pool. Players have to own an item, apply it to an apartment, and keep it.
- Resale. Apartments and items changing hands, with a fee on each trade. Needs transferable ownership and one record the market and the game both trust.
- Events and clubs. Residents hosting evenings that are public, private or paid, and clubs whose members can enter a particular apartment. Access has to follow who someone is and what they hold.
- Brands. Sponsorship, advertising and retail space inside the towers. A brand pays for a room in a world with verifiable residents.
- Renting. Non-owners taking a short tenancy to get in and take part. The right has to move while the asset stays where it is.
Two cheaper options were available, and both stop short of that list:
- Leave the game as it is. The apartments stay decorative, and the sale is the only income the project ever sees.
- Mint on an existing NFT marketplace and stop there. Apartments do trade on open secondary markets, and that part works: the ownership contract is what makes it possible. What a marketplace cannot do is let a club into an apartment, apply a sofa to a room, or pay out a reward pool. Those need a layer inside the product.
The solution
The digital ownership layer sits between the chain and everything that acts on it
Two token standards had to behave as one product. Apartments are ERC-721, one per room. In-game items are ERC-1155, held in quantity.
Joining them meant a platform that could hold both and tie each to a person, tell the game what that person may do, and let the client's staff change the rules later.
Five parts make up the layer. Two further decisions shaped how it was sourced and how it was proved.
An apartment is never simply owned. In the model it is owned and idle, owned and staked, let to a tenant, opened to friends, or attached to a club. Each state grants a different set of rights, one person can hold several apartments in different states at once, and the states interact.
Two rules do most of the work:
- Staking does not change ownership. Putting an apartment into the staking contract keeps it owned, and keeps its saved layout, name and access settings intact. A sale resets all of them, so the next owner starts clean. Getting this wrong would have meant every staked apartment looked sold.
- A tenancy suspends the owner. In the model, an owner is locked out while their apartment is let, exactly as a landlord is. Renting was removed before release, so the rule was designed and never ran.
We wrote the NFT staking contract. Its job is custody. While an apartment is staked the contract holds the token and blocks an ordinary transfer, so the asset cannot move while the product is treating it as in use. The access rules live in the backend and the data model.
Digital identity: linking a wallet to a player account
A player already had an account from registering with an email address. A wallet attaches to that account as one more credential, so there is no second identity to manage. They connect MetaMask or Coinbase Wallet directly, or any wallet over the WalletConnect protocol.
Everything downstream depends on that link. The account carries the person, the wallet address carries the holdings, and the record joins them: this account, this address, these apartment tokens. The client describes the result on its own site as "a unified identity across the ecosystem".
Standing in the world is then derived. The system reads which apartments the linked wallet holds and sets the player's status from the highest type among them, so a penthouse holder outranks a standard one. Sell the penthouse and the status recalculates from what is left. Nobody maintains a spreadsheet of who is a VIP.
Every check runs against that joined record. When a player tries to enter, build or host, the product resolves the account, the wallet, the apartment token and its current state, and compares them to the apartment's access setting.
Access follows the same logic, in four settings a resident can reason about:
- Private, the default, and the state an apartment returns to whenever control changes hands.
- Friends, for people the resident has added.
- Club, for members of a club attached to the apartment.
- Public.
This is token gating. A wallet proves what someone holds, and a service turns that into a decision the product can act on. Proving the holding is straightforward. The work is keeping that answer current while apartments are sold, staked, let and returned, and serving it fast enough to use at a door.
Names, descriptions and tags that players type are filtered and validated, because a live identity system carries user-generated content and has to behave.
The Game API: how ownership becomes usable inside a game
An NFT does nothing inside a game by itself. A game engine renders rooms and objects and has no way to read a chain. The Game API closes that distance.
It works in four steps:
1. It signs in. It calls the login endpoint and receives a set of tokens, then sends the access token as a bearer token on every protected request.
2. It queries the state it needs: the player's account, the apartments and items that account holds, their current state, and the apartment's access setting.
3. It answers from a shared record kept in step with the contracts, so the state is current without the game touching a chain.
4. The game applies the rules to that state, and reports back what changed: a layout edit, time spent, a task completed.
The value is that ownership becomes a normal product capability. Any client that can call an API can use it, and the blockchain work stays in one place. Nothing about this is specific to games. A checkout, a ticket gate or a members' app would ask the same service the same questions, without knowing a chain was involved.
The build-or-buy
decision, taken line
by line
-
Component
Apartment ownership contract
-
Decision
Build
-
Why
Carries the client's own supply, sale phases and per-wallet rules
02/06
-
Component
NFT staking contract
-
Decision
Build
-
Why
Custody behaviour that renting, access and rewards all depend on
03/06
-
Component
Asset catalogue and operator tools
-
Decision
Build
-
Why
The economy's rules live here and had to be the client's to change
04/06
-
Component
Game API and shared record
-
Decision
Build
-
Why
The integration is the product; nothing off the shelf answers it
05/06
-
Component
Token vesting and staking
-
Decision
Buy
-
Why
A solved problem with an audited provider; integrated as-is
06/06
-
Component
Gasless transactions for players
-
Decision
Evaluate
-
Why
Five approaches assessed, two declined on technical grounds, the rest weighed on custody, fees and running cost
Four mechanisms were designed as one economy, so that assets could move. Each got to a different point
- Transfer and resale. Live. Apartments change hands on open secondary markets, which is what the ownership contract exists to allow.
- Staking. Built and audited. Custody sits in the contract. It holds an apartment while the product treats it as in use.
- Renting. Designed in full and built into the staking contract, then removed before release. It did not ship.
- In-game item trading. Built and demonstrated on a Polygon test network, with lazy minting, maker and taker orders and batch airdrop.
Where each asset lives follows from how often it moves. Apartments are valuable and rarely move, so they sit on Ethereum where permanence matters more than fees. Items were designed to behave differently: low value, held in quantity, and expected to move often as players bought and applied them. At that rate, Ethereum fees would have made ordinary play absurd. Items went to a lower-cost chain, and a cross-chain route was designed to move the world's token between the two.
The client's own team runs the economy
Above both chains sits the operator console. The client's team sets sale phases, prices, whitelists, reward parameters and which items are live, without a deployment and without us.
The smart contracts were audited by Hacken before anyone depended on them
Two of the contracts we wrote were reviewed by Hacken, an independent security firm. If a product is going to act on ownership, the record underneath has to be sound enough for someone else to check.
The result we point to first is not the security score. Both reviews scored the functional and technical documentation 10 out of 10, and recorded that the requirements had been provided. We wrote the requirements behind the staking contract and set the tokenomics with the client. Business analysis is the part of this work that usually leaves no evidence a buyer can check. Here an outside firm read it and scored it.
The contract results:
- The token contract: 10 out of 10, no findings.
- The NFT staking contract: 9.9 out of 10, after five of six findings were fixed.
We hold blockchain development to that standard, and crypto wallet development has to sit on it.
Aetsoft delivered this end to end: product and business analysis, the software requirements and system architecture, UX and UI, the backend, the frontend, the smart contracts, the infrastructure and the Game API.
The Game API needed a different working pattern. We designed and built it with the client, then supported the game studio directly. We supplied the documentation, answered their questions, and made the changes their integration needed as it progressed.
Upon the completion of major development milestones, Aetsoft continued with the support and maintenance of the system.
Where this sits in our work on virtual worlds
For Xsolla's XLA Metasites we worked out which markets a virtual platform could realistically win, what enterprise buyers would fund, how the products should work and how they should earn. That engagement was business model and product consulting.
Ethereum Towers is the implementation proof. Here we designed the ownership model and the asset economy for a game, then built and integrated the infrastructure that runs them.
What the work
delivered
Frequently asked questions about Game APIs
-
What is token gating, and how does it actually work?
A person connects a wallet and signs a message to prove they control it. A service then reads what that wallet holds and compares it to a rule you set. The blockchain proves ownership. The service turns it into something a product can use without reading a chain.
-
What does a player really own when a game item becomes an NFT?
A record of ownership that sits on a public chain, outside the company’s database. They can hold it, sell it or prove it without asking permission, and it survives if the product does not. On its own it carries no utility. Whether the item works inside the game, and whether the artwork it points to still loads, depend on infrastructure someone has to keep running.
-
Can tokenized in-game assets be used across different games?
The token can be read by anyone. Using it in a second game is an integration: that game needs the rules and the service to interpret what holding the item means in its world. Interoperability is a product decision, and someone has to build it.
-
We already have customer accounts. Why add a wallet?
An account says who someone is. A wallet says what they hold, lets them prove it to anyone, and lets them take it with them. Add one when ownership needs to be real to the customer and checkable by outsiders such as a brand partner. If it does not, a tiered scheme is cheaper.
-
What did Hacken validate in the Ethereum Towers contracts?
Hacken reviewed two contracts Aetsoft wrote for Ethereum Towers: the ERC-20 token contract and the NFT staking contract. A full audit scores code quality, architecture and documentation as well as security, and checks whether the requirements behind the contract exist and are coherent. Both reviews scored the documentation 10 out of 10, which speaks to the analysis behind the contract as much as the code.
-
Who runs the economy after the build team leaves?
Your team, through an operator console, if someone designs one. Reward rates, prices, sale phases and item availability all change there, without a deployment. If that surface is missing, every economic decision becomes an engineering ticket.
Your product has to act on what a customer owns, on the day they try to use it. Tell us what you want ownership to unlock, and we will tell you what has to be true first.
