Meet the Trojan Foundation (Aragon users)

Hi everybody! First of all, sorry for writing a book here. I’m posting this on behalf of the team behind a forthcoming DAO called the Trojan Foundation, which will use Aragon tooling for its governance structure. We believe that the DAO use case we’ve devised, which we describe below, is quite novel. We’d very much like to talk to an Aragon team member to share our ideas and get an insider’s insights into how we might tackle a couple of governance challenges that have proved sticky for us so far.

The Trojan Foundation will be a cooperative, non-bureaucratic organization which allows artists (initially, artists based in Athens, Greece) to collectively govern a community wallet. The funds in this wallet may be used to finance members’ art projects and, when necessary, dev bounties. The point is to allow artists to share both the economic risks and opportunities inherent in being cultural workers by capturing more of the value created by their work and distributing it to finance new projects (based on the outcome of votes.)

This type of solution could prove useful to artists worldwide, as many of us must contend with irregular income and other financial challenges, including a steep barrier of entry into the “cultural economy” and slow, costly bureaucracy. Greece is a logical starting point for this project because we’re dealing with austerity and capital controls that make it very hard to access funding in euros – but ETH is not affected by these constraints. What’s more, we have an enthusiastic and growing group of artists, both connected to the crypto space and not, helping to think through this system and eager to start using it.

Among the features that will be central to the Trojan DAO are a token bonding curve (our team has invested significant time in bonding curve research), a shared community fund, a REP voting system, and simple UIs. These interfaces should make it easy for people completely new to the space to create proposals, vote on allocating resources to projects that the community finds important, and interact with the bonding curve.

Clearly, there’s a lot of overlap between Aragon’s offerings and our objectives. However, we feel like the nature and scope of what we’re aiming to do (creating a financially sustainable fund governed by and for art workers) make us different from a lot of the other DAOs out there. For that reason, we’re hoping to secure a little bit of time with someone from Aragon so that we can lay out in more detail what our objectives are and what kinds of obstacles we expect to encounter along the way. Hopefully, you’ll have insight into how we can tailor the different components (e.g. the REP system) to our needs so as to create a functional on-chain governance system.

We believe that the Trojan Foundation is well positioned to become a unique Aragon success story, and we’d be deeply grateful if you would share a bit of guidance with us along the way.

Thank you so much for your time!
Adam Reese, James Simbouras, and the Trojan Foundation


Hey Adam et al., first off, welcome to the community.
You may find that ‘official’ members (employees) of Aragon are super-busy, esp. around this time, during the preparatory run-up to quarterly votes.
Perhaps may be equally useful asking for some community member input, there are people around with wide-ranging knowledge, interest and experience - we may, at minimum, be able to point you in some useful directions.
I’m unsure tbh whether it’s technical know-how or governance type input you’re looking for, so perhaps if you spell it out (preferably in bite-size pieces) we can all wade in and then see what happens:)

Looking forward to hearing more, certainly an interesting sounding project, and one e.g. which chimes significantly with many of my own research interests.

Cheers and all the best,


Welcome Adam, James and rest of the team.

Cool to read- agree with @Julian that it would probably be more helpful if you could layout a set of questions that you’re working through at the moment so that we can tackle each one independently in an async fashion

1 Like

Hi @Julian and @stefanobernardi,

First of all, thanks for the feedback. And Julian — I hear you, we’re definitely interested in getting input from everyone on this forum, not just employees. The guidance we’re looking for at the moment is guidance on choosing features of our governance structure, not on implementing those features via code.

I’ll try to keep it brief and avoid going into unnecessary detail (which is easy to do when discussing these kinds of projects, as I’m sure you know.) For now, I’ll lay out a few of our more pressing problems.

  1. REP voting system:
    Do we choose a yes/non-vote type of system, or a yes/no/non-vote system?

It seems that the default, or most common type of voting system, allows for yes and no votes, but I’m not sure such a system would really suit the types of votes we’ll be holding. This is because we want project proposers to focus on promoting the merits of their own projects (seeking yes votes for themselves) rather than denigrating their “opponents’” projects (seeking no votes for others.) From where I’m standing, the only time I could imagine wanting to vote “no” on a proposal is if that project aims to push a socially extremist viewpoint (e.g. race hate, Islamophobia, etc.) So to restate the question: is the better option to find/build a “yes only” voting system, or to adapt a “yes/no” system to our particular needs. If the answer is adapt a yes/no system to our needs, what might that entail (again, at the governance level, not the software level)?

  1. REP depreciation mechanisms:
    We believe we’ve settled on a workable set of mechanisms for issuing REP, but what about diminishing the power of existing REP to prevent long-time members from holding onto power despite recent inactivity? There seem to be several possibilities for how to achieve this, but we’re a bit stuck when it comes to picking one.

  2. Limiting single-voter influence:
    How do we prevent individual voters from amassing so much power that they can single-handedly fund a project, against the wishes of every other Foundation member? We’re considering a couple of options: limiting the number of tokens per voter per project; requiring not only a threshold of yes votes at the token level but also a minimum number of yes voters in order for a project to be approved; simply setting a ceiling on how much REP one may amass.

  3. Best mechanism for directing financial flows back into community fund?
    There are likely going to be several ways that funds generated by projects may find their way into the community fund. The heart of the question is: should there be a mechanism for participants on financially successful projects be able to “squirrel away” funds to use on a future iteration of that same project? (Personally I’d say no — it cuts the community out of the decision-making process and privileges projects that succeed financially over projects that succeed in other ways — but we the Foundation are still talking through our options on this question.)

There’s more, but this is plenty to begin with.

Thanks so much in advance for your input!

Hello Julian and Stefano, thank you for the warm welcome!

I think Adam has us pretty covered concerning the initial questions that we are seeking guidance on. I would like to add that the Trojan Foundation is an incubation project at DAOincubator, which brings together builders, activists, and researchers fostering cross-project pollination and conducting integrations fundamental and practical research on behalf of DAOs.

Thank you very much for your input!
All best,