Open-Sourcing AVM Email: Joining Encrypted Communications with Defi: 3524536010

Governance Discussions xGov Proposals
1

Category: Other
Ask: 150,000 Algo

Value Proposition

  • Already open-sourced and repository submitted to Electric Capital with MIT License

  • 5 PUYA smart contracts for the first decentralized, non-ephemeral, bidirectional, encrypted communications and staking pool service live since October 2025

  • PUYA smart contract pipeline for platform usage, including on-chain registry, staking pool factory, buy-back-and-burn tokenomics or commission-system on email / server purchases.

  • One of the first on-chain implementations at scale of any encryption utility on AVM

What is AVM Email?

AVM Email is a fully decentralized, on-chain, encrypted communication system — our encryption implementation was guided from previous CTO. Although there has been a variation of attempts at on-chain encryption. We are the only encrypted communications dApp on Algorand that checks all of the below:

  • Bidirectional Encryption, encrypt and decrypt sent and received messages between you and another individual on-chain.

  • Email servers provide buyback & burn token functionality, or fallback to a commission based system at user discretion

  • Has a designated workflow for encryption key derivation and does not require arbitrary transactions to be signed

  • Create staking pools for your owned servers

  • Live for the past 6 months

  • Smart contract pipeline

  • Community of 100+

  • DeFi integrations

  • Fully open-sourced

In combination with our on-chain registry, non-ephemeral keys are core to our usecase as communications can be easily retrieved and read by both intended parties. There is no sharing of data or databases storing unencrypted content — only the senders and receivers in any conversation can decrypt communications.

Users can earn commissions on referrals to their email servers eg; @algolinks.avm @asastats.avm @ethereum.avm, etc. when users create email names. Alternatively, server owners can forego these commissions and opt into triggering buyback & burn events for any token of their choice instead; these settings are configurable at any time.

Server owners can create staking pools through their servers to incentive users to purchase email names under their server, and of course any email owner can communicate with another email owner of their choice.

Is Application Live: Yes

Application Is Open-sourced: Yes

Contracts

  • AVM Email Registry / Factory
  • Email Listings Contract
  • Server Contract
  • Email Contract
  • Spam Email Contract

Team

  • Leo Costa

  • Allan Diamante

  • Ulrik Diamante

Previous Works

Adoption Metrics

  • 39 Servers Created

  • 46 Unique Email Addresses Created

  • Greater than 40,000 Algo in Fees Generated

  • 7 Puyapy Smart Contracts

  • Bidirectional Encryption for Encrypted Communications

Additional Info

Website for AVM Email: https://avm.email/
Repository for AVM Email: GitHub - atsoc1993/AVM-email: On-chain Encrypted Communications and Decentralized Finance on the Algorand Virtual Machine · GitHub

2

Thank you for splitting the proposal into multiple parts.
Could you elaborate more on the usage of the AVM Email? How much does the community of 100+ users use the email service and related DeFi integrations? Where is the community located?
Would you also mind specifying in more precisely since when is the service live (i.e. since 2025 is 1 year span)?

Based on past controversies regarding related proposals, I would prefer the work were open-sourced in advance rather than only after approval. This would enable xGovs to better assess the benefits of the delivered work.

3

Of course, no problem.

The launch date was 10/27/2025, so we are nearing 6 months live.

There have been 29 generated servers in total, fees generated from the platform are forwarded to over 100 users in the affiliate Algo.fun platform. Each server can earn commissions to server creator or buyback and burn tokens; we have more details about all functionality under our FAQ section (Question mark symbol at the top right of any page on AVM.email )

We have not seen anyone utilize the server staking pool services as of yet, but that logic is there and functional.

As a reminder we had launched at a time where general sentiment was not great in the community, as we can see by the >50% inactivity rate across the xGov community as a whole alone and, sadly, the general price action. We are still here chugging along— hopefully as sentiment recovers and we get better traction we can see these things change.

Our discord is not the most active, but can be found here: AVM Email

There are 49 users in the discord.

Similar to a comment I left on the other forum thread regarding open-sourcing beforehand as a preference — we actually don’t mind doing this for AVM Email. We would personally prefer not to as there are others trying to implement something similar, however those implementations have been lackluster and generic, likely vibe-coded as I have seen, and missing key components that make UX significantly more friendly, alongside many other optimizations eg; simple transactions with note fields as opposed to intricate smart contract pipelines for communications.

Again, similar to the other thread’s comment. We are not familiar with what occurred in the past with xGov, but we don’t feel that by pursuing the conditional open-source pathway should cause us to fail to meet TnC. It should not be an option otherwise — if we were brand new to the community or notoriously known for vibe coding I would understand, but we are well-known and have contributed to projects in the past like Rxelms that should hopefully warrant some discretion in our favor to not open-source preemptively.

4

Regarding usage, the fees you speak of here, are these the 20k ALGO you refer to in your other proposal? Or how much fees did they generate and how much traffic have these servers seen?

You are mentioning others are implementing something similar. Could you name them? Do you have any info about their use, so that xGovs could assess better if there is demand for such a product?

Regarding controversies, I was referring to your past proposals - AF watcher, where the value was promoted to be in its execution, consistency, maintenance and contributions to the ecosystem, while the watcher was offline for a substantial time after the proposal was approved; as well as w.r.t. the last proposal, which served as a basis for this one, was flagged by the xGov Council as non-compliant with the program’s T&Cs. The proposal was also rejected by the majority of xGovs.

IMO, without open-sourcing in advance, it is highly unlikely there will be a different result this time. W.r.t. the efficiency of the ecosystem, it would be beneficial that the proposal would be resubmitted only if it were materially improved.

5

Note that we were referring to $20,000 in Algo relative to the price of Algo observed at a previous point of time.

20,000 Algo more or less was generated from this AVM email platform — the remainder came from other sources, mainly the AF Watcher proposal.

I commented on a reddit post where someone used ephemeral keys, they seem to have had no content on their reddit or their GitHub aside from their own implementation of an MVP similar to AVM Email in terms of theoretical approach, but not quite at our level of implementation, which I found strange.

Regardless, that application is not in production to my knowledge and is not smart-contract based, they use note fields exclusively via outer transactions, where as we have a fully built, in-production, smart contract pipeline and infrastructure.

They also have no metrics to share either, so that is something important to take note of; seems to be vibe-coded as well, and their encryption method was not bidirectional. They claimed that it was adjusted to be bidirectional, but they mentioned they used non-ephemeral keys, this is a contradiction and just makes no sense.

There have been replies to that subreddit post but they do not seem to be active anymore, this was about 2 months ago if I remember correctly, I believe they lost interest once they saw a platform had already had a complete version of what they were working towards, but of course I cannot speak for them, their sudden appearance or respective disappearance, but we commonly see grifts pop-up and go that do things like this often. They copy-paste existing implementations of something onto different chains and change the banners, use bare minimum chain-specific integrations and try to seek something from it. I do not have a link to their implementation but it can be searched for on the subreddit if that is in your interest.

Regarding the comment based on past controversies, I will comment my response as you commented there similarly as well:

Regarding the AF Watcher, which I am not too fond to see coming up again — the watcher going offline was out of my control, and out of my observance. I still stand by the fact that no one reached out to me to let me know it was offline — the X API free tier was deprecated, and I have since then not only converted to the pay-per-use subscription plan as a courtesy but have also upgraded the watcher to monitor and tweet new proposals as well as daily proposal summaries since then.

We also began working on and provided a discord alternative immediately, but only 3 or 4 people used it — I would appreciate if these things were taken into consideration, and not used as a reason to force us to open-source unconditionally if we want to pursue funding, as I don’t see others having this restriction applied to them mandatorily.

I would also ask that you note you asked for material improvement here as well, correct me if I’m wrong but I believe you were referencing content from the other proposal and that would not apply to this fully built platform.

6

~ @uhudo I discussed with team and the consensus is we just open-source the Gainify contracts, Algofun Shares System, and AVM Email contracts — they are minimally documented and will contain no test files, frontend codebase, or any other supplementary files. We understand the risk of blindly accepting proposal TnC for conditional open-sourcing right now and feel its the least we could do to make your lives easier. We have uploaded Gainify contracts so far, we will add AVM Email & Algofun Shares System by tomorrow.

Edit: All contracts added 04/06/2026 10PM EST

atsoc1993/xGov-Proposals-Contracts: The Contracts for the Algo.fun Shares System, AVM Email, and Gainify Staking

7

About the formalities, the currently shared repo still does not meet T&Cs.
An open-source license is missing and the repo hasn’t been added to Electric Capital.
I also think joining again all proposals in the same repo adds back the confusion about the proposals.
Just sharing the contracts without the accompanying tests and documentation, i.e. a partial proposal, IMO still doesn’t meet T&Cs (while I know some other xGov Council members are more lenient on these points than me).

I’d advise you to focus first only on this proposal. Check how some other proposals that approved were presented and documented, e.g. PCG Random Number Generator.

8

Ok — we will place Algofun Shares System & Gainify proposals on hold — then for AVM Email, fully open-source, add license, document, and add repo to Electric capital. ~~

9

Hi @uhudo — we have open-sourced the entire platform and created a PR @ Electric Capital:

Adding encrypted email platform repo by atsoc1993 · Pull Request #2814 · electric-capital/open-dev-data

The Repository itself can be found here: atsoc1993/AVM-email: Identical utility with additional features and a complete UI revamp

MIT License included.

10

Great. I think this has the highest possibility of succeeding.

I’d just advise organizing the repo a bit more, e.g. by adding an overall README, in particular as test, setup and contract files are all joined in the same folder. Also, if you have any tests that assert the functionality rather than just to demo the use, would be helpful.

Consider also rewriting the proposal itself based on this whole discussion.

11

Yes, we will tidy up the repo ASAP — the proposal has different text than this forum post and I’ll make that match as well.

Thank you for your patience in all of this @uhudo and anyone else keeping track in the background, we didn’t make keeping up with us easy and that didn’t deter you from continuing to help us.

12

Just as an update we’ve reorganized the repo, just thinking of some “non-execution” tests we could add, it’s not too straight forward but maybe for the offchain logic. We’re also working on a nice readme that lays out the key logic / flow behind AVM Email, which I think will be most important

13

Stop wasting your time and money…:wastebasket:

14

We think the repo is in a good place if you wanted to take a look and provide any feedback!

15

The repo is now closer to what I’d expect but please double check it as the README does not correspond to the actual folders.
Once everything is aligned, consider merging it in main for clarity.

Regarding the proposal itself, I’ve noticed you increased the ask from 125k ALGO to 200k ALGO.
I’m wondering what prompted the increased ask?

Your also mentioning the product was guided from previous CTO. Does this refer to JAW?
If so, to what degree was he involved? Why is he not listed as part of the team?

As part of the metrics, I’d put the number of servers created, on-chain users, emails sent, fees generated, etc. Not just “community”.

16

Good evening @uhudo —

  1. We made the readme more descriptive and accurate, I think you’ll like this version — main is now the default with all the updates we made: atsoc1993/AVM-email: On-chain Encrypted Communications and Decentralized Finance on the Algorand Virtual Machine

You’ll notice new/enhanced sections for:

  • Folder Structure
  • What AVM Email is
  • Contract System Overview
  • AVM Email Flow (Server creation, email creation, sending emails, receiving emails, allow lists/junk mail
  • Naming Model
  • Encryption Model (deterministic encryption account methods, salt usage, how storage works for all this information, etc.)
  • Tokenomics, Fees & Commissions (server registration, initial email purchases, buyback + liquidity / burn behavior, marketplace fees)
  • Marketplace Flow
  • Server Configuration
  • Private Staking Pools (Requires owning an email under a specific server to be whitelisted)
  • Some core utilities / helpers
  • Prereqs
  • Contract compilation instructions
  • Running integration scripts for email & staking demos
  • General pytests

  1. Regarding increased ask — we spoke amongst the team and there was a consensus that we increase the ask amount. We weighed out the amount of work that was done, compared to other [valid] xGov proposals that were submitted and approved, and noted that we did not decide on an ask amount together when the proposals were split and the ask amount had not been criticized yet by the team. We do feel its a fair ask — although I understand it can be speculative.

  2. Regarding the JAWS reference, we added a note in the readme under the Encryption Model section regarding this as well, but I will paste a snippet here:

image
image696Ă—261 15.1 KB

  1. I’m not sure if you’ve seen the adoption metrics on the xGov Platform for our proposal, but I’ve updated them here on the forum to match them — if you don’t mind, ironically, we do not have a notable figure for total emails sent, but I was able to get the number of unique email addresses. I have included a script for finding both of these new metrics in the repository under scripts/email:

Adoption Metrics

  • 39 Servers Created
  • 46 Unique Email Addresses Created
  • Greater than 40,000 Algo in Fees Generated
  • 7 Puyapy Smart Contracts
  • Bidirectional Encryption for Encrypted Communications

image
image965Ă—440 23.6 KB

17

Thank you for incorporating the suggestions. I think the current proposal quality is overall improved.

That said, as the ask has now been increased, i.e. almost dubbled to 200k ALGO (while the past proposal requested 300k ALGO for three products), I am skeptical it is justified as neither the delivered work nor the traction has materially improved since then, thus IMO approving the increased ask would set a bad precedent for the xGov program.

Comparing the ask size of different proposals is difficult. E.g. the PCG random number generator library requested only 32k ALGO for implementation in 4 languages and with traction of being used in multiple products, including in Tardly NLL with 0.6M ALGO staked.

Hope to hear the thoughts of other xGovs too.

18

Thank you for all your help again @uhudo

It absolutely is a spectrum of work/asks on the xGov platform. I can only speculate that the PCG random number generator proposal was truly a humble ask from a seasoned developer we were lucky to have on the DevRel team.

I would greatly appreciate feedback from other xGov council members as well, if there’s anything we can iterate on outside of the closed-product that would make them more confident about approving the state of the presented work we would happily pursue it.

I guess these will be my last words here unless there are any other comments. Of course we cannot do anything about the lack of users / adoption of our platform, in an ideal world this would not be the case, and maybe there were things we could have done differently. But we feel the concept was executed well, the documentation is clear and descriptive, and the product was carefully crafted and open-sourced ahead of time.

We are here for any other requests, and we apologize for the confusing path to get to this point where we had a conjoined monstrosity, followed by 3 separate proposals. We discarded the other 2 proposals until they materially improve — but we feel this proposal is in a good place, and hope that sentiment is shared.

Thank you all again for the efforts already made so far and any to be made in reviewing this proposal.

19

So this proposal has come a long way and it deffinitelly shows willingness to adjsut/accomodate feedback.

The traction and user growth is somethign entire algorand is struggling with so lower number of users doesn’t neccessarily mean there is no demand for such product.

Personally i’m supporting this proposal, as the functionality is unique and it has value. However i also feel the ask is on the higher end of the spectrum, but it’s ultimately up to xgovs.

20

The proposal is good, the willingness to meet standards and collaboration is very nice , just if the ask was a little bit more modest, it would have been what I fully support. as of a frank suggestion, I would love to see this proposal’s ask in 100-120 and not more. if you adjust that It will become 100% fit in every sense. Currently, the ask ratio to effort is not justifiable IMHO.