Smart Contract

DNFT is a binary smart contract system. The core contract provides basic security guarantees for all parties interacting with DNFT. Edge contracts interact with one or more core contracts, but they themselves are not part of the core.

Core source code

The core consists of a singleton factory and many pairs, the factory is responsible for creation and indexing. These contracts are very small, even cruel. The rationale for this is that a contract with a smaller surface area is easier to reason about, is less prone to bugs, and is more elegant in function. Perhaps the biggest benefit of this design is that many expected attributes of the system can be asserted directly in the code, leaving almost no room for error. However, one disadvantage is that the core contract is somewhat unfriendly to users. In fact, for most use cases, it is not recommended to directly interact with these contracts. Instead, peripheral contracts should be used.

Factory Reference Document

The universal bytecode held by the factory is responsible for the power supply pair. Its main job is to create one and only one smart contract for each unique token pair. It also contains the logic to open the protocol for charging.

reference document

Reference documents (20th expert review meeting)

The pair has two main purposes: as an automatic market maker and tracking pool token balances. They also publish data that can be used to construct decentralized price oracles.

Edge source code

The periphery is a set of smart contracts designed to support the interaction between a specific field and the core. Due to the unlicensed nature of DNFT, the contracts described below have no privileges and are in fact only a small part of possible peripheral contracts. However, they are useful examples of how to safely and effectively interact with DNFT.

Library reference files

The library provides various convenient functions for obtaining data and pricing.

Router Reference File

The router using this library fully supports all the basic requirements for the front-end to provide transaction and liquidity management functions. It is worth noting that it natively supports multiple pairs of transactions (such as x to y to z), treats ETH as a first-class citizen, and provides meta-transactions to eliminate liquidity.

Design decision

The following sections describe some notable design decisions made in DNFT. Unless you are interested in learning more about how DNFT works, or writing smart contract integration, you can skip these steps!

Send token

Generally, smart contracts that require tokens to perform certain functions require potential interactors to first approve the token contract and then call a function, which in turn calls the transfer From on the token contract. This is not how V2 accepts tokens. On the contrary, at the end of each interaction, at the beginning of the next interaction, the current balance is different from the stored value to determine the number of tokens sent by the current interactor. Saw the white paper to explain why this is the case, but the conclusion is that the token must be transferred to the pair before calling any method that requires a token (an exception to this rule is flash swap).

Weiss is different from DNFT pool, V2 pair does not directly support ETH, so ETH ERC-20 pair must be simulated together with WETH. The motivation behind this choice is to delete the ETH-specific code in the core, resulting in a more streamlined code base. However, by simply wrapping/unfolding ETH on the periphery, the end user can be completely unaware of this implementation detail.

The router fully supports interaction with any WETH pair via ETH.

Minimum liquidity

In order to improve the rounding error and increase the theoretical minimum quotation size provided by liquidity, the first minimum liquidity pool tokens are burned. For the vast majority of pairs, this will represent a negligible value. Combustion occurs automatically during the first liquidity supply, after which the total supply is always more boundary.