Bootstrapping native NEAR ecosystem

[evgenykuzyakov]

Bootstrapping native NEAR ecosystem

The goal is to bootstrap native NEAR ecosystem by providing core open-source components.

Background

Currently the majority of blockchain use-cases is speculation. But at the same time it is the best use of the blockchain so far. It happens, because a blockchain is removing the middleman from the ownership of assets. Invention of fungible and non-fungible tokens on Ethereum sparked the innovation that spawned the ICO bubble and currently powering the DeFi bubble.

In Ethereum blockchain atomic transactions with rollbacks and cross-contract composability plays a big role in growing ecosystem, there are some building blocks that powers all of this. These building blocks do not require atomic transactions. These building blocks are:

• fungible tokens
• fungible tokens marketplace
• non-fungible tokens (NFT)
• non-fungible tokens marketplace

Summary

I suggest to develop by NEAR team, open-source and launch the following native projects:

• Fungible token factory. Allows to spawn a new fungible token.
• Fungible tokens exchange like Uniswap. Allows to exchange fungible tokens with native NEAR token and with other fungible tokens. It can follow uniswap v1 pool economics.
• Non-fungible token factory. Allows to create a new non-fungible tokens collection.
• NFT marketplace. Allows to have an auction-like marketplace for NFT tokens.

Developing them internally instead of providing bounties will allows us to deliver them faster and more secure. Current NEAR documentation is still not perfect and there are a lot of small implementation moments that are not well known. So reviewing of the external work may take longer time than developing it in-house. The front-end improvements may be done through bounties later.

I believe these projects will bootstrap native NEAR ecosystem by providing working tools as well as an example for team to launch their projects on NEAR. It has the following benefits:

• Open-source. Anyone can inspect and see the implementations of the contracts and the front-end for each project. Permissive license will allow forking of such projects and adopting for more customized needs.
• Simple. Each project should have the minimum required logic to function.
• Spark Innovation. By providing a uniswap like implementation, it's possible to adapt it to a more complicated pool/fee logic, e.g. balancer-like.
• Enable Monetization. A new project can issue a fungible token and start fundraising. An artist may issue their digital collection. A blockchain-based game can utilize both of the marketplaces for in-game economics.
• Creating Liquidity loops. Marketplaces creates liquidity due to the nature of the arbitrage. If a similar marketplace exists in another place, then an arbitrager or a market-maker can profit from providing liquidity. And liquidity will be beneficial to the regular users of the marketplace.
• More use-cases. By having low transaction fees NEAR lowers the bar for NFT-marketplace prices, which enable more use-cases.

Existing work

There are some existing work:

• FT factory is implemented here: https://github.com/near-examples/token-factory It may need some work to update fungible token contract to the latest standard.
• FT marketplace. Uniswap UI is open-sourced and can be used depending on the license.
• NFT factory. While the NFT factory doesn't exists, we can utilize the FT factory and finish the current NFT standard https://github.com/nearprotocol/NEPs/pull/4

[robert-zaremba]

For FT marketplace we doing it with with the NEARswap protocol, and few other smart-contract planned for NEAR-CLP (for the moment the work is not sustainable, we will need to plan some resources). https://github.com/robert-zaremba/near-clp/

[robert-zaremba]

It's worth noting, that doing a proper Automated Market Making mechanism is not simple. Eliminating Impermanent Losses and building composability is challenging task (more than simple copy-paste). That being said, a basic Uniswap-like protocol is already implemented by NEARswap.

[oysterpack]

@evgenykuzyakov I couldn't agree more ... This is exactly what NEAR needs to deliver on its vision for "Harness the Internet of Value - Now, everything on the internet can take on the properties of money". Bootstrapping is an understatement - I would call it turbo bursting the NEAR ecosystem. Having built in FT and NFT support would truly help NEAR deliver on its mission to be "The Builder’s fastest path to market".

We need to rally the troops and formalize a game plan to get this done.

Developing them internally instead of providing bounties will allows us to deliver them faster and more secure.

Is this on the NEAR team roadmap any time soon? If not, I would suggest the NEAR team to partner with the NEAR community through bounties. The NEP process should produce an SOW artifact with attached bounties.

That being said ... as you know I am working on the STAKE fungible token and I am currently blocked because there is no FT standard. In order for any FT based project to be truly successful, there must be a clearly defined FT standard - and even better for built in FT support as part of the NEAR core platform. After diving deeper into implementing the FT functionality, and getting involved in the NEP-122 vault based FT, I came to the realization that we are falling into the analysis paralysis trap - at least, that's how I feel ...

Thoughts on how do we escape the analysis paralysis trap and move forward from here (brain dump)

• We need to manage this as a professional project in partnership with the community - leverage the bounty program or NEAR foundation sponsored project
• We need a single and consolidated NEP for "the" authoritative FT standard
  • we need to capture all the requirements and use cases - especially for wallets. FT wallet integration needs to be simple, and it also needs to be simple and smooth for the end user from a UX perspective.
  • currently there are multiple NEPs for FT (NEP-21, NEP-122, NEP-110, NEP-136, NEP-102)
• The NEP needs ownership, leadership, and project management to drive it and deliver the product
  • if FT will be part of the NEAR core platform (as core contracts), then the next logical step is to provide built in FT support into the NEAR wallet - just like there is built in support for staking. We need to prove that the FT solution works smoothly with wallets, and building this directly into the NEAR wallet is an excellent showcase.
• We need to build a dedicated and focused project team. If NEAR team does not have the DEV resources to focus on this project, then recruit community members through the bounty program. We need DEV, QA, and UX person resources. Naturally, the community can assist in testing and feedback, but there should be dedicated and focused QA. The FT solution needs to be rock solid and as efficient as possible.
• We need to pull together design sessions and get agreement on a solution design
  • I like the FT factory based solution proposed by NEP-121 but we need to standardize the FT interfaces and transfer protocols.
  • NEP-102 proposes native FT support at the NEAR runtime level - is that a viable solution - but that is more dependent on NEAR core DEV team - where would that fall on the NEAR runtime roadmap?
• We need a project plan and follow an agile process with sprints, milestones, and deliverables. We need a timeline and draw some lines in the sand.