minter-sdk VS tzip

For the parts related to the image generation and hosting it's pretty much the same as it would be on Ethereum, but when it comes to the contracts it depends on what language you want to write in. Tezos actually has a lot of language options which all compile down to Michelson. I like and have the most experience with LIGO, which supports several dialects. They have a really cool website for learning it too. Once you've done that then tqtezos has a huge collection of reference contracts available on github. I'd also recommend reading through the NFT related TZIP's here, most important are TZIP-12, 16, and 21.

Github

For testnets (and only testnets) it makes sense to centrally manage updates so the testnet and mainnet evolve hand in hand. The tzip has all the details about the design choices.

Further details in the TZIP: https://gitlab.com/tezos/tzip/-/blob/master/drafts/current/draft-symmetric-liquidity-baking-toggle-vote.md

For the parts related to the image generation and hosting it's pretty much the same as it would be on Ethereum, but when it comes to the contracts it depends on what language you want to write in. Tezos actually has a lot of language options which all compile down to Michelson. I like and have the most experience with LIGO, which supports several dialects. They have a really cool website for learning it too. Once you've done that then tqtezos has a huge collection of reference contracts available on github. I'd also recommend reading through the NFT related TZIP's here, most important are TZIP-12, 16, and 21.

Yes to all and token standard fa 1.2 or fa 2, depending on what you need to do (and homebase is cool for Dao). You can read about token standards on https://gitlab.com/tezos/tzip

And to be honest, I'm pretty sure use of to_ with an underscore is because "to" is a protected keyword in OCaml, which is what LIGO (popular smart contract language) is similar to. So technically it doesn't adhere exactly to TZIP-12. But idk if its a big deal.

Regarding adding events to Michelson, we need feedback on the TZIP. Can you comment there about what you think is needed? Here is the discussion: https://gitlab.com/tezos/tzip/-/merge_requests/121

thanks, but your link is broken. This link works

Gives an increase to the liquidity baking sunset level of 211,681 blocks, or five voting periods plus 6,881 blocks to sync with the following voting period, roughly an additional two months and a half. Without this, the subsidy would halt during the lifespan of this protocol. With this change the subsidy can continue until the protocol after this one is activated, even accounting for some delays in proposal injection and/or a restarted voting process, while still making sure it won’t extend to two protocols after this one without a more significant increase. This follows the spirit of the liquidity baking TZIP in that it is still roughly six months from Granada activation and requires a referendum on the subsidy in the protocol after this one. (MR !3425 !3464)