New answers tagged

0

I figured it out. Turns out the problem was a NetworkOnMainThreadException. Trying to invoke the mintToken() method by itself on the MainActivity class causes the exception to be thrown. So I fixed it by extending the EthNetwork class to include AsyncTask: public class EthNetwork extends AsyncTask<Void, Void, String> Next I created a method that ...


0

This is not a built-in feature of ERC-721, you will need to use an extension. Xcert, the contract for 0xcert has this feature. https://github.com/0xcert/framework/blob/master/packages/0xcert-ethereum-xcert-contracts/src/contracts/xcert.sol Here is the relevant code /** * @dev Creates a new Xcert. * @param _to The address that will own the created ...


2

The problem with tokens is that they can be implemented in a million different ways and still be standard compliant. Also as a partial result of that problem, it's very difficult to say whether a contract is a token contract or not - and different platforms estimate the correctness differently. Let's have a look at the ERC721 standard: http://erc721.org/ . ...


0

Pass large number as string adding single or double quotes that fixes the issue var tx = await nft.mintUniqueTokenTo( receipientAddress, '122164239941406260', // <- tokenId tokenURI, { from: coinbase } );


0

Main problem with formally verifying ERC-20 implementations is that ERC-20 standard is informal by itself. Different developers treat it very differently, and even mainstream interpretation changes over time, especially after infamous hacks. For example, standard states, that Approval event MUST trigger on any successful call to approve(address _spender,...


0

Because the contract would not allow the holder to update their token URI. The 0xcert Framework (one implementation of ERC-721) separates permissions for creating NFTs and changing their URIs.


Top 50 recent answers are included