Closed paigel closed 1 year ago
Part of #1 : the primary output feature we want out of the Etherspot SDK
per etherspot SDK requirements, this will require triggering an 'estimate transaction' process before we can allow the user to click 'mint', which will generate errors if the transaction is invalid before submitting it, and will yield a cost estimation that the user can be shown to decide whether to proceed.
per etherspot SDK requirements, this will require triggering an 'estimate transaction' process before we can allow the user to click 'mint', which will generate errors if the transaction is invalid before submitting it, and will yield a cost estimation that the user can be shown to decide whether to proceed.
@brandondees two questions:
@paigel yeah we're not tackling any special fee handling, it's the usual user pays model, and that also means the user has to transfer money into their new wallet to use it. i figured we'll just put text on the screen to explain that, along with the address.
@paigel invalid could be a lot of things but things like if the contract function is unprocessable due to bad inputs or if the code makes it impossible to estimate the gas cost, or user doesn't have enough money, or they're trying to do something unauthorized, etc. -- usually this shouldn't happen if our smart contract is done right but there can also be other edge cases like the RPC server having problems, network connection failure, etc.
the point of mentioning it is that the requirement to pre-estimate the transaction is for reasons, not an arbitrary choice we're making or that's arbitrary on etherspot's part.
okay got it, thank you for the extra info!
transaction sends but then reverts. our app code doesn't get a helpful error message but this info on polygonscan is a good clue. it seems like i accidentally left some openzeppelin boilerplate code that requires minting permission to be explicitly granted per address. i'll try doing that manually for now to confirm. then we have a decision to make: do we remove the role checking and re-deploy the contract so that it's public-demoable, or just leave it as is since we don't expect people to want to use it?
confirmed that we left as-is and do not have a public demo.
User Story
User mints two separate NFTs in a single minting transaction. User receives 2 NFTs as SVGs with embedded text:
(NFT details are in #3 )
"Hello, World!"
"Pizza, Bagel!"
mint
button once allows a one-click action mint of both NFTs (button UI: issue #7 )