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.
Related
Thanks for taking the time to read my question!
I've previously built projects utilising the likes of coingecko, bscscan API etc... Which were perfect for the intended use-case, however now starting a new project I'm requiring informatiom which is proving problematic to obtain.
I'm trying to find a way to query a token address and obtain transaction information, such as how much BNB was spent in the transaction, and how many tokens were received in return.
With the tokens I'm trying to do this with, the majority of purchases are < 1BNB and as a result, BSCScan api returns 0 in the value key:value pair, as well as not providing the token quantities received.
While it would be nice to have access to token amounts received, it isn't absolutely necessary as I could produce this providing I had access to the amount spent on the transaction.
Outside of the commonly known APIs, is there a way to obtain this information?
I apologise if this is an obvious question, but with how transparent blockchain explorers are, I'm struggling to believe that there isn't some way to obtain this information, and struggling even further to figure out how to gain access to it.
not sure if this question belongs here... We are doing a giveaway but we have >30K wallets signed up. We're worried that many are bots. Have you encountered this yet? AND/OR does anyone have a solution to check each wallet transaction history to see if they have any transactions across other signed up wallets? We checked Algo Explorer and it seems that most cases there's a parent wallet and they're sending from the main wallet to a bunch of sub-wallets... thoughts?
Unfortunately there is no good way to prevent this unless you had some form of KYC. I could have a bot create fresh wallets with no transaction history that would be impossible to correlate with each other. Then if those wallets got an asset from you I could then just have them send that asset to the "main" wallet.
You could also set a minimum value of ALGO required to hold in the wallet to be eligible. It wouldn't completely solve the problem, but would make it more expensive for the people operating the bots at least.
Alternatively, set up a centralized service with email + captcha, make each address owner validate their address via that service and deny if they don't.
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.
I need to accept bitcoins on my website (PHP). I'm using blockchain and i have read the api: https://blockchain.info/api/api_receive Is quite simple but i have some questions, but first i will try to explain what i need.
Client send bitcoins to my wallet (Any amount they want)
Server will be notified with confirmations until gets OK.
Gets the sent amount and client wallet from callback and store in DB.
Now my questions:
"You provide a bitcoin address we generate unique addresses that forwards payments to that address instantly notifying a callback URL."
Q: Can we reuse that address and all clients use same address to send bitcoins? Or address will be deleted? The address have a lifetime?
Instead create address to pay is possible clients pay directly to my wallet and server got notified? I don't need extra params like tokens.
I end up in a website that use always the same wallet/address for each odd: http://bitzillions.com/satoshibones
I will like to have a pay system like that, one address per game.
Also should i use blockchain/blockchain (https://github.com/blockchain/api-v1-client-php) library or the simple library (https://github.com/blockchain/receive_payment_php_demo)?
Also if you have any suggestion or alternative i will like to hear.
I think I can help. Disclaimer that I work for BlockTrail.
It would not be good to use the same address because people can view the historical transactions associated with that address. It is recommended to use a new address for every transaction. These can be under the same wallet or different wallets. That may sound complicated but with the possibilities as long as the universe is old you can make a new address per transactions. Some wallets will do this for you automatically. This is called HD Wallets or Hierarchical Deterministic Wallets. You can also use this to have your clients always pay into the same wallet.
You can also use an API to create these wallets. If you are interested in using BlockTrail's here is the link: https://www.blocktrail.com/
We also have webhooks that will send you notifications for confirmations etc... If you want to learn more about our platform, here is a blog that describes it. BTW it is free! https://blog.blocktrail.com/2015/06/blocktrails-developer-platform/
I'm looking to implement an SMS authentication for one of my projects, basically before a user is able to register an account with us, we would like to authenticate the user by sending sms containing a code to his mobile phone, and get him to put in the code in our form before he can proceed.
I've been looking around and found onVerify to be a pretty good way to go
http://www.onverify.com/
But I'd like to know if there're any other alternatives similar to onVerify as it is a bit expensive, so if I could go with cheaper one, that'd be great.
Thanks!
You can do this easily enough if you have access to an SMS provider.
Typically you send an SMS to the user by making an HTTP request, containing the verification code. You'd store this code, and the recipient number, in some persistent database, against which you can compare when they fill in the details on the form.
You don't mention which geographic regions you expect your users to be in, which can be important given the variable delivery quality in some markets.
Have a look at the HTTP API for BulkSMS, message pricing and coverage.
Note that you can register in various regions, if you, for example, want to price in USD.
Disclosure: I work at BulkSMS