How do I modify my smart contract code so I'm the only one who can sell tokens? Everyone else send their tokens to me to exchange for either ETH, etc - solidity

So I have a token that has about 103 users. What I need to do is restrict the ability to sell those tokens to just myself the developer, so the other users can redeem their tokens for ETH or MATIC by sending to me. The alternative would be to just write a new smart contract, including this function and moving all users to the new platform. How would I write that new contract?

The first, you can't change code of deployed contract in Ethereum.
The second, look at ERC-20 and ERC-721 (NFT) standarts, its already have functionality you need.

Related

About Solidity Transferfrom and Approve Functions

I actually need a very simple smart contract using the following functions "transferfrom" and "approve".
I just need a smart contract that will be able to request approval to spend a token ( example -- bake ) from a wallet if the user calls the "approve" function.
It will also be able to withdraw the particular token from the user's wallet to the "address to" set by the contract's onwer, if the onwer calls the "transferfrom" function.
There's a design limitation of the ERC20 standard that disallows approval through a contract in between.
The user always needs to invoke the approve() function on the token contract directly - not through your contract.

what's the purpose of the approve function in erc 20

I'm new in solidity and erc20, so I read ERC20 description on the openzeppelin and find this function which isn't clear for me.
approve(spender, amount)
What's the purpose of allowing to the spender spend my token, instead of send my tokens to the spender directly?
You can change the approved amount or revoke it altogether (only the unspent amount). But you cannot take back an already sent transfer.
A common use case for the approve() function is trading on a DEX (decentralized exchange). You approve the DEX contract address to spend your USDT tokens for example. And when you want to buy an XYZ token (against USDT), the DEX simply pulls the already approved USDT from your address and sends you the XYZ tokens.
Approve is a function used to give permission the spender can be anyone an exchange or EOA to withdraw as many times from your token contract up to the _value.
You can check this reference here
As others said, Approve function can give permission to the spender to pulls the amount of token in your address. It can be used in: DEX (decentralized exchange) or in Custody services.
In custody services, after you approve the custody provider to take your token, whenever your wallet receives token, the custody provider is able to transfer your token into some internal wallets and keep them save for you. (It's just like how the traditional banks work)

Verify user is owner of an NFT via MetaMask connection? Make sure connected users public eth address is the same as of the NFT?

I need to verify on my own domain/server the user which has connected his MetaMask wallet is the owner of a specific NFT in order to allow him special functions? Basically, I want to give the user access to an area that only the owner of this NFS would have.
My original NFT is sold in opensea but I can't use the opensea hidden-area option to just give the user a hidden password since the next owner (after reselling) and the old owner would have the same password and old owners could still access like this. But I need that only the current owner has access.
My user/visiter can already connect with MetaMask at my own domain and I get the public ETH address of the active account but since this is only javascript and my backend is PHP I can't just post the MetaMask info to my PHP backend since this would be easy to trick/hack.
How can I make sure the current connected MetaMask Account is the same as the NFT owner (which I know) and allow to access a URL only for this user?
My current state is that the user connects his MetaMask and I use opensea API to check who is currently the owner of the NFT. I can compare both eth addresses but the flaw in this is obviously that I use ajax to send the MetaMask public address to my backend which is only for testing since this is of course zero save!
Thank you in advance for any idea, help, tip I can get.
PS: My backend is PHP
After hours and days of researching, I found a solution that works for me.
Here are the needed steps.
Use the MetaMask API to let the user connect with your site. This is pretty easy and good explained in the MetaMask API.
Once you want to verify the MetaMask owner is the legit owner of an NFT you need first query OpenSea (or another place) the current owner of the NFT. In my case, I use the OpenSea API for my specific NFTs. Once you got the owner you are ready to verify.
On your site you need to ask the user to sign a custom message with MetaMask. There are different options to do that. More about this here: MetaMask Signing. I send for example a short text message with a unique code that I first created in my PHP Backend. Doing that I also save the code and custom message into my MySQL.
Once the user has signed you get the signing code which you can send back to your PHP backend via ajax etc. without a problem. Only the owner of the Account which you requested in the signing code is able to sign with the correct account.
Once you got the signing code in your PHP Backend you can use Fast Elliptic Curve Cryptography in PHP and php-ecrecover to check the code against the unique code you created before and the message the user signed. As a response, you get the Signer Account ETH Address and you are ready to compare. If the Signers ETH Address is the same as the NFT owner you are ready to go and you can consider the signer the owner of the NFT.
I believe this is safe to use but I am not an expert on that. In my case, this only authorize an NFT owner for a certain closed area in my community page and there are not really high risks involved but maybe somebody raises some security thoughts on that. However, I found that other NFT pages and even Opensea work similarly.
I hope this points someone in the right direction, I lost quite some time figuring this out because most solutions are Node.js etc. but not with PHP backends.

how to differentiate between buyer and seller in smart contract?

I'm creating a new token in BSC using Solidity, and I want to identified when someone is buying, so I can make the contract do something specific
How can I identified when someone is BUYING? thanks

ERC20 solidity contract with pre-existing balances - possible?

There's a part of me that thinks that if this is possible it kind of goes against the whole idea of a secure blockchain, but I just want to check and make sure.
Is it possible to create and deploy a smartcontract which creates a number of addresses, each with a pre-defined, initial balance of tokens? And if so, can these addresses then be made 'accessible' as a wallet for someone to use?
So, suppose I create a coin ABC, and it has a supply of 1.000.000.000 and I then create 10 addresses, each with, say, 50.000 ABC in them, with the remaining ABC tokens still in the 'genesis'/initial address - is that possible? Alternatively, can this kind of "pre-walleting" be done with a second contract after the token creation? And suppose now that I have said 50K ABC addresses, can they then be 'given' to users/made accessible?
Of course one can always create the coin and then do a bunch of transactions to do the above 'the old fashioned way' but I am curious if such a setup can be obtained in a faster/shortcut way.
This can not be achieved using the standard ERC20 token definition, what you want to do is very similar to an "Airdrop", in that case that can be achieved following these steps:
Create and deploy the ERC20 token.
Create a smart contract to handle the token distribution, this contract will contain the logic to handle or the distribution process.
Call the distribution contract and pass the array of addresses that
will receive the token.
The problem that i see with your proposed approach is that in order to give the addresses to the users you must provide them the private key, which means that they will not be in total control of their funds since you already know those keys, so i don't think this is a good decision.