Likes - Activity - HashMapsData2Value - Algorand

xGov 186: TxnLab Use-Wallet Discussion

Thanks for your question! As an open source project, our approach to wallet integration in use-wallet is fundamentally inclusive. We welcome and actively encourage contributions from developers in the ecosystem. In fact, several wallet providers currently supported in v2 were added by community contributions.

Yes. It would be trivial to evade. I was thinking about it from the perspective of how OFAC normally works, where certain entities get blacklisted. But in crypto, it’s easy enough to evade this setup. So I could see whitelisting rather than blacklisting being the preferred solution. One thing that needs to be considered is...

I want to address this because opt-in is a significant friction point for Algorand adoption. Although NFD vaults are commercial solutions for users who want to receive airdrops, they do not address other use cases. Everything from on-ramping USDC to other ASA-based applications must also be considered.

I wouldn’t have started any project if there wasn’t UseWallet. A more universal, non-React-bound version would certainly be needed. Ensuring compatibility with new wallet releases and protocol changes is crucial.

The use-wallet library is a critical piece of open source code that dramatically simplifies connecting web dapps to many different wallets, most of which have their own unique interfaces. The existence of use-wallet enables other developers to build faster and provide best-in-class connectivity options.

Hi Everyone, I’m Alessandro Cappellato Ferrari, Head of Product at the Algorand Foundation. On behalf of the team behind this effort, which includes @Adri, @trekianov, @StephaneBarroso, and @Loedn, I’m happy to present the working document for the evolution of the xGov platform.

Proposals are to be submitted to vertical heads for evaluation, and approvals may be processed by vertical committees or by (a) the vertical head and/or (b) GAC.

Imo the best solution would be to decide on a case-by-case basis following a vote by Algorand governors.

Serious question: why seek the community’s feedback? We did this last quarter, and there were consensus views from the community that were not implemented before the vote. My opinion is, why get into the business of bailing anyone out? Why not just let the market forces work? There’s plenty of natural evolution in this space.

This proposal depends on the xGov platform, which doesn’t exist. More clarity is needed. Is this simply voting on the amount of ALGO to allocate toward future xGov community grants? The entire xGov platform and this proposal deserve to be formally presented to the community and discussed in live Q&A sessions.

This sentiment is important. It appears that the options under each measure do not provide governors much agency, and the general direction will be similar regardless of the vote outcomes. The community will perceive this, and there may be substantial backlash, regardless of the measures' intent.

I strongly disagree with the "illusion of choice" way governance is being handled here. Measure 3 presents the question as, "Do you want to put your coat on inside or outside?" It’s not offering any meaningful choice to governors, and it’s embarrassing for the foundation to pretend this proposal has been endorsed by the community.

In the context of vote coin, we encrypt voting ballots using ed25519 public keys and decrypt using private keys. Furthermore, the questioner may publish the private key to the blockchain post-voting, enabling everyone to verify which accounts voted, thus ensuring full auditability.