Seeking Help writing Smart Contract use case

Seeking help writing use cases for token that will document title to digital and physical property. Will compensate. This is what I am trying to create:

Need to write use cases for the following:

Smart Contract as Title:

I imagine tradeable token(s), that are linked or? One token will show the state of all the fractional title holders within the whole of a titled object, and other tokens will represent fractional ownership of the whole (I’m open to ideas on how to do this). I have questions about how much data I can or should store on-chain. I imagine an excel-like spread sheet shows all relevant data- which may be on or off chain with a decryption key provided if off chain.

Smart Contract to Create Crypto Currency:

Create a Crypto Currency that admin sets quantity in circulation—Presumably an ERC-20 Token

Smart Contract as Title and Accountant:

Variation on Smart Contract as Title above, but token owners receive accounting and proportional disbursements (optionally in crypto) of profits from titled property.

Smart Contract as Certificate of Authenticity:

Public key(s) to view only certificate(s) of authenticity. Private key to create and add data to certificate(s) of authenticity

Hello
I saw your job description. I can help you with smart contract development and use case.
Contact @cryptodev1990 via Telegram.

You're not coming up on my telegram?

I have read your job posting and I am interested in your job.
Hope discuss further more details via Telegram.
@DesarrollaorTalentosa
Best regards.

@bitadvisor

Hi I can surely get you proper help on this Let me know the right time and way to connect.

Telegram: @bitadvisor

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.

  1. 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.

  2. 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.

  1. 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:

Creator

Dated of Creation

Title of Property

Transaction history

Photo documentation of physical property

Other documentation

  1. 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).

  1. 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.

Telegram: @bitadvisor

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.