A very newbie question here, but is there a way to claim a BEP-20 token name kind of like buying a domain address? I understand that the contract is immutable so once deployed the contract is immutable.
Because of the decentralized nature of smart contracts, there's no central database that token creators would need to verify their token name against.
You can deploy the same token contract (including the same constructor parameters) virtually unlimited amount of times. Each time it' s going to have a different address, but also each time it's going to have the same token name.
Related
I'm new in the blockchain community, and i have to realize a web 3.0 project.
In this project, we have an ERC20, and for each user who sign up on our platform, I have to create a custodial wallet attached to this user.
User A want to be able to send tokens to User B.
I didn't find something concrete on google... so I'm maybe going in the wrong direction.
My question is: Is it possible to do that type of custodial wallet with smart contract in Solidity, and can you explain me how ?
In other to achieve this you will need 3 smart contracts:
Factory: This is the smart contract that has a function deployWallet that can only be called by a certain address, most likely the deployer address. What this does is deploy a new instance of another contract WalletProxy and store the address in a mapping to a UUID string which you use to identify each customer in your off-chain DB.
WalletImplementation: This contract holds the action you want your wallets to perform, e.g transferERC20, stake, swap, etc., and can be anything. It's going to be a contract you can always swap out and use another one with a more updated function, but be careful you need to understand how upgrades work in smart contracts and design Version 1 well. This contract will only be deployed once for every new version created.
WalletProxy: This is the contract you deploy every time a new wallet is created by calling the deployWallet function in the Factory.sol contract, only callable by a certain address. It serves as a wallet for each user and it's only a proxy contract that uses delegatecall to call functions from WalletImplementation, so in the future, if there is any update like WalletImplementation V2 it will always have access to it. The tricky part is also writing it in such a way that only a certain address can call all of the deployed wallet proxy contracts.
Reference Contracts:
I created the following contracts for the same demonstration purposes when asked how to create a custodian wallet using smart contracts.
Factory.sol
WalletImplementation.sol
WalletProxy.sol
I also did a live session where I built a simple exchange using the pattern described above. You can also go through the full codebase here https://github.com/CeloTAs/cXchange
I have already found many wallets that offer multisig smart contract deployment. But this way is very expensive and slow, because it requires a lot of transactions.
I think there is another way. For example, we can create many private keys, sign transactions with them, and then combine the results into one final transaction.
Is such a scheme possible? Or maybe I missed some services?
Ethereum does not support native threshold wallets. You need to use multisignature wallets like Gnosis Safe.
Gnosis Safe requires only one transaction per execution from the multisig wallet. Other communication happens off-chain. Thus your assumption "very expensive and slow, because it requires a lot of transactions." is incorrect.
Currently, Ethereum protocol only supports smart contract based multisignature wallets. They are very expensive to deploy and they do expose wallet setup: participants of multisig wallet, many of them and what is the minimum amount of confirmation to transfer funds from this wallet. On top of that, smart contract should know how to work with native coins, with different kinds of tokens and be able to handle multiple spending requests. This all adds weight to smart contract and makes it more expensive to deploy and operate.
However, there is a threshold signature system (TSS). In the nutshell it works the following way: all participants generate their own private keys, then they derive their respective public keys and share with others. The group public key is literally a sum of participants public keys. When they need to sign a transaction they calculate their individual shares of r and s values of a signature. This way they literally can just sum up their signature shares and get a group signature. This approach is called multiplicative-to-additive transformation and is a scope of multi party computation (MPC).
The advantage of it is that group does not expose their wallet participants to the world and transaction cost is the same as if that was signed by a normal private key (through a Metamask for example). On top of that, there is no difference what transaction you are signing, coin transfer, NFT token minting or deployment of smart contract.
If you want to try this in action feel free to download multichain multisig wallet: WH Cypher. It supports Bitcoin, Litecoin, Ethereum, ERC20 tokens, BSC, BEP20 tokens and more. There will be more blockchains supported soon. You can setup there any wallet scheme: 2-of-2, 2-of-3, 3-of-5 and so on. There is also test networks avalable: Bitcoin Testnet and Ethereum Ropsten.
Disclaimer: I am a developer of this wallet. Feel free to reach out to me to provide feedback or request new features.
I want to develop a dApp (Smart Contract) on Ethereum and have a mobile application on top of it.
My concern is: every time we interact with Smart Contract to inquiry or change data, we need a account as well as a certain number of ETH used as Gas. It looks no problem on the development environment, but getting into trouble in real life, I mean about user experience (UX).
- Whenever a user download and install the app, we will create for them an Ethereum account. BUT where they can get ETH to interact with Smart Contract? And absolutely, they don't care and don't want to be bothered with exchange ETH.
I have an alternative solution: we have only 1 Ethereum account with some ETH in their and act as the Proxy to the Smart Contract. Whenever user's request come, we delegate the request to Smart Contract and return to user. BUT it seems we will lost the main characteristic of Blockhain: Decentralized :) Who know we might arbitrarily change the Smart Contract without user attention.
Any suggestion is appreciated. Thank you!
You can send some ether to each new user that is just enough to call your contract.
I'm working on Ethereum ICO project, I studied Solidity and created a test token and deployed to Ethereum blockchain using MetaMask & Etherscan. but I'm not sure how to proceed further. I'm trying to connect different dots to achieve my goal. I have few questions related to ICO:
When launching an ICO, do we need to implement only ERC20 token standards into Smart Contracts or we need to write other logic's as well like how token buyers going to be benefited from this contract?
When investors send Ethers against ICO token, where to store those Ethers or how those Ethers can be managed so later all can be used for further development?
How to revert back Ethers if ICO goal is not reached?
How to transfer tokens to investors if ICO goal is reached?
Do we need Dapp for launching an ICO?
How contract manages tokens reserved for developers?
I studied Truffle but not sure how to use it for ICO launch?
It will be highly appreciated if anybody can guide me by replying all the above questions and share their personal experience launching an ICO.
Thanks in advance.
Its up to you but if you want people to be able to use your token in metamask / other exchanges to implement it you need to use ERC20 token, its tested and everyone knows how to implement
All depends on how you configure the contract but usually the person who lunch the contract will have access to the contract and can transfer the funds ... of course your contract your contract needs to be ownable in order to have such a properties enabled
You can do this by setting your crowdsale contract as RefundableCrowdsale
There is contract for crowdsale and in it, in distribution section you've options to transfer funds, essentially token is just a database with a list of wallets and how much of the wallet they own. meaning you don't really transfer anything and more like recording the name in the contract.
Not necessary, essentially investors just need to send ether to your contract.
I think that could be a a separate contract holding the fund for x amount of time before it gets released. The zeppelin-solidity seems to provide Tokenvesting.sol for this purpose.
Truffle is a framework, using industry standards of how you should deploy a contract it also helps with debugging
I would advice you to go through openzeppelin and by reading it you get a general idea of how everything works - helps with learning solidity
I am trying to understand how to swap tokens between blockchains...
lets assume the following:
I have a smart contract in ETH that issue a token (ABC) as ERC-20 token
I have a smart contract in NEO that issue a token (ABC) as NEP5 token
How can I consolidate them in one blockchain? (all in ETH or all in NEO?)
How do ICO's handle multi-concurrency collection?
Thanks All
Cheers
Each blockchain is its own seperated administration. Therefor it is not possible to swap tokens on-chain as you would need the first chain to rely on stuff that happens on another chain.
To do something like this, usually, you need a third party that guarantees that the exchange happens correctly.
An example of such a service is "ShapeShift". Take a look at what their service is about here:
https://shapeshift.io/
Just realise that the management of swapping is an off-chain process in this case.
Neo is unique in that it describes a mechanism in which off chain assets can be exchanged atomically, which is referred to in their whitepaper as "NeoX". Ontology is a collection of protocols of wich part is a implementation of the NeoX concept.