Venture Moloch Designs

Greetings MolochDAO! :space_invader: Ross Campbell here from OpenLaw and other stuff.

I have been following Moloch’s most recent proposed “v2 upgrades” with keen interest - :mag_right:

Specifically, I am studying the Moloch code for a fork more attuned to investing rather than pure grant-making, with ‘The LAO’ as a proposed model to launch with a limited liability proxy (brief overview of ‘vmLAO’ extensions here).

As different groups w/n and outside of Moloch DAO refine specifications for Solidity that would support a variety of fundraising requirements (multi-token support, more advanced withdrawals to realize profits, etc.), I thought it would be highly worthwhile to start a thread here and kick things around, scope out different implementations of Moloch v2 (I imagine different business plans might entail tailoring, but yeah, this is exactly the kinda stuff I want to field…).

Among my initial design decisions in vmLAO:

  • Removed proposal deposit/fee mechanism: this feels unfamiliar to venture funds, and not sure if friction is worthwhile where we might have membership agreements and also adopt a form of ‘guild kick’ - lemme know what you think! (lkwyt)

  • Support multiple token types: I basically wanted a lightweight way to push token exchange into proposal mechanism (so, proposals might entail funding, membership, or hybrid request). Still not settled on if membership and voting proposals should be separate tracks, but I like having familiar voting setup from Moloch, with minor tweak to allow tribute tokens to be any token, modest value tracking, and a base ‘contribution token’ to reflect member economics - lkwyt

  • Track voting and economic weight separately: In Moloch, votes reflect equal claims on the guild bank - I wanted a way to account for a member making a large economic contribution and getting a fair claim on the bank but avoid whales overwhelming voting pattern; I am still studying how Moloch might generally prevent this just through diligent voting, where Members seem to be able naturally select how much influence should be given for whatever contribution amounts. So, this might see some tweaks in our review - lkwyt

Otherwise, glad to join this Forum, learn more about MD community. Cheers :v:

Removed proposal deposit/fee mechanism

This could be OK with a guild kick mechanism. One advantage of the processing fee (currently set to 0.1 ETH) is that proposals are always processed when anyone visits the UI.

Support multiple token types

The security risks of this are non-trivial, which has led me to implement both an ERC20 whitelist (and a separate proposal type for whitelisting), as well as an emergency escape hatch just in case a malicious token is whitelisted.

The token whitelist is the first line of defense but should we whitelist a token with an address blacklist like USDC, it’s possible that we could end up with the DAO proposal queue completely frozen. Here’s how:

  1. We add USDC to the token whitelist (via proposal)
  2. Alice submits a proposal and offers USDC as tribute
  3. The proposal does not pass
  4. Before the proposal is processed, Alice’s address is added to the USDC blacklist
  5. When someone attempts to process the proposal, it tries to send Alice back the USDC, but her address has been blacklisted so the entire processing transaction fails.
  6. No other proposals can be processed either because proposals must be processed strictly in order, and so any tribute funds held in escrow by later proposals is stuck indefinitely.

Proposals have to processed strictly in order or else because of the constraint that you can’t ragequit until the highest index (most recently submitted) proposal you voted YES on is processed. So if you voted yes on proposal 10 and want to ragequit proposal 11, you want to make sure proposal 11 doesn’t somehow get processed before proposal 10.

I suppose we could relax this constraint, but then it would become the responsibility of the person who wanted to ragequit to process the proposals, which isn’t too much extra work if you plan to ragequit anyways…

But more importantly, the escape hatch I mentioned allows a stuck proposal to be processed if after a sufficient amount of time has passed (e.g. 1 week) it still has not been processed.

// If emergencyExitWait has passed from when this proposal *should* have been able to be processed, skip all effects
bool emergencyProcessing = false;
if (getCurrentPeriod() >= proposal.startingPeriod.add(votingPeriodLength).add(gracePeriodLength).add(emergencyExitWait) {
    emergencyProcessing = true;
    didPass = false;

This would then SKIP paying back the tribute to the applicants under the assumption that the ERC20 transfer is failing and will continue to fail.

// Don't return applicant tokens if we are in emergency processing - likely the tokens are broken
if (!emergencyProcessing) {
    for (var k=0; k < proposal.applicants.length; k++) {
        // return all tokens to the applicants
            proposal.tributeToken.transfer(proposal.applicants[k], proposal.tokenTributes[k]),
            "Moloch::processProposal - failing vote token transfer failed"

Here’s the code for the above.

Two final points:

  1. It’s likely the members would still have to all ragequit if a whitelisted ERC20 broke, because any member could still troll the DAO by submitting additional proposals using the broken token as tribute.
  2. Being able to eventually unstuck proposals would mean any proposals after the stuck proposals would eventually return escrowed tribute offered (in non-broken tokens) to the applicants.

Track voting and economic weight separately

This was actually in the original MolochDAO design in the form of Loot Tokens, which were intended to be transferrable but have no voting rights and the counterpart to Voting Shares, which had voting power but were not transferrable (as they are in v1 today). The idea was that you could claim Loot Tokens by burning your shares 1:1, and claim the proportional share of Guild Bank assets by burning your Loot Tokens.

I’m currently considering adding Loot Tokens back in to allow for the very case you’re describing, where a whale wants to join and the members want their money, but don’t want to risk them getting too much voting power. Instead of receiving 100% shares, they could receive 10% shares and 90% loot.

Thanks for your notes! Looking forward to seeing where this goes!

1 Like

Support multiple token types

Take a look at what James Prestwich and Matt Luongo are doing on tBTC. I would expect them to expand the scope of that project. There are definitely certain security risks with allowing different token outside of ETH/ERC20 and so it hasn’t been seriously contemplated by any DAO team to date, but we also must recognize that there could potentially be considerable upside. For now, you could hold wBTC, which is arguably a substantial fund position for any professionally managed fund. Ethereum is certainly where the most interesting income generating opportunities lie at the current juncture, so if you fish where the fish are, you’ll make the trade off to stick to ERC20s for the foreseeable future. To the extent that FIL, XMR or a few other assets are interesting to have some exposure to, you could handle it through 3rd party custody services since you’ll be an LLC and can make those types of off-chain agreements (however, that is a whole other problem in itself and is less interesting philosophically. However, that is a topic for a different thread).

The security risks of this are non-trivial, which has led me to implement both an ERC20 whitelist

The whitelist would have to be performed by a ‘standards DAO’ separate from the MV-DAO otherwise you have an attack vector whereby a well endowed group could attack the MV-DAO by buying up votes to control or influence the whitelist and then arb the whitelist. Imagine the jump in shitcoinX once it’s approved on the whitelist on Moloch. Whitelisting is a tough point of centralization as highlighted by the SEC DAO Report (
It would be interesting to understand the escape hatch further.

Remove proposal deposit/fee mechanism

I disagree that there isn’t a minimum stake posted in traditional venture processes. Teams have to get to a certain point in their PoC, build a deck, travel around and do a road show and employ a minimum team to be taken seriously. Having a minimum bar for professionalism makes sense imho. In fact, I would propose a staking mechanism where individuals could stake to get a project evaluated more quickly and potentially increase their attribution associated with that deal. This would allow the most professional projects to bubble up faster.

Track voting and economic weight separately

Tracking performance and decision making over time:
IMHO Ownership capital is totally separate from reputation garnered from making good decisions. This is the relationship between LPs and GPs in traditional venture. Here we can make for more transparent evaluation of performance. Lot of issues there to be resolved over time though.