Peer to peer betting
Ability to send bet someone, have it accepted, wallet engages both parties to fund, event concludes, smart contract matches bet w sportsfeed for verification of winning party, smart contract settles account.
Users can bet each other on any event, including and especially non traditional sports (battlebots) and esports (madden tourney), which is not currently being addressed by traditional sportsbooks and vendors, in the current market in the United States.
Girolamo Cardano would maybe like this because of his gambling nature
What about non-fungible tokens for that purpose ?
The Napolitana token, the Siciliana token, etc … each associated with a shop ID and issued by the vendor’s machine. No matter on which address you receive those, as long as you have them and matching the shop ID you want to use them on.
Possible ? You pay your free pizza by returning the 10 tokens to the vendor.
As an accessory fun, you could even breed pizzas to discover new funny ways to arrange tomato, banana and chocolate. The shop owner does not care, as long as the ID of shop stays unchanged within the new token. Of course, when two tokens mate, you get 2 tokens of value 1 or 1 token of value 2…
And then starts the pizza-kitties madness. But on a community localized around the pizza truck.
Charles and IOHK might have the feeling their efforts were wasted
Printing store currency kind of reminds me of this:
I doubt CH and IOHK will feel their efforts are wasted if a pizza-kittie styled token appeared on the platform.
The pizza-kittie madness is actually more in depth than the surface of such information shows, very genius idea that the erc721 token is (cryptokitties), most people when looking into ETH tokens get around to understanding what an ERC20 is but fewer people start to look into the coding and functionality of the other ERC ETH tokens and what utility they could perform in the world.
An ERC20 contract with 100 coins is basically a contract with 100 coins that are identical
the ERC721 contract of 100 coins is basically a contract with 100 coins that have some identifier that makes them individually unique.
So if a pizza breeding shop was to run on the cardano network then people would always be able to claim they had a special unique coin to represent it in a sense - a collectible pizza for what its worth, how a visionary could take this code and change the application to fit it into the world as a real use case could be done just by viewing the pizza breeding shop results.
For instance lets say as we move toward decentralization and tokenize everything you would like to invest in a timeshare, the agent selling timeshares creates tokens that give access to the property, if they are ERC20 than everyone with the coin could access the property at any given time (if based on the idea the token is the key), yet if the tokens are based on the pizza-kitties code(like ERC721) then the property could then be programmed to allow access only to the uniquely numbered keys at certain date and time.
I hope a pizza breeding shop is created on the platform
But you do realize I use humor as a defuse mechanism, just in case I say silly things without noticing. It is called the anti-backlash smart contract
I love anti-backlash contracts, your post was not silly, maybe… I read in between the lines
There doesn’t need to be a shop ID because the smart contract itself stands for the shop. Things to solve are more about:
- how to group payments to customers if every order has another sender address (which is needed for privacy and also to know if the customer payed at all)
- then, if you store something like a key and a counter, store it in a way it is not exploitable. (by looking the contract for 9th orders and pretend your order is always the 10th or something like that)
Well, how would this play in the case of a non-fungible token (ERC721 like f you wish)
- Creation of a App that allows easy click-buttons creation of a non-fungible tokens bag.
- Shop Owner side
- You identify yourself, the number of tokens you want created, their date of expiry, their designation etc … and submit all that to this webpage app / daedalus app.
- Pay the fees involved in this one time generation event. Some goes to the creator of the template contract.
- You receive the desired amount of unique tokens into an address. They are yours, and will return to you eventually after distribution.
- You are now a shop owner with X amount of non-fungible tokens.
- Client of the shop
- Buy a pizza
- Get offered by the seller the possibility of receiving a unique token working like a stamp on a fidelity card.
- Accept it /them.
- Receive it/them on a address of your choice. Daedalus will recognize the template ERC721-like and will pull all the relevant info from the blockchain. Shop / location / opening hours if the attribute field even exists ! / token designation / etc …
- Next time you’re hungry, the sellers will accept 10 of these tokens against a pizza. Making effectively the 11th for free.
In such a scenario, there is no contract counter involved. Only a quantity of non-fungible tokens. Also, for such frivolous uses I am not expecting tons of privacy features nor security overhaul. It is a fidelity card… I mean, I would forget those in the bus …
More expensive use cases might implement with higher standards ? But this feels already to me like an overkill for a pizza-worth fidelity card.
Now I got it. Indeed very clever to get a stamp token and simplifies the design.
I’ve been waiting for Cardano to mature enough to finally build the Brewtegrity® token on it. Hopefully someday I will have enough helpers to actually build it.
Basically the idea is complete production transparency for beer. It is sort of like enforcing Organic for beer. Turns out the majority of breweries add nasty chemicals during the production process and they don’t disclose that information. Brewtegrity would hold the industries feet to the fire on that issue and remove the nasty processing agents that they use to cheat the consumer.
POKER Post must be at least 10 characters
I watched it a few years back, but it’s still entertaining. But, all monies remind me to this.
Stake redistribution contract.
Rationale: Staking pools will be a race to the bottom providing value so users choose them for staking either redistributing ada back to the users or offering value added services.
How: While I dont know if staking adress=store adress one could make a registration process where stake adresses are stored and % of stake reward redistributed to registeted users who provide proof of proof of stake (heh).
Your staking rewards will go to a special reward address. (interestingly this is an account style address not utxo to prevent dust)
Reward distribution is not done by the pool but automatically by the protocol. As far as I understand you will not be able see what addresses are delegating to a pool at all.
Yes but I am talking about the pool redistributing its rewards back (on top of users rewards) to the stacking users. With low hardware costs this is a likely strategy for pools.
My point was more like: how do you do this if you are not able to see who’s addresses are delegating to your pool?
And the bonus question : wouldn’t it be easier to just lowering the pool margin then?
Thats why I said you need a registration process. And yes if the pool can just set the margin obviously that would be an easier approach. Look forward to learning more on this subject.