Simplifying Proposals - A Discussion

This subjects pops every now and again, and in the last ApeComms @Lost and I bantered a bit about how best to address it.

As a software dev and a detail oriented person, I simply cannot be trusted to simplify anything (in case you didn’t know, back in the day, my Battlecruiser series of games sparked the RTFM movement) related to committing thought into few digital words. And so, I have refrained from writing up an AIP for this; instead, opting to get some ideas from the community to see if it’s even an issue worth addressing.

So, what’s this all about, then?

Some proposals are highly technical and/or wordy in their nature, thus requiring copious amounts of words and images. This despite the on-going premise that apes (not all of them, tho) either don’t like to read or don’t read at all.

The complexity of some proposals warrants a lot more attention from the voters who need to absorb and parse this information in order to make an informed decision before voting. And therein lies the rub.

The other aspect to this, as @JasonJape also mentioned in the same ApeComms section, is that while Discourse has a translation option, most of the time it doesn’t work as expected.

I don’t see how else the AIP Draft Template could be simplified. But that may not even be the issue.

From my view, perhaps we need two specific naming conventions and descriptors as follows:

AIP Draft Template - Simple

This would be the pre-existing version which needs no further revisions.

AIP Draft Template - Advanced

This would be a new version which, while having all the same fields as the simple version, also has sections additional [technical] sections.

Though it may not even need any such new sections, the category of the draft itself should probably suffice.

But if we went this route of adding a new technical section, how does that translate over to name/number when an AIP number is assigned? Perhaps Lost’s idea in AIP-451 provides a solution. One of the points in that proposal is:

While I have no idea how that was going to be implemented, perhaps we could adopt a naming and/or numbering convention that identifies whether an AIP is a simple or advanced version.

For example, we are currently around AIP-46?. We could keep this numbering scheme as-is for simplified legacy proposals, while adopting something like AIPA-nnn which stands for Ape Improvement Proposal - Advanced, as in AIPA-0001

Doing it this way preserves the pre-existing draft contents and sections, while the numbering scheme in the proposal name is what prepares voters for an extended read.

Then the question becomes, how does an author know if their proposal is a simple or advanced version? Perhaps a word count?

Let me know what you guys think.

Some examples of an AIPA:

AIP-444: Growing Wellness: Home Harvest’s billion dollar opportunity to improve the way we live & eat, powered by grow2earn
AIP-418: APE Builder Developed by Sequence
AIP-396: LFG VENTURES presents: Made by Apes - Powered by ApeCoin
AIP-364: The Battle for Goblin Town - A Bored Game
AIP-316: Fantasy MMORPG Game - Powered Exclusively By ApeCoin // This was mine
AIP-133: Boring Security - For The Long Haul!
ApeLance: WEB3 Freelance Marketplace on ApeChain
The Boring Artists Agency: Bringing Billions of Dollars’ Worth of Game Dev and Publishing Talent to Web3


Thanks for the discussion.

I agree that short proposals should be easy to read. However, it’s crucial to ensure all aspects of an idea or business are clear and well-researched. In my case, there are many competitors, and the goal is to attract users who are new to crypto. This makes it essential to include reasons, statistics, weaknesses, and advantages.


write small, stay alert, write brief and focused…stay Simplified

1 Like

There also should be a rule where undoxxed people can’t make bold and unverifiable claims under the AUTHOR section.

We saw trippy remove his multiple awards claim on the bananas bill which was only right, but we need to stop these often long and unnecessary self indulging author descriptions - unless ofc they can be verified by the readers.

I read a proposal by Lost about two days ago and the author intros were longer than the AIP itself. After a couple of lines I got bored and didn’t bother to read most of the actual substance and skipped to the end.

My main issue is that I see lots of bold claims in both author descriptions & throughout the AIPs themselves. So when reading them they feel more grift like at times than anything of real value and the author has often lost me as a supporter right out of the gate.

So tl;dr here is that:

  1. AIPs should be more factual especially under the benefits section.

  2. Author section should be limited to VARIABLE FACTS only.

I’ve seen people describe themselves as “visionary founders” :person_facepalming: - my point being we need to move away from all the nonsense language and grift like tactics; get back to basics & insist on more provable factual information as readers.

1 Like

I agree.

FYI, I had to modify all my 12 proposals because I was notified that I needed a full author bio instead of the one line that I used. In my case, to do a detailed one would be expansive. I mean, I hold 4 degrees and several institutional awards over my career; as well owning two dev studios managing over 50+ people around the world individually or via external teams etc.

Around here each time you talk about knowing who people are behind the aliases, some try to argue the merits of doxing v privacy. Go take a look at my AIP-464:


This I agree with.

However, regarding your point about doxxed vs not doxxed. It is a bit more nuanced: if the author has already completed KYC with the foundation, where they have background checked the author, then the claims are not unverified; however a new author who has not done KYC perhaps should be more concise or limited on what they write here.

Out of interest what was the claimed awards from CT?

It’s not nuanced. We already know that authors do get KYC in the background. It’s about making the authors known to the DAO community. The Ape Foundation works at the behest of the DAO and so, the DAO is entitled to whatever info it requests. e.g. in my AIP-464: Future Election Leadership Requirements proposal, I specifically make this point about authors being publicly KYC during elections.

You can use the pencil in the AIP-454: The BANANA Bill: Apes Gotta Eat to review changes between rev 1 & 2.

1 Like

We all want more people to join the DAO and hopefully apechain and the 100m helps, but I’m just a little concerned that our processes are not as robust & diligent as they can be, and potential consequences as the masses arrive.

For example - if an author writes an AIP to swap our $ape into BTC, ETH, SOL etc etc and under author claims are made of multiple relatable qualifications and years of experience for top banks, should these claims be verified in such instances? As the author statement is part of the AIP and helps sell the idea. (I’m pretty sure even when the author does KYC to receive the money if the AIP gets voted through the author claims are not checked retrospectively.)

The other question then arises of how practical it is to do so and is there even a way of doing this easily? The only solution I could come up with rn is limiting the author section to DAO member unless for example, as you highlighted, they’d had KYC and background check done for say an election and this information could indeed be confirmed as verified.

I just feel that with the new chat section, discord, twitter, TG, and all the other ways people communicate within the DAO, could the discourse forum not become a more factually verified place? And would this set us up well for the numbers that are expected to come?

In regards to CT - I think it was kodama made a comment on twitter and wanted more details around the claim, and then it was removed. Which made me think if there was some sort of way to say VERIFIED it could have remained with no further explanation needed possibly.

Self indulging descriptions - I just find them funny to be honest and they’re pretty harmless ngl - but are they necessarily needed and a good thing? Perhaps the Ape_U coaches program makes AIPs better and this naturally becomes less prevalent.

Thanks BB & Derek :handshake::handshake:


IMO yes, as they’re core to the value proposition that author is making about their AIP. Even if it’s not true KYC, we’d want trusted sources to do the leg work and stand behind the information they present.

1 Like

Love that - core to the value proposition - exactly that. :handshake::handshake:

1 Like

Good thoughts here Derek, but I do have thoughts.

The AIP Draft Template needs work. Right now, there is no area to actually expand on specific, particularly important, deeper-level, and technical concepts.

I’m also more of the mindset that rather than looking to shorten or simplify our non-repayable grant process for authors to receive (often times large amounts of) funding, we should be increasing our efforts to provide them with more visibility through promoting stronger engagement with voters, and in-turn offering voters more digestible ways to consume what’s being proposed.

This is good to know, as I have long wanted to see us do better. Another question for our bilingual community members is how reliable different browser-based translation tools are.

With ApeCoin participation growing rapidly overseas, it may be time to start looking at more effective strategies in this area.


Indeed. I believe that the removal of the ‘abstract’ section wasn’t a good idea because that’s where pertinent info could be conveyed. However, I believe that authors should be free to add whatever [optional] fields and headings they want; as long as the mandatory fields are in place. This way, we don’t find ourselves editing the draft once again because it’s likely to be deprecated again at some point in the future.

Those are two different things though.

  1. The disbursement of funds should be revised for expediency. The bottom line is that once the DAO has voted for funds to be disbursed, there should be no road blocks because anything related to transparency, accountability etc. should have been addressed during admin review. We can’t continue putting the cart before the horse while expecting to streamline ops to any reasonable extent.

  2. As to providing more visibility to authors, I agree. However, I’m not sure how we would even do that. Especially given the low engagement that ALL the community outlets (social, Discord, Discourse) etc. continue to experience. You can only do so much within a bubble that’s not growing - while not engaging.
    As I mentioned in a recent UGH Spaces with @G_is_us and others, what we’re missing are activities that engage and incite the community. Given our relationship and proximity to them, I used Moca as an example of a engagement community. I have been working on some ideas on how to do something for the community here, but I don’t have much faith in our community engagement, let alone the voting process. And so, I don’t see how anything that I come up with could possibly amount to anything but wasted time and effort. I have to admit, it’s disheartening, and it’s the same or similar despair and frustration that’s holding our community back. You being one of the most uplifting and positive people in the community, must know this already.
    Also, I am vehemently opposed to proposal campaign activities because it is counter-productive and burdensome in so many ways. I just wrote a lengthy missive about specifically this.
    If builders come here and write up a proposal that makes it to vote, the onus is on the community to review what they’re voting on. That’s on the community not the builders. This burden, the voting gauntlet and uncertainty aside, is precisely why we’re not growing. And it’s another reason why we must [collectively] endeavor to review our voting system.
    As I type this, we have had several proposals funded for activities like this - and nothing has come from them.

It’s an issue with the translation tool built into the software. There are far more advanced AI tools that do exceptionally good translations now. We should probably look into those. But then, seeing as they are external processes, we would need someone to manually run them through the AIPs. And therein lies another problem: How do we know if something needs corrections or tweaks if we don’t have people in the community who are familiar with both English and the target language?

Another idea that I have been toying with since that UGH Spaces would be to do audio translations of the final proposals. It is common knowledge that audio translations are far better than written ones. And so, in each final proposal, we could then have a link to supported language audio (even English) for people to listen to. I am working on a proposal for this, but have yet to put it up because I am also working on three proposals which I haven’t yet had time to finalize due to my schedule.