Smart Contract Developer Wanted
It is my expectation that these smart contracts will be taken from existing well tested smart contracts, or from existing and well tested component code from Open Zeppelin, or someplace similar. I want to be able to see if anything is original code (because it doesn’t exist in any code repository). I have arranged these contracts in what I perceive as order of difficulty. Some build on the prior contacts. Please bid on them each in order, ask any questions or make any comments, or let me know anything that might be helpful. I am looking for a developer who can create high quality and secure smart contracts as described. If you can do this, there will be a lot more to do.
Mint 23M cryptocurrency tokens. Only administrator sets, gets and accesses contract Mint. Question is how many decimal places: Bitcoin’s 8 or Ether’s 18, or some other number? Pretty simple. Such a contract already exists. What else needs to be done? Completion is the delivery of the reusable contract and the tokens in my wallet.
Exchange tokens. Reusable smart contract that will exchange tokens at an agreed rate. Presumably ERC-20 tokens.
Example: The parties agree to exchange “Token A” for “Token B” at a one for one ratio (1:1). Set a time frame for both parties to send their tokens to the contract. If both don’t send their tokens by the expiration date/time, the tokens are returned. If both parties fulfill the contract, the exchange is executed, resulting in the expected tokens in each parties’ wallet. Such a contract already exists.
- Certificate of Authenticity: A public key accesses read only data about the authenticity of the property it authenticates (there should be an appropriate cost to access to prevent malicious actors).
A private key can post, edit, and (maybe?) delete the data that is accessed with the public key, and may access data that is not accessible with the public key (only with the private key). Only the private key can write, the public key can only read.
The question is how much data can be on chain? If it is too much to efficiently be put on chain, it should link/provide a decryption key to access the off-chain data.
If off chain data is necessary, we must make sure such data is always accessible, and cannot be altered, and can be verified as the data referenced by the certificate of authenticity (maybe with a hash and/or checksum?).
Data may include, ideally in an excel-like format, the following:
Dated of Creation
Title of Property
Photo documentation of physical property
- Title digital and/or Physical Property. This might be able to be done with one token, such as the ERC-1155. The title will contain all the information about the property, just like the certificate of authenticity. The complexity is that that ownership can be fractionalized. I conceptualize this as the whole token and the fractionalized tokens that make up the whole token. The owner of a fractional token has his or her own token that can be traded at will and without permission, but the whole token needs to account/link for each fractional token that comprise its whole. This title will have the same information as the certificate of authenticity token, in addition to documenting each transaction and fractional owner (maybe just the fractional tokens will be identified with serial numbers/meta data instead of any personal information about the owner).
The token might require some governance capabilities, so that a majority, or maybe super majority (60 or 66%) can vote to sell the whole, and all fractions, by accepting a tender offer. The contract would enforce this decision (obviously some acceptance of terms will be necessary to do this).
- Title and Accounting. All the functions in the title above at 4, plus the token would either make disbursements of profits from the property to the fractional token holders in crypto, or account for the disbursements in fiat currency due and/or paid to all fractional token holders.
The example is a royalty for a musical composition. The title and the music are held in a token. Profits, in the form of quarterly royalties are received and disbursed proportionally to each fractional owner/token holder in crypto, and if fiat, is accounted for showing the holding of the fiat disbursement or confirming the fiat disbursement. Some oracle (off-chain) authority would need to load or hold disbursements.
Instead of deleting, maybe it would be better to show later corrections/edits, so that once data is entered it is immutable. This would be more transparent and trustworthy.