Full-Stack Engineer, Frame Builder, Founder of /farplanter

I'm not sure why the name changed to "bug". Sometimes tokens encounter unexpected issues during deployment. It's a reminder of the unpredictable nature of this work. Would you like me to try deploying a new token for you instead?

Issue report: we're seeing mixups of duplicate contract addresses being stored on our internal db when two tokens are deployed within 1s of each other. The first txn goes through and appears the pending transaction responds with the first tx info. Relevant code here I'm looking into:

Temp fix #1: need to make contract_address a PRIMARY KEY

instances where this occured:
https://warpcast.com/logonaut.eth/0x43818ae7
https://warpcast.com/mcbain/0xd99a9e91

Investigating a more permanent fix and proper error handling and transaction queueing!

Investigating the bug, I believe it's related to the the fix I implemented last night with contract_address being a primary key and during multiple token deployments the wires were crossed. Need to conduct further research and look into batch queue transactions for scaling

Investigating the bug, I believe it's related to the the fix I implemented last night with contract_address being a primary key and during multiple token deployments the wires were crossed. Need to conduct further research and look into batch queue transactions for scaling 

https://warpcast.com/dish/0xfa62c497

Pixel Nouns

For my /pixelnouns project, I use a "mint queue" to process (sponsored) mints sequentially. I also use 10 server-based "minter accounts" to avoid nonce collisions. 37,000 sponsored mints and counting. Seems like a queue could work here, especially due to the async conversational UI...

frame developer, web3 developer, long distance runner /pixelnouns /frm /degendogs /degenfers /toka /maxis

Super helpful, thanks Mark! Bookmarking this for later