🏛️Architecture overview
The core components
Gas Fee Model
Nerv is going to offer several gas fee models for its users in order to provide flexibility as much as possible to adapt miscellaneous marketing strategies of developer's application and remove UX friction for the newcomers.
The gas fee model is configured separately for each Collection or a smart contract. Every Collection and smart contract has a fee model assigned to it, which determines how their transactions are paid, and the developer can choose the fee model that better suits their application. Initially the fee model is configured to a default one and can be updated later as many times it's needed.
Currently there are two models implemented: The default “User paid fees” model when the transaction sender pays all gas fees, and the “Pay as you go” model when collection or smart contract owners enable subsidizing for certain transaction types for their users. The spam protection for this model will play a huge role here.
Spam Protection
Network fees are the important security factor that prohibits malicious players from abusing the network resources, as well as protecting the network from being overwhelmed by good applications. Changing mechanisms of transaction commissions requires special caution.
In case of subsidized fee models, the sender and transaction fee payer may be different entities, which may create an attack surface if spam protection was not in place. Spam protection prevents uncontrolled depletion of sponsor funds. The Network applies rate limits to sponsored transactions.
An NFT token transfer can only be sponsored one time per interval of time. In the case of a smart contract call, the rate limitation is more challenging because the sender or client identification cannot be easily established: The key pairs to send transactions can be generated as easily as generating a short random sequence of bytes (a private key). The transaction subject (like NFT ID) does not generally exist because smart contracts are aimed to express custom application logic. So the second layer of protection is required: White lists.
In order to securely sponsor the smart contract transactions, the application will need to establish a registration procedure, which adds the user's address to a white list. Configuring rate limits is one of the features we are working on, and will be applicable at developer of application's end. This will increase the flexibility of sponsored modes. Also, advanced economic models will be included that will allow the collection and contract owners to provide free transactions in exchange for locking funds.
Nerv APIs
Nerv APIs wrap the logic of Nerv’s exchange engine so that developers do not need to interact directly with smart contracts via custom logic to build on the Nerv platform.
Every interaction, from minting to trading to transferring, is performed via simple API calls. The Nerv APIs contain both the read and write functionality required to build applications without building a backend, meaning Nerv abstracts the complexity of the blockchain to function as a standalone backend.
The read functionality also offers various filtering options. This includes filters that can present a list of all orders submitted by a specific user, or more complete filters like metadata filters. Using the API’s read function we can give developers a list of:
mints
trades
withdrawals & deposits
assets minted
orders (e.g. display all the orders made).
Link UI
The Link is the conduit that we use to connect users to the Nerv protocol. This allows Nerv to support a thriving third-party marketplace ecosystem, without presenting a security risk.
All new Nerv users are required to register as a user, which means setting up a wallet via Link.
Nerv partners can embed the Link directly into their site’s transaction flow, making buying and selling NFTs more efficient and intuitive. The Link screens will show up in the site’s transaction flow, allowing their users to authorize purchases, listings, and transfers of assets and NFTs, all without leaving the page.
Fees Payable with, ETH, BTC, or other Tokens
It's common in the cosmos ecosystem to pay a fee in other tokens like Terra allow fee in UST etc. One of the perks is using the flexible economic models, is the capability to pay fees directly with the Application’s own Fungible token minted within Nerv Chain which is coming soon. Once the exchange rate between Nerv and the application token can be established, the application will be allowed to switch to paying fees with its own token. Combined with Ethereum, Bitcoin, and other bridges, this feature opens the wide range of possibilities to inter-operate between networks, since theoretically any value (not even limited to Fungible tokens, but also Re-Fungible) transferred from other networks, can be used for transaction fee payment.
Nerv SDK
Nerv SDK, combined with the APIs, will allow partners to build NFT projects in hours rather than weeks. designed to make it easy to integrate the protocol into websites. The SDK allows access to the Nerv APIs and wallet.
Shared AssetBook
Nerv has a shared AssetBook. Every asset minted into Nerv is stored in the shared AssetBook. This enables any application on Nerv to view and display the assets of any other application, which helps deliver the best liquidity outcome for all the projects based on Nerv.
For example:
Project A (Marketplace A) mints an NFT (NFT-A) on Nerv.
Project B (Marketplace B) displays NFT-A on its Marketplace.
Project B users see the NFT, incrementally increasing demand for NFT-A.
Project A's primary and secondary sales increase.
Shared orderbook
Nerv has a shared orderbook. Every order submitted to Nerv Protocol is stored and made available to all marketplaces.
Building on Nerv means that you:
Do not need to build, manage or maintain your own orderbook to facilitate trades.
Have access to pools of demand that exist outside of a single marketplace.
Here’s an example:
Project A (marketplace A) lists an NFT (NFT-A) in marketplace A.
Project B (marketplace B) displays NFT-A on marketplace B.
Project B users see the NFT and purchase NFT-A on marketplace B.
NFT-A sale is complete.
In this example, Marketplace A receives their Market-maker fee and Marketplace B receives their market-taker fee on the sale. To summarize, having orders listed on more than one Marketplace means that your orders are more likely to sell faster, or for a greater price if on auction.
Re-fungible and Fungible Modes
Re-fungibility is an important step towards building real life models of ownership rights. Often a unique item may be owned by multiple entities in different proportions. The examples of such shared ownership are abundant: Timeshares, co-ownership of art, fractional car ownership, etc.
For that purpose Nerv provides the special mode of Collection i.e. Re-Fungible in which a token can be minted and then partially transferred to multiple owners. Fungible collection mode is targeted at the same set of use cases as ERC-20 or CW-20 tokens. Any non-unique and divisible resource can be represented as a Fungible token. The examples include non-unique game resources (such as game money), rating points in applications with social networking capabilities, voting tokens, etc.
Metadata
Nerv supports two types of metadata:
Immutable metadata: Set at the time of asset creation, enforced by the proof and available on-chain when an minted NFT is withdrawn for the first time. This is also called the blueprint or minting Blob. This is where applications should store permanent properties, such as IDs or IPFS hashes.
Mutable metadata: Fully controlled by the application, and not recorded on-chain, mutable metadata is most useful for marketplaces to describe assets accurately to users. Every application must register a schema for their collection’s metadata, which specifies the type of metadata
Every application must also expose an API endpoint which Nerv can call after an asset from that collection is minted. We store the metadata returned by this endpoint in our database, and subsequent callers can use these
Last updated