Technical Specifications
Marketplace
Listings
Our listings offer a peer-to-peer method to buy & sell any kind of asset, without the risk of the asset being a scam, because of our built-in verification algorithm that only allows tokenized assets from specific issuers.
Process flow
User connects his Metamask wallet.
User selects the
ListTokenForm
in the menu.User selects the asset he wants to sell by putting in the assets contract address and the preferred token ID.
The user selects a price he wants to list the asset for.
The user either enables or disables financing / mortgages. (meaning buyers are either allowed or not allowed to finance that asset.
The asset is listed.
Tokenized Asset Verification
We have developed a total of 2 methods for verifying if an asset is either a tokenized security or a normal NFT / token:
Whitelisting Method - Already integrated
Verification-Hash Method - Beta
Whitelisting Method
The Whitelisting method relies on a public whitelist of verified issuer addresses. When a user wants to list a token, we do a metadata check for the mintingAddress
, comparing this address to our whitelist. If the address matches with some in our list, we can approve the listing.
Issues:
Having to contact all known tokenization companies -> getting their wallet addresses for tokenizing.
Relying on them not changing the wallet address -> if changed, they would have to update it.
Copyable -> Anyone can use this technique, making it not unique after a certain time has passed.
Security concerns -> Currently there are no universal / general metadata schemes or regulation how to mint tokens properly, thats why we would have to develop individual checks for individual solutions from different issuers.
While the whitelisting method is easy to develop and does not require an off-chain component, it does not offer the universal solution we want to have. Below you will see an overview of our metadata check solution.
Technical Overview
In general, we can summerize the required metadata in most countries into the following data fields:
issuerName string
issuerAddress string
issuerEmail string
issuerPhone string
issuerRegistrationNumber string
issuerWalletAddress string
assetType string
assetDescription string
assetLocation string
tokenName string
tokenSymbol string
totalSupply uint256
tokenStandard string
prospectusLink string
prospectusSummary string
prospectusRiskFactors string
regulationCompliance string
BaFinCompliance boolean
AML_KYC_Compliance boolean
transferRestrictions string
secondaryMarketAvailability boolean
The process flow can then be summerized like this:
In connection to this process, we can create our generalized solution on which we can integrate specific methods for special tokens, issuers, or metadata requirements with our off-chain issuer database:
While this method offers a great solution for small marketplaces, it would not bring the efficiency and the fitting strategy to our marketplace we want to deliver. That`s why we developed a more universal and advanced solution:
Verification Hash Method
Here, tokenization companies / digital asset issuers, can request the access to our APIs, which allows them to create a specific hash that let`s 3rd parties verify if an asset if either a verified tokenized security or just a normal asset. After users requested the verification hash at their issuers (either through mail or through a closed messaging service), the isser just has to provide his signature along with the the users contract and token address(es). Our API automatically creates a verification hash that can be stored within the contract`s or token`s metadata. The proccess uf updating the contracts metdata comes with the signature of the issuer, the completed updated metadata would contein the following in a completed version:
VerificationHash
: A unique hash generated from asset-specific information.LegalDocumentsLink
: A link or hash pointing to legal documentation validating the asset. (Not necessary currently for beta/POC development)IssuerIdentityHash
: A hash representing the identity of the token issuer, normally represented through their website URL.AssetDescription
: A brief description of the asset, ensuring clarity and transparency. (Needs to be included in the user`s request)Timestamp
: The date and time when the asset was tokenized, adding a temporal dimension to the asset’s lifecycle.
Tokenization Teaser
The (Perfect) Workflow
Currently, when a company issues a tokenized asset, the asset ownership is perfectly fractionalized into multiple tokens, but does anyone know what happens with the metadata? No.
Since each fractionalied token hold mostly the ownership to the same asset, companies store the metadata of the asset, in each token. (For example, if we have a property which uses 100 tokens to represent to dividend rights on-chain, every token hold the exact same metadata, with only a few adjustments.) This creates extremely high costs and wasted storage + unnecessary waste of computing power.
What`s about to come with tokenizing assets:
Because of that, we have created a solution that is called the Centralized Data Repository Contract in connection with an off-chain de-duplication algorithm, allowing to check if metadata is already stored one time, and creating and managing references to the metadata, to ensure it is only stored one time.
Integrations
Financing / Mortgage Integration
Sellers of listed assets can enable "financing", if enables, buyers are allowed to finance the asset. First, a buyer has to make an initial payment of 20%, after the payment is confirmed, the listed asset, and the inital payment is transferred to an escrow contract. This escrow contrcat holds the assets and all repaid funds until the loan is repaid. Once repaid, the asset is released to the borrower / buyer, and the repayments + the paid interest rate is transferred to the seller.
Current terms:
Max. loan duration is currently 5 years (approval by BaFin awaited)
Interest rate is dependent on the loan duration, starting at 4%.
Initial payment is always 20%, after that, the asset is in pre-ownership which is converted into full ownership after repayment.
Only one mortgage per person at the time, KYC required.
Borrower and seller always remain private, no details or information is shared.
Process Overview
Auctions
Structs and Data Mapping
Auction
: Struct includes seller (address payable
), starting and highest bids (uint256
), highest bidder (address
), end time (uint256
), description (string
), and active status (bool
).auctions
: A mapping ofuint256
token IDs toAuction
structs, tracking each token's auction status.
Core Auction Functions
createAuction(uint256 tokenId, uint256 startingBid, uint256 duration, string calldata description)
: Initializes an auction. Verifies token ownership and auction non-existence fortokenId
. Sets upAuction
struct and transfers token to contract.placeBid(uint256 tokenId)
: Facilitates bid placement. Validates ongoing auction status and bid amount exceeding current highest bid. Manages bid overtake logistics, including refund to previous highest bidder.endAuction(uint256 tokenId)
: Concludes auction. Checks auction activity and time expiration. Handles asset transfer to highest bidder or returns to seller if no valid bids are present.
Enhanced Functionalities
Time Extension Logic: Integrated within
placeBid
. ExtendsendTime
inAuction
struct if a bid is placed within a critical time window before the currentendTime
.Reserve Price: Incorporated into
Auction
struct and checked inendAuction
. If highest bid doesn't meet reserve price, auction deemed unsuccessful; asset returned to seller.
Token Locking Logic
Enhancement: When a token is listed for auction, it is now transferred to the Auction contract (
nftContract.transferFrom(msg.sender, address(this), tokenId)
increateAuction
).Locking Mechanism: The token remains locked in the Auction contract until the auction ends or is cancelled.
Marketplace Coordination: Implement a status check in the Marketplace contract to verify if a token is currently in an auction before allowing any marketplace transactions.
Cancellation Handling: Add functionality to handle auction cancellation, ensuring safe return of the token to the seller if the auction is cancelled before completion.
Withdraw Bid Functionality
Rationale: Allow bidders to withdraw bids under specific conditions. Useful for extended auctions or if a bidder decides to opt out before auction closure.
Implementation: Function to withdraw bid, adjusting
highestBid
andhighestBidder
inAuction
struct. Requires careful handling to maintain auction integrity and prevent misuse.
Example integration with ERC721 auctions:
User Verification
Our first idea was to create a hashed credential that can be integrated as a Snap in Metamask, but now, we have again created a more universal, interoperable solution to verify the identity and KYC data of a user on-chain. Besides our cooperation with Hokan.co and PaddleIdentity.org, we need an overall, simple solution that allows users to verify their data while remaining private.
Yes, zero knowlege proofs are the go-to address here, but they require a lot of development and knowledge, meaning we will implement them later in our verification structure, for now we just need to understand the simple cncepts. We have 2 solutions to offer:
Beta Solution:
KYC-Linked NFTs
KYC-linked NFTs offer an easy way to interact with KYC data with multiple wallets, independently, and at any time. The issue with KYC-Linked NFTs is the lack of technical advancements and security considerations, therefore, we have created a more secure, updatable, and regulated method, the BIPS.
Objectives
Enhance Security: Ensure all marketplace participants are verified.
Compliance with Regulations: Adhere to KYC norms.
Seamless User Experience: Simplify the process of identity verification.
System Architecture
KYC Verification System: Partnering with a third-party KYC Company like IDnow
NFT Minting and Management: Smart contracts for minting and managing KYC NFTs.
Marketplace Integration: Modify existing contracts to require KYC NFTs for transactions.
User Wallet Integration: Ensure users can store and manage KYC NFTs in their wallets.
Technical Specifications
1. KYC Verification System
Function: Verify user identity.
Process:
User submits KYC documents.
Verification by KYC provider.
On successful verification, trigger NFT minting process.
2. NFT Smart Contract Development
Standard: ERC-721 (for unique, non-fungible tokens).
Key Functions:
mintKYCNFT
: Called post-KYC verification, mints an NFT linked to the user's wallet.Inputs: User's wallet address.
Output: Unique NFT token ID.
isKYCVerified
: Checks if a user owns a KYC NFT.Input: User's wallet address.
Output: Boolean indicating KYC status.
Non-Transferability: Override standard transfer functions to prevent NFT transfer.
3.Marketplace Integration
For Listing Items: Insert
require(isKYCVerified(msg.sender), "Seller not KYC verified")
in the listing function. This ensures only KYC verified users can list items.For Transactions: Add
require(isKYCVerified(receiverAddress), "Receiver not KYC verified")
in transaction functions. This mandates KYC NFT possession for transaction receivers.
Transaction Flow:
Listing: Checks if the seller has a KYC NFT. If not, listing is rejected.
Transacting: Verifies if the receiver has a KYC NFT. Transactions are blocked if the receiver isn't KYC verified.
4. User Wallet Integration
Requirement: Users must use wallets compatible with ERC-721 tokens.
User Interface: Display KYC NFT status in the user's wallet interface.
Future: Blockchain-Based Identity Passport System (BIPS)
Concept: Developing a BIPS where each user gets a unique on-chain identity passport after completing a comprehensive KYC process. This passport is not just a hashed credential but a dynamic, updatable record that includes the user's KYC status, transaction history, and a trust score based on their marketplace activities.
Implementation: Using a smart contracts to create and update BIPS. The passport gets updated with every transaction, enhancing the user's trust score based on parameters like transaction volume, dispute resolutions, and feedback.
Advantage: Ensures KYC compliance and builds a transparent trust system beyond the marketplace, encouraging responsible and credible behavior.
Last updated