A new asset tokenization framework

UDAP Middleware

A platform that provides APIs for blockchain protocols and business

Harvest Wallet

An ERC721 and UDAP Singular style asset wallet


A music marketplace and a music player on your mobile phone


UDAP Decentralized Game Engine


An EVM smart contract framework that provides a standard model of tokenizing non-fungible assets. It contains a definition of contracts for singular item, a wallet for these items, interfaces to other token standards such as ERC20 and ERC721, and primitives for decentralized trading of singular assets.

Our basic asset contract singular and the design

1. A piece of asset is uniquely associated with a smart contract account. The account is the home for the asset. People can easily scan the information about this token through public services like Etherscan.

2. The owner of the Singular token must be another smart contract account, named ISingularWallet. There is no direct way for EOAs to own Singular tokens. This design is largely in the same direction of Ethereum’s account abstraction model (discussion)that might be deployed in a future version of Ethereum.

3. It should support push ownership transfer and pull ownership transfer patterns. In so called one-step transfer, the current owner can pass an offer of the token ownership to the receiver account and the receiver account can choose to accept or reject the offer in the same transaction. In a two-step ownership transfer, however, the current owner reserves the token for the next owner in a transaction. The address of the token is passed to the receiver out-of-band. The receiver issues a separate transaction to accept the offer, once it determines that the offer is in its interest.

4. Operators. The ISingularWallet account can assign operators to help with ownership transfers. Having an operator to manage the asset token on the owner’s behalf is a pattern that has been accepted by some other proposals, such as ERC721 and ERC777. People have found it convenient in handling token trading. The current token owner can appoint an operator for the next ownership change. But setting the operators on the token directly is polluting the token interface.

5. Timelock. When an owner make an offer of ownership to someone else by calling the approveReceiver() function, there is a required argument for expiry time, during which period the receiver can take the ownership at will by invoking accept(…)on the token, which will in turn send a notification to the previous owner for it to any state update it wants, or even chain to another action. A critical design is that the owner cannot change his mind during the offer period. This is essentially a time-lock for the transaction. In contrast, neither ERC20 nor ERC721 or any of their derivatives offers built-in time-locks for ownership trading.

6. Token swapping and token sale is implemented with an intermediate TradeExecutor, which is a stateless contract that deployed at a well-known address and be trusted by Singulars for ownership management.

7. Adapters have been built to wrap tokens in ERC20 and ERC721 as tradable Singulars. This enables building decentralized asset exchange in a very straightforward way.