A Long Awaited NEAR Account Marketplace Has Arrived

A Walkthrough By NEAR’s Alex Kouprin

Introduction

My name is Alex Kouprin, and I’m one of those developers who prefers to stay in the shadows, solving some of the most complex and intriguing problems in the world. As a core engineer, I have been coordinating projects such as NEAR State Sync, Sharding, Garbage Collector, Rainbow Bridge architecture and many others. Entirely consumed by these exciting initiatives, I have not had a chance to build a project on top of NEAR….Until last month.

Today I’m going to tell you a story about how to bring your own project to NEAR MainNet in less than two weeks, and how to get your first payout in NEAR within a few hours after the launch of the said project: It’s straightforward, and a huge efficiency boost for new developers entering the space.

Beginning

NEAR Protocol has multiple selling points that allows it to distinguish and differentiate itself in the blockchain industry — that is what inspired me to get started. Firstly, looking at the extremely talented NEAR engineers like Evgeny Kuzyakov and his “Berry Cards” project, one cannot ignore the top level productivity of the team members. It seems this guy can release projects with the speed of a machine gun! It shouldn’t be too complex, if someone can do it once a month, right? (I’m talking about his series of “Berry” projects, accessible here: https://berryclub.io/)

The next point of differentiation that deeply appealed to me is the leadership model within the team. Thanks to the encouragement and support of the Chain Team, I booked my Fridays for Build-on-NEAR activities easily.

When it comes to the business part, the NEAR account model is absolutely unique because it operates on (human readable) accounts each capable of being a sort of a business in itself. The NEAR account Market Place is a platform to sell and buy accounts. Today users often buy and sell domain names for, sometimes, enormous prices. However, NEAR accounts hold a higher value — they store various types of data inside of them. In this way, domain names are like wrappers of a business, but NEAR accounts are actual businesses.

Development

As an open source enthusiast, I believe in transparency when it comes to writing code. Evgeny’ implemented primitives illustrate how nice and smooth onboarding can be when building on NEAR. When I started with my first fork of Berry Cards, these primitives fueled my motivation enormously to get into the details.

Economics

In the beginning there were several conditions I aimed to fulfill for an Account Marketplace on NEAR.

1. The Marketplace should work under circumstances of small liquidity — I didn’t expect thousands of bids nor tons of buyers at the start.
2. The system should help to enable honest price discovery.
3. Resulting information asymmetry (i.e.acting last minute using maximum available information) should be accounted for.
4. The trading process should be interactive.
5. The duration bid on the market should not be artificially restricted.

The above-mentioned conditions break in the basic sell-buy mechanics and various forms of auctions.

When (some of) these conditions do hold, people often focus on one of the better functioning mechanics and hope for the overall rate of success. Contrary to that, I believe differently: in the real world, if the system tolerates abuse, abuse becomes a norm.

Another important detail lies in the creation of a new relationship form enabled by smart contracts. The traditional role of a human seller is substituted by transferring an account to the Marketplace where a smart contract can ensure its immutability and compliance with the established code of behavior.

This new relational framework consists of the following dynamic roles:

• Founders, who offer accounts to the Marketplace;
• Believers, who bet if the bid is underestimated and will be claimed for higher price;
• Claimers, who want to obtain accounts.

That being said, I think there is no reason to go deeper into economics. For those who are interested in further details on this topic, information can be found here : https://near.bet/#/rules.

Architecture

Smart contracts are at the heart of any NEAR project so I invested in figuring out a scheme that works best on NEAR.

To transfer access to a NEAR account, NEAR offers a flexible access keys approach. For each account, there are two types of keys: Full Access and Function Call keys. Let’s take a look at Full Access keys .

Full Access keys allow us to do any transfers and contract calls, including adding other Full Access keys or deleting existing ones. Whoa. That is exactly what we need to transfer our account using Marketplace keys in the offering phase and then to transfer the account under the key of Claimer in the acquisition phase.

Two remarks need to be mentioned. To be trustful in decentralized terms, the Marketplace should possess no account keys at all. (Otherwise there is no reason to trust — the owner of the key may access accounts ignoring the contract rules.)

Moreover, there must be no access keys from the Marketplace account. (Otherwise there is no reason to trust — the owner of the key has access to the Marketplace and can update the Marketplace contract in any way.)

It is possible to build a Locker contract that spawns an Access Key only once, if and only if called from the Marketplace account. Let’s call this function “unlock”. Unlocking is done unconditionally by cross-contract call from the Marketplace in the acquisition phase.

Here we reached the point where it’s theoretically possible to transfer accounts safely. What should the offering procedures look like?

1. Grant a Full Access key to the offered account.
2. Register the account at the Marketplace.
3. Deploy a Locker contract to the account.
4. Remove all keys from the account.

Now only the Marketplace contract has access to an unlocking function of the account. Let’s look to the acquisition procedure:

1. The User provides its public key.
2. The Marketplace contract ensures that the acquisition conditions are fulfilled.
3. The Marketplace contract calls the unlocking function for the account with the public key provided.
4. The new user unregisters the account from the Marketplace.
5. The new user removes the Locker contract from the account (the user can do that as it already has the key).

Awesome! Let’s build.

Tools

Implementing the economics, I found the Marketplace contract to be heavy and complex. It has more than 30 functions and some of them are far from trivial. They need to be tested properly.

Luckily, the NEAR Blockchain Simulator (near-sdk-sim) has been just included in the latest version of near-sdk.

Look at the example:

Each do_-method is a wrapper to a contract call. This is a perfectly readable and convenient way to write tests. I covered most of the code with 20+ tests written easily.

On the frontend side I’ve used a near-api-js library. Below is an example with the offering procedure, the most complicated part of js code:

As you may see, this code is identical to the explanation given in the section above. There are one-liners like “deployContract” and “getAccessKeys” that make the code very well structured. Simple!

One more very useful tool is the near-cli command “dev-deploy”. It creates a development account on TestNet, fills it with initial balance and deploys the code. This feature literally saved me hours.

Launch

Git says, initial commit has been made on March, 7. The explorer says (https://explorer.near.org/accounts/c.nearbet.near), the Marketplace contract has been deployed to the MainNet on March 20th.

One day before the release, I deployed the code to TestNet and asked people to participate. There were two or three button clicks for the whole day.

Most developers are interested in real projects, not testing things. That is why I’ve decided to launch on MainNet instead of spending time on refining and polishing.

To be honest, I was and I still am afraid to fail stupidly. I’m far from being an expert in smart contracts, and there was no review or audit. The code is fully open and published at GitHub (https://github.com/Kouprin/accounts-marketplace) since its first day — so if there is a bug, you can simply make me feel like an idiot, looking at how the tokens flow away and angry users come to me cursing for losing their accounts.

From my experience, many founders feel the same way and keep postponing their projects for this reason. This is not my personal pain, this pain is shared, and it’s important to be capable of embracing it.

When I finally decided to launch, the project immediately piqued people’s attention.They were asking about economics and contracts; they were offering and betting, claiming accounts. After a couple of hours I have already collected ~10 NEAR tokens in commission on top of the smart contract rewards.

Conclusion

The NEAR Accounts Marketplace has been alive for just over a month. Now there are ~60 accounts offered. The most expensive account costs ~350 NEAR to claim, which is quite incredible!

I’m used to being inside the core team, and developing a smart contract on NEAR is almost a new experience to me. I’m proud that building on NEAR is such an elegant and easy process.

And I’m happy to prove it’s possible to launch on NEAR in under two weeks. :)

The link to the project: https://near.bet

Rules: https://near.bet/#/rules

Source code: https://github.com/Kouprin/accounts-marketplace

Locker contract code: https://github.com/Kouprin/accounts-marketplace/blob/master/lock_unlock_account_contract/src/lib.rs

Marketplace contract code: https://github.com/Kouprin/accounts-marketplace/tree/master/marketplace_contract/src

near-sdk-sim tests: https://github.com/Kouprin/accounts-marketplace/blob/master/marketplace_contract/tests/general.rs

Account where contract is deployed: https://explorer.near.org/accounts/c.nearbet.near