ARCs VS beaker

I will build Bonfire, a web app that implements a user interface for ARC-54: ASA Burning App, a community standard for burning ASAs. I will deliver:

The same as for the Algorand boxes, this proposal's research implication should reveal the exact technology for NFTs - it is expected that we use either ARC72 (https://github.com/algorandfoundation/ARCs/blob/main/ARCs/arc-0072.md) or ARC19/ARC3 combination (https://github.com/algorandfoundation/ARCs/blob/main/ARCs/arc-0019.md; https://github.com/algorandfoundation/ARCs/blob/main/ARCs/arc-0003.md).

Find out more about ARC 12 📁🔍 https://github.com/algorandfoundation/ARCs/blob/main/ARCs/arc-0012.md

Step 3: Click on the Template form link to view the proposal template. Read the information on the template page. You will need to submit your proposal to the folder Proposals, as specified.

As noted in the multiple discussions on the topic (on GitHub and our public discord meetings regarding auth standards) we (Foundation + community) reached the consensus that transaction-based authentication is not the way to go. Getting users used to signing transaction payloads for authentication is not ideal and once it's standardized it's hard to get away from. Instead, we've been focusing on ARC-0031: https://github.com/algorandfoundation/ARCs/pull/160

xGov discussions are ongoing on multiple places but mostly on the official Algorand Discord (https://discord.com/invite/YgPTCVk) - governance, arc-33 and arc-34 channels; on Github ARC repository https://github.com/algorandfoundation/ARCs/ (i.e. 33 and 34); and on Twitter spaces (follow Adriana Belotti - Algorand Governance Manager Program, at https://twitter.com/nonfungibleab).

Not necessary. While the proposals on which xGovs vote on will be published on Github (source: example on Foundation website), you can treat this simply as a website with links to documents describing these proposals (which will follow a template). You can just read through the proposals and vote based on that. However, it is encouraged to make comments to the proposals to improve their quality. For this part, you would need to learn how to use Github to make comments there or use alternative communications channels to give your feedback to the proposers.

To all the people claiming this information has been obscure, you should really give me a follow on Twitter. I have been covering xGov and EVERY SINGLE DETAIL for almost a full year between Algorand Forum, Twitter, Reddit, Github, and Discord. The info has been there if you were looking. Here's the most recent info, there are only a few details that this article misses such as 1. Your xGov voting power = your Algo reward for a given General Governance period. 2. Your xGov voting power will "refresh" every xGov voting cycle until "rolling off" after 4 quarters (though if you have other commits from future xGov commits, you will still have that voting power to use after initial rolloff): Folks Finance Medium article on xGov Adri Belotti & Stephan xGov NonTech Twitter Space Choppa from PactFi's notes on xGov Meetings (Find "xGov ARCS Conversation...." about 9 down, and another 4 down on the list where Choppa and I dsicuss xGov meetings) GitHub ARC 33 "Hot to become an xgov" GitHub ARC 35 "xGov Proposal Generation"

https://github.com/algorandfoundation/ARCs/blob/main/ARCs/arc-0033.md https://github.com/algorandfoundation/ARCs/blob/main/ARCs/arc-0034.md

You didn't specify what framework you are using. There are different ones besides the native TEAL: pure PyTEAL, Beaker, Reach and Tealish. They abstract state management differently. Take a look if one better suits your style and needs.

MakerX is our technical partner on AlgoKit, and they've been doing a stellar job. Algokit's goal is to make development extremely easy, it was built with modularity in mind because all software (languages included) ages like milk, so whatever language there will be 30 years from now can still leverage our work. We are championing beaker, we're also trying to achieve vanilla python (this is the language) which is a huge engineering effort. Smart contracts programming will never go away, we can however give ever more building blocks that compose the most common parts of smart contracts. We're evaluating formal verification, have a few options (linked in other replies) let us know what you think!

Lastly if you still really want to get into smart contracts you'll want to use a framework, which you can find here (there's a tutorial on the algo dev docs too I think): https://github.com/algorand-devrel/beaker