New answers tagged tokens
1
Ropsten is, well, a testnet. It can be used for testing various blockchain functionalities but everything in Ropsten is useless in the "real" world. You can't use Ropsten assets in the main chain and all assets in Ropsten are worthless.
So if you want your assets to have some real users, real usage and possibly read value you should put it into the mainnet. ...
0
IM also created token in ROPSTEN network, so question is the same:
Should i move my erc20 token to main network?
to use my tokens as coins in regular ether network?
0
Solidity allows two functions with the same name and different parameters.
They have different signatures so the client will call the correct one.
1
Short answer is: not necessary.
ERC-20 standard requires token owner to personally initiate, or at least approve all transfers of his tokens, so when using ERC-20 functions, token owner has to execute some transaction from his own address in order to move tokens forward. If token owner uses an Externally Owned Address (EOA) to hold tokens, then executing ...
0
Mostly: yes. They can receive the tokens but if they want to transfer them onwards they need Ether to pay for the gas fees.
There are various schemes to let someone else pay for the gas, see for example here: How to make someone else pay for Gas? . One option not (directly) mentioned there is meta transactions but that is also something quite new and not ...
0
Adding this line to code actually solved my problem.
bidders[tokenDetails[bidders[returnId].addr].personId].remainingTokens = currentbalance;
0
A bit difficult to say as this is a part of a bigger contract. But here's my guess.
At the end of the function you are setting your startPrice to be zero. Next time the function is executed the multiplication of startPrice = startPrice*100000000*amount gives always 0 so you always approve the move of 0 tokens.
1
To begin with, change this:
goods[msg.sender].add(amount);
To this:
goods[msg.sender] = goods[msg.sender].add(amount);
And this:
bids[msg.sender].add(startPrice);
To this:
bids[msg.sender] = bids[msg.sender].add(startPrice);
You probably also want to change this:
startPrice = startPrice*100000000*amount
To this:
startPrice = startPrice.mul(...
1
One is protocol and one is an app. You explicitly write the procedure for both cases.
Ether
The EVM uses ether to financially incentivize securing the network and verifying transactions. All ether originate with a found block and a reward paid to the miner that found it.
In a contract, msg.value is the amount of ether sent to a function, and the ...
1
The question is too broad.
An ERC20 token gives you the accounting and transferability as well as compatibility with wallets and exchanges.
Great.
In theory, you can sell the tokens for money if anyone will buy them. Why would they? It's not a rhetorical question.
This is an economics, mechanism-design question. It's a little too broad to describe ...
1
This is definitely possible off-chain, as one may monitor or query Transfer events.
In general, this is not possible to do on-chain, as token transfer do not leave any trace, so smart contract may not verify that some token transfer actually happened. However, smart contact may verify that token balance of certain address (probably smart contract's own ...
2
I guess it depends on how paranoid you are. These two functions are private and so the rest of your code may prevent reentrancy. However if you really want to be safe you could introduce a mutex of some sort, like:
bool isTransferring = false;
function transferFunds(uint _value) private {
require(isTransferring == false, "Rentrancy Detected");
...
2
In function transfer:
balances[msg.sender] = (balances[msg.sender] - tokens);
You are not verifying balances[msg.sender] >= tokens.
And so when balances[msg.sender] < tokens, the unsigned value of balances[msg.sender] - tokens will typically be huge.
For example, consider the following case:
balances[msg.sender] == 0
tokens == 1
Then balances[msg....
0
The problem with receiving tokens is that a contract can't know when it receives tokens - there is no transaction to the contract which receives the tokens as the tokens are exchanged only inside the token contract's balances. There are lots of posts about it, here's one for example: Detect token transaction to a contract
So basically what you'd need to do ...
0
You can modify placeBid like this:
function placeBid(uint amount) public notOwner returns(bool) {
require(auctionState == State.Running);
// update the current bid
uint currentBid = bids[msg.sender].add(amount);
require(currentBid > highestPrice);
// set the currentBid links with msg.sender
bids[msg.sender] = currentBid;
// ...
0
I would be inclined to make a token factory that issues ERC20 shares. The shares in A would be fungible and you would have another contract for B.
You would probably want a way to track them, the contracts, symbols, desc and so on. ERC721 is a candidate by there is nothing to "transfer" in the reference list itself so I would probably just build it into a ...
0
You're not the first one to have such a question. Here's one reference: Ethereum implementation of a non-fungible but divisible token? (ERC721 seems not to work for that) . The first answer there suggest that the token can be owned by a contract which should actually solve your problem - you just have to code the owning contract in a certain way.
There are ...
0
Try to update your Tokens by (if they are your tokens):
ERC865
0
Yes.
ERC-721 requires that every token have own owner. Source. It is permissible that other entities have permission to revoke that token and transfer ownership to someone else. Source.
You are adding a requirement that a token "belong" to multiple people and that somebody else have "custody" of it. So long as the token still only has one "owner," then yes ...
0
The ERC721 standard includes an approve function, which allows the owner of a given token to approve another address, and give that address permission to transfer that token, but this second address is not an owner. The 721 standard only allows for one owner per token at any given time.
0
The ERC721 is a non-fungible token format, which implies that only one of itself could exist at any point. When you use an ERC998ERC721 top-down composable, you transfer ownership of your ERC721 token to the ERC998ERC721 top-down composable.
Thus, the ERC998ERC721 top-down composable has the ownership of the ERC721 token and not you.
More here.
Top 50 recent answers are included
