Maxim Afanasyev

We've started work on a new Aether demo based on a AAA shooter. We're targeting 60 FPS with a verifiable economy built into the game. We're keeping the title under wraps for now. We want to show what sits behind a rare weapon. Where did it come from? What earned the player that reward? If it was crafted from resources, you should be able to verify that those resources were spent and the item was created under the game's rules. Ownership is just the starting point. We want players to trace an item's history from creation through trading and use. That's why we're building Aether as a single system for tracking game resources and rewards, with verifiable rules for item creation and consumption. The game engine will handle graphics and physics. Aether will manage the economic state and enforce its rules. We're designing the integration so rendering doesn't wait for the blockchain. In a firefight, you want to aim and move, not deal with transaction confirmations. This shooter will be a testbed for the infrastructure we're developing for studios. We want teams to be able to add a verifiable economy to an existing game while staying focused on game development. That includes trading. A studio's resale fee can be part of the trading rules and collected by the system at settlement. We want the working demo to show how all of this fits into familiar gameplay. That's why we chose a shooter for this test. Which AAA shooter do you think we're using for our next Aether demo? Real games. Deep on-chain economies. Indie budgets. Why pick two?

Let's say your game bans bots. The game next door doesn't. Now imagine players can move items between them. They earn an item in one game and get its equivalent in yours. But if bot farms can churn those items out almost without limits, the supply can explode and prices can collapse. Accept that supply without limits, and you could end up importing the problem. If I want other studios to accept items from my game, I can't just shrug off the bot problem. They need to know what I'm sending into their economies. But we might disagree on the rules. You might allow automated farming. I might ban it. How do we make that work when our games share items? We'd need to agree on what automation is allowed, how we'll spot violations and what penalties apply. If someone breaks your rules to earn an item, should they still be able to take it into my game? Who should be responsible for that: the team building the Web3 engine for all connected games, or each studio running its own game? Real games. Deep on-chain economies. Indie budgets. Why pick two?

Hi everyone! My @aethergamesSOL co-founder @a1th0r and I spent a productive weekend judging the @iDosGamesEngine side track at the international @colosseum hackathon. Tomorrow, Almaty hosts Demo Day, where 40 projects from two side tracks will be presented. See you tomorrow in Almaty! Wishing all participants the best of luck with their presentations! @SuperteamKZ is setting new records!

How do you verify the winner of a game auction when the bids are hidden? We've talked a lot about mining ore and crafting. But blockchain in games goes beyond those mechanics. Trading and auctions raise another question: how do we verify rules and settlement while keeping the right data private? Some designs also need participant anonymity. It depends on what we're hiding, and from whom. Today, let's look at a sealed game auction and privacy tools available on @solana. Imagine an auction for a rare sword. The funded bids are 100, 140 and 160 in-game coins. Under the rules, the highest valid bid wins and the winner pays that amount: 160 coins. Rivals must not see each other's amounts before bidding closes. I'd break this down into three questions. 1. Who can see the bids? Are they hidden only from rivals, or from the operator too? Check related transactions. If a public deposit equals the bid and can be linked to it, encrypting the bid field doesn't keep that amount secret. 2. Which bids count? Only eligible bids accepted before the deadline. Prevent later bid changes and double-spending of reserved funds. Publish tie-breaking rules in advance. 3. How does settlement work? Payment and item transfer must succeed together or neither executes. Release the other bidders' funds. Define cancellation and refund rules for failures. Solana's Confidential Balances extension for Token-2022 encrypts transfer amounts and balances. Account addresses remain public. That's amount confidentiality, not participant anonymity. Processing hidden bids needs a mechanism too. Arcium, for example, lists sealed-bid auctions as a use case for confidential computation. A private transfer alone doesn't determine the winner. The studio still needs auction rules, a way to verify the result and a policy for access to the inputs. The chosen design has its own trust assumptions. These are requirements we're considering as we build Aether. We're building a shared layer to execute economic rules, verify operations and track items and their history. Through common tools and an SDK, we want to help studios implement game mechanics with the data-access boundaries they need. For a sealed auction, privacy, rule verification and settlement need to be designed together. Choose the mechanism to meet those requirements. Who can read your players' bids before the deadline? Real games. Deep on-chain economies. Indie budgets. Why pick two?

Players come to play. Why make them learn blockchain first? Imagine an RPG. Someone wants to explore the world and try combat. If they first need to connect a wallet, buy a token and work out the fees, they still haven't found out whether they enjoy the game. I'd start with the path to the first interesting action. What does it take to enter a fight, earn an item and try it out? Which steps are necessary now, and which can wait? If external trading and withdrawals aren't needed to try the game, their setup can come later. Ownership and withdrawal terms should be clear from the start. Routine gameplay deserves the same attention. If mining or crafting keeps sending players to a wallet, I'd rethink how those actions are authorized. Scoped session permissions can help. The system must check each action against the permission's scope and expiry. Players need to understand what they've authorized and how to revoke it. I'd treat item sales, withdrawals and payments separately. Those operations need clear terms and player consent: which item is being transferred, to whom, at what price and with what fees. Permission to mine mustn't quietly become permission to sell the inventory. A cleaner interface depends on how authorization and economic rules are implemented. That's the infrastructure work we want to simplify with Aether. We're building a shared layer for executing and verifying economic rules, recording items and their transaction history. Through an SDK, we want to help studios connect this layer to gameplay. The studio decides how players get started and which actions are available in a session. We want to take on the common infrastructure work so each team doesn't have to assemble that layer from scratch. I'd look at how many players reach the first battle and how many return to play again. Wallet connections alone don't answer those questions. Walk through your game as a new player and count the steps between launch and the first interesting action. Real games. Deep on-chain economies. Indie budgets. Why pick two?

Your game's quality matters more than the L1 or L2 behind its token. Building a game strategy around where to launch a token gets the priorities wrong. Expecting that choice to make the game successful puts infrastructure ahead of the product. I'd start with a playable RPG prototype and people who enjoy the genre. Watch a player pick up a sword and learn the timing of an attack. Is the combat satisfying? Do they want to explore beyond the first area? I'd look at where their attention drops and what makes them want another session. Then I'd change the prototype and test it again. Those observations would give me more direction than the network name in a pitch deck. Blockchain has a job: provide the properties the game's economy needs at an acceptable cost. Transaction costs, the required level of verifiability and integration effort should guide the infrastructure choice. A game token needs a clear role too. Activity around its launch doesn't tell you whether people enjoy playing. Game quality comes first. Blockchain and the token should serve the game. That's the division of work we're building Aether around. The studio decides what game to make, how its mechanics work and what rules govern its economy. We're building infrastructure to execute and verify economic rules, track items and record their history. We're developing an SDK and shared operational tools so each team doesn't have to assemble that layer from scratch. Our goal is to give both small indie teams and large studios a common infrastructure layer they can connect to their games and maintain with us. Integration still takes work. We want to make it a clear part of game development, with effort and costs the team can assess. I want a conversation with a studio to start with the game it wants to build and the guarantees its economy needs. Aether's job is to help deliver those guarantees and free up the team's time for the game. Real games. Deep on-chain economies. Indie budgets. Why pick two?

Where does the ore go when players keep mining? Imagine a game where players mine 10,000 ore in a day. Crafting, repairs and upgrades consume 4,000. Another 6,000 ore is added to stock. Every resource grant is valid. Every deduction is correct. If that gap persists without growing demand, the resource may become less valuable to players. I'd start with 3 questions. 1. Where does the resource come from? Mining, quest rewards, compensation grants and recycled materials. Count every source: even a small additional issuance path can change the total supply. 2. Where does it go? Crafting, repairs, upgrades, construction and consumables. For each action, track how much it consumes and why a player would choose it. An ordinary player-to-player transfer changes ownership while preserving the total ore supply. High trading volume alone doesn't show how much ore was consumed. 3. What does the resource become? A 10 ore -> 1 sword recipe reduces ore stock and increases the number of swords. If swords last forever and few players want new ones, the stockpile can build up at the next stage. I'd track materials, item production and subsequent item consumption. Ore recovered from dismantling a sword belongs in the accounting too. A repair should restore gear a player wants to keep using. Other sinks need a purpose in the game too. I'd assess resource spending alongside enjoyment and progression. Target stock levels depend on the audience and its needs. New players and upcoming events can increase demand for materials. Veterans may already have enough. Track issuance and consumption over time and by player group. Recipe and issuance-limit changes also need clear rules: which version applies, when it takes effect and whom it affects. With Aether, we're building infrastructure where resource creation, consumption and transformation into items can be independently checked against the game's rules. With all state changes accounted for, a studio can compare issuance, consumption and stock levels. The game team still has to tune recipes, test demand and measure the effects of changes. I'd begin with one resource and follow it through to the items it creates. Where in that chain is stock growing faster than players' need for it? Real games. Deep on-chain economies. Indie budgets. Why pick two?

Go @lifted_fi!

We're building Aether so verifiable game economies can fit a conventional studio's budget. That means reducing both the infrastructure bill and the engineering work needed to integrate it. Cheap transactions cover only part of the cost. Studios still have to integrate the system, manage data and keep it running. Our design follows 4 principles. 1. Run frequent actions in a dedicated layer. In our design, mining, crafting and item consumption execute in Aether near the game server. Solana handles verification and external settlement. This avoids sending every action as a separate main-chain transaction. Fast player feedback and final confirmation remain distinct steps. 2. Batch the work. We aim to spread publication and verification costs across many actions. Savings depend on the workload and verification mechanism. Each protected state transition still needs to be independently verifiable. Publishing a hash alone doesn't prove the rules were followed. 3. Provide shared infrastructure. We're building an SDK and common tools for rules, economic state and item history, alongside operations and recovery tooling. The studio defines its mechanics and permitted actions. Aether packages the infrastructure into a shared service. The studio still needs to connect valid game inputs to those rules. 4. Start with one complete economic loop. Mine ore -> craft a sword -> consume it. For a 10 ore -> 1 sword recipe, that means validating the mining inputs, including the player's position and resource state. Crafting must consume 10 ore once and create 1 sword. Repeating a request mustn't create a second sword. Later consumption also needs verification. The first integration has a defined scope. A team can test failure recovery and compare costs with its current backend before expanding to other mechanics. The savings need to be measured. We'll compare the full cost of execution, verification, data, integration and operations, including engineering time and recovery from failures. Moving a fee from the player to the studio doesn't make the system cheaper. Our goal is to make verifiable game economies a practical infrastructure service with a clear integration path and transparent costs. Real games. Deep on-chain economies. Indie budgets. Why pick two?

Why hasn't blockchain delivered its gaming revolution? My view: a major barrier is making deep integration affordable to build and operate. A wallet or an NFT can sit beside an otherwise conventional game. Verifying the economy changes the backend's responsibilities. Take 10 ore -> 1 sword. Checking the recipe is one step. You also need valid resource creation, shared accounting and explicit permissions for admin grants. Now 2 players try to mine a node with 1 ore left. Retrying the winning request must still produce only 1 reward. A conventional backend already handles those cases. Deeper integration must also make accepted state changes independently verifiable. A fully verifiable game goes further: every gameplay action needs validated inputs and a valid state transition. Graphics can still render in the client. The studio also needs policies for disconnects, pending actions and rule upgrades. It has to decide when players receive feedback and how rejected actions are handled. Then comes the bill. Execution. Verification or proof generation, depending on the design. Data availability and indexing. Networking, monitoring and incident recovery. Integration work and ongoing maintenance. Cheap transactions cover only part of that cost. A fast demo doesn't tell a studio what the system costs under its actual workload, or how it behaves when data is missing and an operator goes offline. Technical tools already exist. The adoption challenge is turning them into something a conventional studio can ship, afford and maintain. A studio already has a backend. If deeper verification adds cost, the benefits need to justify the extra engineering and operational burden. The team still has to build a game that competes with good indie titles on Steam. I'd sell that studio a defined guarantee, a workable integration path and a full operating budget. A pitch aimed mainly at crypto developers doesn't answer those questions. That's the problem we're working on with Aether. Our goal is to make verifiable game economies practical for teams that can't build a blockchain infrastructure department around their game. I'd start with one complete loop: mining -> crafting -> consumption. Define what is verified, test recovery and measure the full cost against the current backend before expanding. That's how I'd judge progress toward a gaming revolution: what can a studio actually ship and sustain? Real games. Deep on-chain economies. Indie budgets. Why pick two?

Can ownership of game items drive repeat purchases? Consider upgrading an iPhone through trade-in. The previous device's assessed value contributes toward the new one. The buyer pays the difference. The previous purchase helps fund the next. I see a possible cycle for games: sell an old item to another player, add funds, buy the next item. Resale proceeds become part of the budget for the next purchase. For studios, that could mean revenue from new purchases and fees or royalties on secondary trades, where the trading mechanism enforces them. But this needs real demand. Blockchain doesn't guarantee a buyer, price retention or liquidity. Blockchain can help make item issuance, ownership and trading rules independently verifiable. A token can show who holds a sword without proving the ore behind it was legitimately created. I'd want players to verify its origin and know that supply can't bypass the game's rules. Confidence in those rules could make buying feel less risky, especially when players can see a credible path to resale. That is a stronger offer than another promise of a gaming revolution. NFTs and crypto checkout alone leave too much of the economy inside a closed server. I'd start with concrete studio problems: item duplication, unchecked admin grants, opaque supply, restricted transfers and ownership records trapped in one server. The guarantees depend on validated actions and inputs. Ownership records need independent access. Aimbots and continued access to item files or gameplay need separate solutions. Technical tools already exist. I see 2 adoption barriers for conventional studios: 1. Full costs: integration, execution, verification, data, settlement and support. 2. The pitch: explain a game or business benefit to studios, rather than selling mainly to crypto audiences. A studio already pays for a backend. If verifiability adds cost, I'd want its benefits to cover the difference. I'd use good indie games on Steam as the benchmark for gameplay, visuals and usability. A wallet doesn't compensate for a weak game. That's what we're building Aether toward: a focused tool for verifiable economies, at a cost the studio can justify. I'd test one economic loop. Measure integration effort and full operating costs, then see how resale affects repeat purchases, primary sales and net margin. Any claim of multiplying revenue needs evidence. Real games. Deep on-chain economies. Indie budgets. Why pick two?

Imagine Alice's sword #17 is stuck in a trade. Support mints #18. Cancellation then returns #17. 2 usable swords. I'd check authority and caps, bind incident #42 to Alice and #17, and retire #17 with its pending claims when issuing #18. Retrying #42 must not mint again. A signature can't prove the loss. Support judgment remains trusted input. With Aether, we're building toward rules for admin grants too. Real games. Deep on-chain economies. Indie budgets. Why pick two?

We're building Aether around 4 goals for game studios: - Less repeated infrastructure work. - A viable operating budget. - Verifiable item history. - Integration that fits the game. 10 ore -> 1 sword needs a traceable origin and rules for spending ore once. Savings and latency still need measurements. I'd compare one mining -> crafting -> consumption loop with the current backend, including integration effort and full cost. Real games. Deep on-chain economies. Indie budgets. Why pick two?

For @aethergamesSOL, I'd start with 1 loop: mine 10 ore -> craft 1 sword -> consume it. Check the accounting. Replay requests and recover from disconnects. Measure player feedback and verified-state acceptance separately, including p95 under defined load. Count cost per completed loop: execution, verification, data, settlement and ops. Track integration effort too. Compare with the current backend on the same workload. Real games. Deep on-chain economies. Indie budgets. Why pick two?

Hello @JosipVolarevic2 @mattytay. Can we continue developing our project in the same repository we submitted to Colosseum, or is it better to do so in a different repository?

A rare drop can be manipulated even with a valid randomness proof. Imagine Alice's boss defeat #42 has a 1% sword chance. Validate #42, bind its random request to Alice's claim and fix the loot table before drawing; then verify how that request's output maps to her reward. Award once. Retries reuse that result. Timeout recovery mustn't create a fresh draw after a bad roll. For Aether, I'd test that whole path. Real games. Deep on-chain economies. Indie budgets. Why pick two?

1 ore left. Alice and Bob mine it at the same time. Both players pass eligibility checks against the same snapshot. Only 1 reward can be credited. Suppose Alice is first in the defined order: consuming the ore and crediting her inventory must commit together before Bob checks the node again. 0 left. Bob gets nothing. Alice's retry mustn't mint more. For Aether, I'd test ordering too: a valid result alone doesn't prove fair selection. Real games. Deep on-chain economies. Indie budgets. Why pick two?

This is our project for "Coliseum." And it’s not just a hackathon project... This is a new Web3 paradigm for gaming.

Your balance is verified. The operator is offline. Can you withdraw? Imagine 100 deposited tokens, with 20 left in the accepted withdrawable balance. I'd make 3 checks: can a contract release those 20 tokens, can I obtain its required evidence, and is there an enforced fallback without the operator? Pending trades and repeat claims need rules. The deposit must still back the balance. A sword isn't automatically redeemable. Real games. Deep on-chain economies. Indie budgets. Why pick two?

May be should demonstrate our solution? What about one of the popular game on the world like Minecraft? We can? @a1th0r