Axie Pro is a Web2 data management platform designed to streamline and automate smart contract and blockchain interactions (aka Web3) for the Play-to-Earn game Axie Infinity using that managed data.
Background
Axie Infinity was hot during the middle of 2021. (It’s since cooled off considerably in the 2022 bear market due to market forces and major changes in the game’s structure.) But it was hot. And there was a gold rush to get involved in Axie “scholarships.”
“Scholarships”, or “guilds” as they came to be known (since a player never really “graduates” from a scholarship) are a unique way for an investor to extract value from a competitive online game that uses NFTs – Axie Infinity – using Axie “creatures” as a ticket for participation and rewarding cryptocurrency, in this case SLP, for winning. SLP is an ERC-20 token that has real world value, and can be traded on Centralized and Decentralized Exchanges for Ethereum or other ERC-20 tokens.
Not only was this scenario intriguing from a new Play-to-Earn gamification standpoint that also involved DeFi, GameFi, and traditional gaming mechanics a la Pokémon, this model especially interested me because it offered the opportunity to help people in other parts of the world in proportionally more restricted economic conditions.
Many of my colleagues were getting in the game so to speak, loaning Axies to people in different countries. But they explained how difficult it was to keep track of everything involved and after exploring a little more myself, I saw an opportunity to improve the experience for people who were investing in the Axie Infinity ecosystem using this scholarship model.
Game + Marketplace
Here’s how it works:
- A player in a country with a lower cost of living than the USA could earn a comparatively decent amount money in local wage rates just from SLP awarded from playing the Axie Infinity game
- With individual Axie NTF values skyrocketing, the cost of entry was too high for many people
- An Axie Team could cost anywhere from $200 USD to $1000 USD depending on the NFT’s traits
- Axies with better traits were more likely to win battles but gameplay was still heavily skill based
- A person living in the United States, for example, with capital to invest could buy Axie NFTs and loan them out to a player in another country who could not afford the upfront cost
- The investor can then split the earnings paid out by Axie Infinity with the player usually somewhere around 50/50
The game platform’s design facilitated this model because it made it possible for a player to login with a username and password and use the Axies associated with that account in-game, but not have access to transfer the Axies or sell them because players would not be given the private key to the address the Axie team resides on. This made it safe to spin up user accounts with emails and passwords and provide them to players, because these credentials were distinct and agnostic of the private key of the corresponding Ronin address.
In the usual case, an investor takes all of the risk upfront by purchasing the assets required to play the game and loaning them out to player whom they hope will be good at playing. Interests are aligned in that a player wants to play well so the game awards them as much SLP as possible, and the investor wants to loan the Axie team to a good player so they can also maximize their return. There is usually a screening process involved to vet the player, because if the player simply does not play, then the Axies are sitting around not making revenue. Also, Axie Infinity put in place strict anti-cheat measures that ban Axies from ever generating revenue if a user is detected playing more than 1 account. But the owner need not trust the player to not steal the Axies themselves, because it is not possible to move the ERC-721 assets without the private key to the account. The owner must trust the player to play well, and the player must trust the owner to actually make the payout, but it is in the owner’s best interests to keep good players happy to continue maximizing SLP rewards. Rewards can then be split up and SLP can be traded for ETH using Axie’s own Dex and then moved to Etheruem Mainnet via Ronin Bridge.
This is an attractive model.
But there were some shortcomings. It’s a little more complicated than that….
The Problem(s)
TLDR;
2 Main Problems with the Axie Scholarship Model:
For Owners:
It is extremely cumbersome to manage all Player data in spreadsheets and manually queue and execute all necessary transactions
Players:
As a player, it is difficult to keep track of payments as well as ensure that they are not being cheated or treated unfairly by the Owner
Many Axie investors (Owners) were all about speed, and there’s some wisdom there, but my cost benefit analysis methodology never trades reduced security for speed. Not in the crypto space.
I was always taught: “Not your keys, not your coins,” so now I say: “not your keys, not your NFTs” and with many high profile attacks going around some of which targeted huge Axie guilds where many thousands of Axie NFTs were stolen, I wasn’t willing to take the risk.
I always wanted to secure Axies on a hardware wallet. So I did. But this made operations even more complicated.
Axie Infinity locks up earned SLP for 2 week time periods, so once claimed in the Account dashboard via a Web2 interface facilitated smart contract interaction, it is not possible to claim any SLP for disbursement again for exactly 14 days, down to the minute. When claiming SLP, an owner manually logs into the account, clicks the claim button, and signs a transaction that sends the SLP amount (generated via gameplay) from Sky Mavis to the account’s Ronin Address.
Based on this lockup period, it made sense to have payments sent to players twice per month, usually on the 15th and 30th of a month. Interestingly, by using the Ronin Block Explorer you could see Ronin Network traffic spike on these days every month as all kinds of guild owners would be conducting their payouts at the same time.
The Manual Way
For a few scholarship accounts, this manual login process was fine, but at scale, when managing tens or even hundreds of accounts, this quickly became a nightmare to keep track of in spreadsheets and actually make the accounting happen. It was possible, but the manual nature of the transactions being signed via Trezor plus manually recording each number in the spreadsheet, the biggest issue was not the monotony of it all, after all, the returns were good for a while, but instead, it was the human error that could occur over a several hour period getting blasted in the face with all kinds of numbers.
Once every 2 weeks, you would be bombarded and overwhelmed with numbers, tedious tasks of logging in and logging out of different accounts, signing transactions and then tracking every number accurately in a spreadsheet manually, completing subsequent equations and redundant audits to ensure accuracy of every transaction.
Again, this worked fine for a few accounts, but at scale, these manual tasks became a big issue. One wrong number in the spreadsheet threw everything off. And the whole process took hours. Not just 1 or 2 hours. Somewhere between 8 and 10. And if something went wrong, like a minor accounting error, it took even longer.
Not helping matters, still in a nascent state, the Ronin Network ran through only 1 node and often failed. Sometimes there were issues with the Ronin Wallet Chrome Plugin. So that transaction you thought went through, really didn’t. This had never ever been a big problem on the Bitcoin or Ethereum networks in my experience: the fee was estimated, paid at the same time as the transaction, and I only ever once experienced a transaction stuck in the mempool for a few days before it cleared. Not the case on early Ronin Network. Transactions would fail as much as 40% of the time. Since transactions were manually recorded in a spreadsheet after initiation, this process required a lot of repetitive logging and auditing.
Sometimes the Wallet would even have discrepancies from the block explorer.
That doesn’t instill a lot of confidence for big investors.
But even as the Ronin Network matured, the need for a better way was clear. So I learned in-depth how a scholarship works, and how to manage one, the manual way, then set out to design the a better system for managing it all. And not just for the investor, but for the players too.
What I learned was that a lot of managing a scholarship was managing people. Beyond just throwing money into the Ronin bridge and buying on-meta Axies there was a lot of interaction necessary on Discord. Discord was where investors typically spun up a server to communicate with their loyal team of players, to make sure they all were using the latest strategies, and that everyone was doing what they were supposed to. It became clear that talking with players and keeping tabs on them was important. After all, “scholars” we’re less likely to put in a lot of effort if they weren’t confident in their owner/manager.
There were other early tools that helped keep track of players earnings. Some savvy developers found ways to hook up to Axie API endpoints and display information like a players rank, and their daily SLP earnings. You could copy and paste Ronin addresses for accounts into these tools. But it wasn’t very private and only solved part of the problem. It would be nice to have all this data visible in one place to make better decisions about scholar performance.
Further, it was disturbing to me to hear from scholars themselves about other Owners (investors) mistreating a lot of players. While I totally believe in voluntary contracts, I absolutely do not believe in mistreating people, or making them feel bad in any way while they work for me. While there is little risk involved for a scholar, and more work than you would think for an Investor/Owner to onboard them, it rubbed me the wrong way that other Owners (no one I knew personally) were almost taking advantage of these players. So not only did I want to do my part to treat people kindly and fairly, but I wanted to create a system that could facilitate some transparency. This system would need auditability and clear messages to players so they would know they weren’t being stiffed and everyone: investors, owners, managers and players could feel confident in the financial accounting and that everyone was doing what they were supposed to do. That’s the whole point of public ledgers in crypto right?
Solution
Having the in-depth experience of each manual action of managing a scholarship was instrumental in creating this product.
Knowing each of the metrics users wanted to see, and helping to automate tedious, manual actions required intimate knowledge of the use case and workflow.
For example, Owners would really want to see player performance over time.
Was there improvement?
Did someone suddenly stop playing? (sometimes this happened and they wouldn’t even notify you)
I wanted to build a dashboard that would help users make informed decisions based on data:
- How is each player doing over time?
- Are there any immediate issues that need attention?
- What does an end-to-end process look like for recruiting the best players?
- How can we better organize player information while still respecting their privacy?
- How can we automate payments to avoid human error?
- How can we streamline the complex “trade” process across different accounts?
The answer was what became Axie Pro:
Axie Pro serves 3 kinds of users:
- Guild Owners (investors) who buy Axies to lend to players to play the Axie Infinity game with
- Players who play Axie Infinity using loaned Axies
- Managers (who are also almost always Players themselves) that help operate the guild and coach other players on behalf of a Guild Owner
Sign up:
OAuth for Easy Access
A hallmark of an Axie Guild is it’s management through a Discord server. More informal than Slack, but powerful and customizable, Discord became very popular very fast in the Web3 community, not just for Axies. It’s nearly ubiquitous usage among not just Guilds, but NFT enthusiasts as well, sparked the idea to leverage it’s OAuth flow for authentication. By integrating Discord APIs, we made it easy for users to be onboarded in seconds, with only Owners needing to provide any additional information to get started.
No sign up forms, no new passwords, just a simple sign on, that everyone using the platform will already have immediate access to anyway.
Streamlining Payments
This rough diagram actually shows the manual process of how payments were conducted to give developers an idea what we had to automate:
By following a specific, iterative process, both human errors and system errors were mitigated. It was a complex process but it reduced errors and by batching each step and verifying we could minimize any issues, and if we detected any, solve them.
Every action requires 3 clicks on the Trezor, so eliminating the manual logging in of every account and dealing with the cumbersome Ronin Wallet plugin was a big win.
Concept profile accessible by both player and owner:
This profile page would give the player control over what address their payments were sent to along with a clear audit trail linking to the block explorer for provably fair payouts. And a clear view of their progress and SLP earn over time.
Many scholars requested changes to their Ronin payout address. Sometimes this was because they lost access to their original address. If it wasn’t recorded by the owner properly or in a quick time frame, or maybe they missed the request via discord message, a payout could go to an inaccessible address – essentially throwing money away. This self service option would provide players a way to control their own payout address in the system and make immediate changes. We could also lock the payout addresses an hour before payout time to avoid any potential issues conflicting with last minute changes.
A main page for Axie Pro would be the player Dashboard which would keep track of relevant statistics for each user. Sortable by every column, an owner could get an accurate, daily overview of scholarship performance on a per player level.
This information is essential for catching problems.
For example, sometimes players would abandon accounts. Most people wanted to put in the effort to be good at the game, and obviously it was in their best interest, because the more they won, the more SLP they would be rewarded.
But some people just aren’t good at these kinds of games. So instead of “fessing up” to not being able to play well, they would be embarrassed and not say anything and just stop playing. Meanwhile, those Axies would be sitting around doing nothing, while someone else could have been playing with them and earning SLP…
So this kind of overview of Players shows who is at the top of the pack.
MMR is in game ranking where certain higher brackets receive higher payouts for wins. Total SLP shows how much SLP the player earned to date during the current pay period.
Daily average shows how much a player earns on a daily average. Usually 150 SLP per day was the threshold. More than that, and the player was a good player. Less than that, and the player was not performing well.
The percentage column is what percentage cut of the SLP the player receives. This was customizable on a per player basis since some players would put in extra effort to mentor other players, further improving gameplay across the guild. These “managers” or “helpers” are typically awarded higher percentages.
The Payout Address column with Ronin logo is a quick link to the block explorer to see activity on the user’s payout address. Useful when needing to confirm previous payout transactions on the blockchain.
The Ronin logo next to the account number links out the Marketplace account where the Axie team is visible on a public URL in browser, and all traits and information about the Axies are visible.
The Axie column shows how many Axies a player is currently playing with which is important data because top players would get extra Axies. If you were playing and winning with more Axies on the account, you would gain more SLP. So top players got the privilege of extra Axies on their account.
Payouts are handled on a similar dashboard view.
Displaying mission critical information
It’s quite data dense, but for a first release, this information is the most important for the users to work with in order to see who is eligible for a payout. As discussed above, sometimes players would abandon their account. I would always still pay them, but this kind of dashboard would show if there was a problem by highlighting the row in red indicating the player needed to potentially be replaced.
Links to accounts, amount earned, the breakdown of the player’s cut and the guild’s cut as well as the pay period and daily average round out the stats.
Multiple Hardware Wallets
Before Axie Pro was even in production, there had been a limit of 50 Ronin Addresses per hardware wallet. So Owners with more than 50 accounts would have to use multiple hardware wallets or workarounds involving multiple instances on the same wallet. Either way, that made it tricky to keep track of which accounts were where. So I designed the system to include labeling so users could keep track of which accounts were on which hardware wallets. This information was of course able to be uploaded via CSV file for easy editing and management of the data. Automated tasks are batched by hardware wallet, so no need to switch between batches. When all transactions for users on one hardware wallet are complete, the dashboard prompts to connect the hardware wallet corresponding to the next set and elegantly continues smoothly until all actions are complete. Of course, error handling with an emphasis on automatic retries and clear feedback for the user are included for the best possible user experience.
Can I have a trade?
Additionally, players were constantly requesting trades or updates to their team. Since trying to put together good teams with a high likelihood of winning involved breeding Axies, which was less expensive than buying them but also required some skill in pairing traits that would generate a high likelihood of strong offspring, there was an element of chance to what traits each creature would be “born” with and not all teams ended up being the same.
Sometimes, through gameplay, players would find they needed a specific battle move that their team didn’t have. So they would request a “trade” or a new Axie that had what they believed they needed to win more. Sometimes it was possible to accommodate these requests, and sometimes not. But often, it was important to keep players happy and motivated, so you would want to switch Axies around to accommodate as best you could which involved signing more transactions. Complicated enough on just the software wallet, along with making sure to keep all the Ronin account addresses straight (you don’t want to accidentally send an Axie or 2 to a player’s payout Ronin Address, but to their account address that only you have the private key to) – but even more extra steps involved when using a Trezor hardware wallet too.
I also wanted to address this.
First, we had to confirm this feature would work. So we set up a test page using the web3js API to test if trades were possible programatically. We were able to interact with the Ronin chain by examining some traffic and understanding how Ethereum transactions work since Ronin is a closely related side chain to Ethereum.
One of the most unique features of Axie Pro became the evolution of this trade functionality. Since the product design was based on the expectation that an owner would want to secure their Axies with a hardware wallet because it’s always the safest option, we built that in by default.
The Trades tab let managers (who had specific permissions) queue up trades remotely and save them, so that once a batch was queued up, the owner, in possession of the corresponding hardware wallets, could easily sign the transactions and perform the trades. There’s a lot to manage in an Axie guild, so having managers who are also players have extra permissions to access this tab is a big help.
Managers are usually players with a high level of competence and gameplay expertise who not only enjoy the game, but understand the stats, the gameplay, and enjoy helping others. By having this understanding they recognize how to make teams stronger and give players what they need. So these type of players are ideal for setting up trades, that an owner can later review and execute by signing via the Trezor.
Trades were set up like this:
A known Axie ID would be entered into the field. A picture of the Axie would automatically populate in the Axie column which gives a quick visual indication if we are dealing with the correct Axie. Different types of Axies look very different, so if a number is off, this image of the Axie is a good indicator. Along with this image, the name of the account and an external link to the associated Axie Marketplace account are provided, where all the Axies on the account can be reviewed. Then a drop down of only Owner-approved Ronin addresses will allow selection of options where the Axie can be sent. Although this could have also been an open text field, I viewed this as a potential security risk, where a malicious Manager could add their own address for the trade and an Owner not paying attention could sign their Axies away to addresses outside of their control. There are other ideas around how to solve these issues, but for now, the dropdown only displays addresses imported by the Owner, and only this guild Owner has the option of importing addresses.
Feature Highlight
Another problem that would occur frequently was players changing their Discord names. Since Discord is the primary means of keeping your team of players organized and communicating with everyone, it was the only real interaction you had directly with your players and therefore the entire context around how you knew who someone was. So you would frequently see a person’s discord avatar/profile picture and associate it with their username. However, players would often update their avatars, so you would immediately lose all visual context. And if a player changed their username and avatar at the same time? Forget it. That person might as well be a complete stranger. And when you’re having regular chats with people about their progress, it’s a problem when no one can recognize them, especially for the people running the guild – owners and managers. We implemented rules that if a player wanted to change their username or avatar or both, that they must announce it in a special channel so we knew who they were. But this was difficult to enforce in practice. I wanted a feature in the platform I was designing that would alert owners and managers if someone made a change to their discord profile and give them time to get used to it. Almost like “source control” for Discord usernames and avatars.
So here’s what I came up with:
Discord Change Alert
When a user changes their Discord user name or avatar, or both, an icon appears next to their name. If the user has changed their avatar, the old avatar will be partially visible behind the new one. When hovering over the caution icon, the previous avatar moves into view, and the old discord name becomes visible. This option will remain for at least 3 days and can be cancelled by the owner once they have sufficiently noted the name change thereby giving them a chance to be clearly made aware of the change, and get used it.
Other Unique UI Elements
All of Axie Pro was custom designed, but certain UI elements needed more care than others as they served very specific purposes.
Since the main purpose of Axie Pro is to streamline complex workflows and simplify user journeys, it was important to give users a good visualization of things that were happening in real time.
For example, the payouts process, as outlined in the complex diagram above, involves 3 steps, each of which have to be completed in sequence, on a per account basis, that take some variable amount of time depending on network traffic, and each come with their own points of failure. It is important to keep the user apprised of the status of each of these steps, in a clear visual way.
A further refined version of the status indicator:
Since each of these actions go row by row, iterating over all the players icon changes to indicate status for
Ronin Chain, Ronin Pain 😖 – Testing in Production
Publicly exposed APIs on a “Private” blockchain makes for difficult development. Since the time of writing, Ronin has actually released a public testnet called Saigon. At the time of development though, this was not available.
On the Official Axie Infinity Discord Server, Sky Mavis employees encouraged development of tools like Axie Pro, but very little if any documentation was provided at the time. As developers, we were left to combing through code, inspecting with in-browser dev tools, and scouring smart contracts to learn exactly how the Axie Infinity system was working so we could make similar calls and automate features in Axie Pro. Everything is easier with official docs and clear API access, but unfortunately that is not something Sky Mavis made available at the time.
Where there’s a will there’s a way, but it wasn’t easy.
Axie Infinity has strict anti-cheat controls so if a player is detected using 2 accounts on the same device, and sometimes even the same IP address, not only do the accounts get banned, but so do the Axies. The Axies are still yours, you just can’t play the game with them. (Not very decentralized, but anyway…) This, along with the restriction to only be able to claim every 2 weeks certainly complicated matters. We had some users helping test a few accounts by only gaining a small amount of SLP trying to evade bans, while simply just having to test in production on payout day and make changes on the fly during this time period. If it took too long, we would have to wait another 2 weeks; can’t take too long to deploy fixes because you can’t hold up people’s payments and can’t mess up the accounting.
These restrictions proved to be the most challenging I have ever worked with. Ultimately, we worked around it with a lot of sleepless nights, but only every 2 weeks or so haha. Not the most elegant way to develop a platform, but when your business depends on a third party, it can be a necessary evil. This was a lesson in and of itself, there’s inherent risk depending completely on a third party especially when they are uncooperative – intentional or not. Either way, it was an excellent learning experience that gave me and the developers a ton of insight into how smart contracts work as well as a glimpse into how the Axie Infinity platform was built with interesting design decisions that were clearly made for speed over longevity, which also afforded me the experience to know which concepts to apply and which to avoid when designing my own products.
Branding
Most Axie Pro users fit the young, crypto bro persona, not all but most. And I don’t mean that in a negative way. But young, typically male, tech savvy users attuned to the crypto space, maybe not complete experts, but with enough experience to handle managing these kinds of assets and more advanced DeFi features of using Dexes and Bridges.
What could I call this brand new platform? I wanted to have the name Axie in it, and let users know it was a professional way to manage it.
Axie Pro
Axies have cute designs, so I wanted to keep the playfulness of the Axie platform, while still evoking professionalism with a sense of humor.
At first I drew a really quick sketch of a laser eye 1-color Axie wearing a graduation cap in a fighting stance. But Axies are usually in a 3/4 view and they just don’t look right straight on. Looks more like a marine animal of some kind like a whale or a fishy.
Axies are unrecognizable in a front view since they almost always
appear in 3/4 view throughout official media
So that didn’t work. And then I was thinking what if an Axie was like juiced and muscular, ready to fight and win? The game is a battler after all. So I leaned into to a sort of “gym bro” look, with a backwards hat, an expression like he was flexing and ready to throw down. Some Axies had wings, but I though this Axie needed wings for sure (like “Red Bull gives you wings”) and some cool shades along with some ripped actual human arms (which Axies do not have) but also, wearing a tie to keep it professional – “pro.”
I went through a bunch of iterations, but eventually settled on this guy, along with some alternate logos, toned down to fit more appropriately with the UI in certain areas. I think this appeals to our market perfectly. I’ve gotten a lot of compliments on the logo. Logos can be tough, their a whole job in and of themselves, but I just needed something that was well done and fit our image.
The bold yet precise fonts evoke strength and precision, while the comical Axie instantly reminds users the tone of the game this platform helps manage.
Goals
I wanted to design Axie Pro to be the best place to manage a guild, both for Owners and Players. That includes having the best features, considering the entire “workflow” and having the highest reliability.
In the future, Owners would be able to source new players from a pool of accounts with good reputation, and likewise, Players could seek out the best reviewed, highest paying, and most trustworthy Guilds to play for. These features have already been considered and designed.
Right now, in 2023, the Axie landscape and larger market are not cooperating with enough incentives for many users to even play and extract value from the game. But Axie Pro was designed to be extremely reliably, handle the edge cases, and be the best tool for Owners and Players to manage their interactions with the Axie Infinity Ecosystem, and it will be ready to rock in the next bull market.