Since launching on Mainnet in July, imbrex has on-boarded users from twenty-nine states, two national firms, and over 13,000 listings! The team has been communicating with our community on a daily basis. We’ve been providing demos, recording user-experience interviews and diligently considering feedback, and experimenting, so that we may provide a better web3 experience for our web2 userbase.
One of our first hurdles was web3 tooling. Why do I need a wallet? What’s a private key? Initially, we responded by defining these terms up front. That was a mistake. Our definitions didn’t resonate. It was just too much information too soon. So, we reversed the flow and introduced unfamiliar web3 features only after a user had received value from them. More on this later in the post. In addition, we’ve begun adopting user web3 definitions over our own.
Next, we saw that users were not interested in paying for gas, period. We addressed this with our Subscription model. The Subscription model led to other challenges like a backlog of gas related transactions. To overcome this, we created the Owner Account Management (OAM) model to, among other things, ensure that transaction processing required to run things, took place smoothly and swiftly.
Last, we found a unique way to scale listing curation using a Token Curated Registries (TCR) called imbrex Listing Curators. Spammy real estate listings are everywhere, undermining buyer experience on consumer-facing platforms nationwide. Real Estate, while being a global opportunity, is essentially a local business, so decentralized design patterns, like TCRs that incentivize independent parties to share their local knowledge (to their and the community’s benefit) seemed like a perfect fit.
We are excited to report, our TCR model is working on a small set of <1,000 users. The team seeded several fake listings among the 13,000 listings currently on imbrex, all of which were flagged and voted down as spam.
Before EthDenver, we will release a detailed review of our TCR model called Listing Curators.
Now, let’s dive into the details of imbrex’s Alpha User Experience (UX) post-mortem….
User challenges centered around:
- Crypto Wallets
Originally, when a user signed up, imbrex provided two options for setting up their wallet:
- Set up a MetaMask wallet
- Import an existing wallet
Not one user chose to import an existing web3 wallet. Some early users successfully installed MetaMask, but the majority didn’t understand MetaMask, nor private keys. Using analytics, we could see users making it to step two of the signup process, then dropping off en masse when getting to MetaMask. Although we love MetaMask, we decided to remove it and add ConsenSys’ eth-lightwallet to the signup process. Now, the user doesn’t have to download a plugin and can generate a wallet natively within imbrex. No third-party install. This increased the number of signups by about 20%. However, we were still losing signups at the generate-wallet step. The message was clear: remove the wallet from signup completely. Originally, we tied the user’s wallet address to their signup ID. In January’s release, the wallet will be triggered only when a user has received value, i.e., has earned IMBREX tokens, either as a Listing Rewards or for participating in the Spam Curation arbitration process.
On imbrex, users are required to pay for gas to process transactions that call the Ethereum blockchain. We explored EIP 865 and relay systems but learned these were mostly theoretical at the time, so we created a custom solution: The Subscription Model. The Subscription model assigned each user a pseudo-contract, using a forward function to pay for gas. Now, users can sign-up with a credit card (via a third-party credit card processor). Imbrex collects fiat and handles gas for transaction processing via smart contracts.
This system came with additional hurdles like nonces getting overridden. Imbrex signs transactions on behalf of our subscribers. To process user transactions, we created five externally owned Ethereum accounts. As more users joined imbrex, transaction nonces from the five externally owned accounts were getting overridden. In addition, Ethereum can only process fourteen transactions per second (for context, Visa processes 40,000 per second). As the Ethereum network gains in popularity, the network only becomes more congested. In addition, there is a +30 second delay from the time a user clicks “submit transaction” to the time the transaction is processed by the Ethereum network. On the current web, this issue does not exist. If a user clicks a submit button and nothing happens, they either refresh the page or continue to hit the submit button. To overcome these challenges, we created a custom queueing system on our backend called the Owner Account Model (OAM). OAM receives transactions from the frontend and processes them through one of 50 owner accounts imbrex controls. Transactions are queued in the backend then cycled through the 50 owner accounts until it finds an address that is not busy processing another transaction. This solved our nonce issue and gave us the flexibility to continue onboarding users. We learned these systems still caused confusion (aka frustration), as users just didn’t understand why they needed to purchase ETH in the first place. Therefore, in January’s release, you’ll see a revised design that takes gas completely out of the user’s experience.
Imbrex (the app) employs the IMBREX token as a rewarding mechanism for contributions of quality listing data to the ecosystem, as well as to incentivize users to curate spam out of the listing feed. We realized during the design phase, that it would be burdensome for users to navigate out to an exchange to obtain IMBREX tokens, then send them to the wallet application in order to engage in commerce. Our solution was to reward users in IMBREX from the Listing Rewards Contract for participating good data. This method has worked well as a good majority of our users have been paid out in IMBREX Listing Rewards. They can use their ETH transactions they purchased via the Subscription model to pay the gas fees, thus being able to participate in spam curation and voting without ever having to leave imbrex’s native application.
Next, we studied existing consumer-facing real estate applications and how efficiently they curate spam. We discovered that approximately 20%-30% of listing data has misinformation or is stale data to one degree or another. Our first method of spam curation is a derivative of Mike Goldin and Ameen Soleimani’s Token Curated Registry (post-mortem on imbrex’s TCR to be released by Stephen soon). We seeded several listings within imbrex’s 13,000 listings. We are happy to report that all of them were flagged, voted on and marked as spam. Although this model requires much more time, users and testing, it appears to be working on a small scale!
Web3 has features such as wallets, gas, and tokens that create friction in the web3 user experience. Dapp developers can create processes like imbrex’s Subscription model to bypass gas but we suggest taking it a step further by exploring token relayers like ERC 865.
This will allow users to obtain value first (tokens) then use these tokens to pay for gas. It will create a much more fluid user experience. Last, we suggest not introducing web3 features like virtual wallets and private keys until it is necessary. Imbrex originally lost 99% of our Facebook advertising conversions at wallet signup. Although ConsenSys’ ethwallet helped, we recommend exploring token relays then only introducing web components when it’s necessary and through creative and playful storytelling. Web3 is the future but in order to scale web2 user adoption, the development community needs to employ methods that make the user experience as seamless as their current web2 landscape.