I'm trying to get familiar with the patterns in designing Solidity smart contracts.
For example, say I'm trying to model a Mall with multiple Restaurants in it. Each restaurant can have multiple Owners owning a stake in the restaurant. The person with the greater than 50% ownership is the main owner of the restaurant. Each restaurant has a valuation. People trade ownership of the restaurants using a MALL token.
Now assume that I have the following user interface.
- (1) "Bidders" can see a list of owners of a restaurant and can make an offer to buy all or some of an owner's share of the restaurant. They can bid at market value for the share or above/below market value
- (2) The owner can see various bids and choose to accept/reject the offers.
With an ERC20 token, you would need to make an allow transaction followed by the actual transaction so I thought using an ERC777 would allow for an easier workflow.
The "Mall" contract could be an "operator" for the "MALL" ERC777 token.
I thought the actual bid making could happen off-chain.
When a bid is accepted, that's when something is written to the blockchain (something that confirms that the owner is willing to sell their share, how much and for what value).
Otherwise I feel it would become too messy - if the bidder had to transfer tokens with each bid, then the owner could purposely not respond to them and tie up the funds of the bidder. Obviously I could use some kind of time calculation. But to revert the funds even with a window for the owner to accept/reject without making it too costly for myself would need some kind of UI/mechanism for the bidder to go retrieve their funds minus fees (which is not a good user experience!)
So in a nutshell I'm stuck trying to figure out what is the best way to write this smart contract without making the user interface too complicated or burdensome on the end user. I feel like this would be something very common in the Solidity world but despite a great deal of searching, I can't find the best practices on how to implement this.