Setting up a multisig; initial EOI and preferences survey

Now that a liquidity mining program and new pools have been implemented, it is a good time to start collecting different opinions and expression of interest in relation to setting up a governance multisig to reward Key Contributor Roles, or alternatively propose a different model to trustlessly distribute TORN.

Following up on this conversation

Listed herein are the top 10 community users, but as discussed in the other thread anyone is free to express their interest; it is important to note that the main condition to be a multisig holder is a genuine commitment to ensure weekly-biweekly availability to sign transactions, ensure remunerations stay effectively proportioned to community efforts and whatnot; this is not a honorary recognition.
Ideally we would want a majority of non-anon holders, and also at least one non-community member, better if coming from an existing project. Multiple choices allowed.
Second, the community shall decide how many TORN shall be released; two choices allowed in order to specify your preferred range (e.g. 5% to 10%).
Anyway, this thread will serve as an informal initial screening to collect community sentiment.

Please vote for your preferred multisig holders, or express your preference over a different governance model (please elaborate)
  • poma
  • Rezan
  • ethdev
  • optionsmate
  • gewitet
  • luke_lo
  • samkazemian
  • skybizze
  • gebib
  • Byron-McKeeby
  • [other (please specify)]
  • [I am against a multisig, would rather go for a batched governance proposal instead]
  • [against multisig AND against batched governance proposal]

0 voters

If anyone listed herein receives strong community supports however does not wish to be included in the multisig, they are welcome to specify it here.

Please vote on the budget as a percentage of the 275k initial TORN + 91.6k monthly TORN vestings:
  • none
  • 5%
  • 10%
  • 15%
  • 25%
  • 35%
  • 50% or more
  • [other (please specify)]

0 voters

Expressions of interests / questions / objections are all very much welcome.

3 Likes

Many questions.

First, where does 275k inital torn + 91.6k monthly torn vesting come from?

Second, if we pass the proposal of setting up a governance multisig, does it mean that the 10 sig holders can determine the future TC decisions and we do not need the proposal voting any more?

1 Like

Thanks for setting up this discussion.

I think we should confirm with the Tornado Cash team/devs directly on whether they want to be involved in this.

They might have legal concerns to consider, and so far they have been really careful about not engaging in any activates that could jeopardize the legitimacy and/or legal standing of the Tornado Cash.

I just want to be sure we’re not stepping on any toes before attempting to vote to add them to the multisig.

Otherwise, I would personally love for them to be a part of it!

I also want to say that it’s nice to see something like this. Having been part of the Tornado Cash community since the very early telegram days and since the creation of the discord channel. I love seeing how organically we’ve grown.

2 Likes

@zhubingjie
Sure thing. Questions are very welcome if anything is unclear.

  • As per initial announcement, TORN has a fixed supply of 10M tokens of which 5% of the supply was airdropped to previous users, 10% will go to liquidity mining rewards (distributed linearly over 1 year), 30% to founding developers and early supporters (unlocked over 3 years with a 1 year cliff), and 55% to the protocol treasury (unlocked linearly over 5 years with initial 3 months cliff just happened last month). The latter category is where these TORN will be unlocked from. In the second poll I am staying relatively low with %s to avoid giving too many TORN to the multisig, which is probably good to avoid especially in the beginning.

  • There likely won’t be 10 multisig hodlers; probably 3-5 would be good to start things; this will be discussed on the next stage once all EOI have been submitted and community sentiment reviewed.
    Multisigners would simply execute the will of the community. No specific additional power granted; furthermore, multisig singers could be added or removed by on-chain governance whenever needed.
    The current process for what concenrs proposals for protocol changes would remain extant.

@skybizze
Thank you and I agree. Certainly; as I wrote, anyone mentioned here who is not interested in becoming a multisig holder is welcome to say that in the thread. The poll included the 10 most active forum participants as this is what was previously discussed, but it is just a very indicative initial list (it’s also missing a very prominent member like rstorm) to get thing started with a survey and encourage discussion.

oh I did not expect to be on this list. I am comfortable being a multisig holder, and have some experience being a keyholder for other groups.

In general I wonder what the multisig would be formed to accomplish? What budget are we seeking to ratify and what plan are we looking to carry out?

Good to hear. The multisig’s signers will execute the community’s will in relation to TORN distribution (or discontinuation thereof) to KCRs and other remunerations and allocations as decided by the community.

Are we establishing something like a grant committee? What actions will be in the purview of the multisig as opposed to governance?

1 Like

My go-to choice would ideally be Rezan or Poma but I highly doubt they would want to have any part of this for legal reasons.

This is why I voted for @ethdev who I have had the pleasure to talk to on multiple occasions.

He is very knowledgeable and sounds like he is perfectly in line with the tornado.cash long term vision.

1 Like

That probably would be the ideal long term solution.

The only alternative solution I can think of is a Mini Grants DAO where Key Contributors regularly submit a proposal where they summarize their recent contributions along with the relevant reward.

This assumes further bureaucracy though, increases the complexity of the tools we use (dao platforms are still very limited) and involves paying a lot of fees (unless the platform is on L2).

Given all the points of my last sentence, using a multisig for now (maybe for the first 12 months) seems the best solution.

Very good point. Agreed.


@optionsmate thx for the clarification re. origin of funds/tokens

Makes sense.

I would be happy to be a signer but although a supporter of the project since a long time, I have not gained the legitimacy on this forum (nor on Telegram) yet. I am happy to jump through a few hoops, give a more active push in my community contribution as I have the bandwidth rn and simultaneously accelerate this process.

I would be in favor of that. Although the active community seems rather small now so maybe we can do without it and have a grant process without the committee?

The advantage of a committee though - even if established now - is that we could reward the committee members for fostering a very active community: time spent in sourcing grant participant (outreach), vetting grants, polling the community, etc.

2 Likes

What is the benefit of a multisig vs an on chain proposal for spending of funds?

A formal proposal would have more accountability and transparency. However it may be cumbersome and limit the project from being more agile. Is this the trade off or am I missing something?

Proposals require several days, necessitate custom proposal solidity development, and have a high opportunity cost for voters. It is common to establish a multisig with a limited amount of money that can fund specific initiatives with minimal fuss

2 Likes

Good question.

It is common to establish a multisig with a limited amount of money that can fund specific initiatives with minimal fuss

Pretty much this; you basically semi-streamline regular enough occurrencies and distribution of community development rewards (very relevant thread: https://torn.community/t/remunerate-key-contributors-from-the-community) in order to prevent community decision-fatigue. Drawback of potential signers’ collusion / stuffups is minimized by low initial allocation of funds and signers’ reputation at stake (to which some present an argument in favor of non-anon signers). Once again, signers can be added or removed at any time would the community decide so.

1 Like
pragma solidity ^0.7.6;

contract TornadoCashMultiSigWallet {
    event Deposit(address indexed sender, uint amount, uint balance);
    event SubmitTransaction(
        address indexed owner,
        uint indexed txIndex,
        address indexed to,
        uint value,
        bytes data
    );
    event ConfirmTransaction(address indexed owner, uint indexed txIndex);
    event RevokeConfirmation(address indexed owner, uint indexed txIndex);
    event ExecuteTransaction(address indexed owner, uint indexed txIndex);

    address[] public owners;
    mapping(address => bool) public isOwner;
    uint public numConfirmationsRequired;

    struct Transaction {
        address to;
        uint value;
        bytes data;
        bool executed;
        uint numConfirmations;
    }

    // mapping from tx index => owner => bool
    mapping(uint => mapping(address => bool)) public isConfirmed;

    Transaction[] public transactions;

    modifier onlyOwner() {
        require(isOwner[msg.sender], "not owner");
        _;
    }

    modifier txExists(uint _txIndex) {
        require(_txIndex < transactions.length, "tx does not exist");
        _;
    }

    modifier notExecuted(uint _txIndex) {
        require(!transactions[_txIndex].executed, "tx already executed");
        _;
    }

    modifier notConfirmed(uint _txIndex) {
        require(!isConfirmed[_txIndex][msg.sender], "tx already confirmed");
        _;
    }

    constructor(address[] memory _owners, uint _numConfirmationsRequired) {
        require(_owners.length > 0, "owners required");
        require(
            _numConfirmationsRequired > 0 && _numConfirmationsRequired <= _owners.length,
            "invalid number of required confirmations"
        );

        for (uint i = 0; i < _owners.length; i++) {
            address owner = _owners[i];

            require(owner != address(0), "invalid owner");
            require(!isOwner[owner], "owner not unique");

            isOwner[owner] = true;
            owners.push(owner);
        }

        numConfirmationsRequired = _numConfirmationsRequired;
    }

    receive() payable external {
        emit Deposit(msg.sender, msg.value, address(this).balance);
    }

    function submitTransaction(address _to, uint _value, bytes memory _data)
        public
        onlyOwner
    {
        uint txIndex = transactions.length;

        transactions.push(Transaction({
            to: _to,
            value: _value,
            data: _data,
            executed: false,
            numConfirmations: 0
        }));

        emit SubmitTransaction(msg.sender, txIndex, _to, _value, _data);
    }

    function confirmTransaction(uint _txIndex)
        public
        onlyOwner
        txExists(_txIndex)
        notExecuted(_txIndex)
        notConfirmed(_txIndex)
    {
        Transaction storage transaction = transactions[_txIndex];
        transaction.numConfirmations += 1;
        isConfirmed[_txIndex][msg.sender] = true;

        emit ConfirmTransaction(msg.sender, _txIndex);
    }

    function executeTransaction(uint _txIndex)
        public
        onlyOwner
        txExists(_txIndex)
        notExecuted(_txIndex)
    {
        Transaction storage transaction = transactions[_txIndex];

        require(
            transaction.numConfirmations >= numConfirmationsRequired,
            "cannot execute tx"
        );

        transaction.executed = true;

        (bool success, ) = transaction.to.call{value: transaction.value}(transaction.data);
        require(success, "tx failed");

        emit ExecuteTransaction(msg.sender, _txIndex);
    }

    function revokeConfirmation(uint _txIndex)
        public
        onlyOwner
        txExists(_txIndex)
        notExecuted(_txIndex)
    {
        Transaction storage transaction = transactions[_txIndex];

        require(isConfirmed[_txIndex][msg.sender], "tx not confirmed");

        transaction.numConfirmations -= 1;
        isConfirmed[_txIndex][msg.sender] = false;

        emit RevokeConfirmation(msg.sender, _txIndex);
    }

    function getOwners() public view returns (address[] memory) {
        return owners;
    }

    function getTransactionCount() public view returns (uint) {
        return transactions.length;
    }

    function getTransaction(uint _txIndex)
        public
        view
        returns (address to, uint value, bytes memory data, bool executed, uint numConfirmations)
    {
        Transaction storage transaction = transactions[_txIndex];

        return (
            transaction.to,
            transaction.value,
            transaction.data,
            transaction.executed,
            transaction.numConfirmations
        );
    }
}

This the part of code which would be added to the formal proposal in the future once the community has made his mind, with a few options. Basically a multi sig is a wallet which can execute txs only at the condition that some of the signers approve it (e.g. 3 out of 5).

@ethdev @poma @rstormsf @Rezan wondering if any of you would be up to become part of the multisig, due to popular request :slight_smile:

1 Like

Hey, this great! thanks @optionsmate for writing the post.

Happy to volunteer for the multisig. Note that I am not part of the Tornado Cash team. They do not employ or pay me :stuck_out_tongue:.

I think to goal of the multisig is to have a small part of the treasury available to fund smaller community initiatives. Some examples:

  • Fund Gitcoin grants
  • Remunerate community contributors
  • Fund a security bounty program
  • Sponsor hackathons
  • Diversify treasury funds

One important thing is that the multisig members should commit to implement the will of the community. All spendings should be agreed upon by the community in a loose consensus fashion. Spendings should be made public with ideally monthly/quarterly reports.

As far as I am concern, I would support this initiative and volunteer to be a multisig member. I am long time Tornado Cash contributor and full time dev in an other Defi Project.

I would propose that additionally to maybe 3-4 active community members we add external members that are active in Defi. I would propose @deacix from 1inch and Maybe Ameen Solemani from SpankChain. Both are strong Tornado cash supporters.

I don’t think the core team wants to be part of the multisig but I will let them confirm.

A 3 out of 5 or 4 out of 5 multisig sounds reasonable to me.

@optionsmate I think the best would be to deploy a Gnosis Safe, add the members and create a governance proposal that just transfers the funds to the Gnosis Safe.

I guess the next step would be an application thread. Where multisig applicants present themselves succinctly, describe their contributions to Tornado Cash and their intentions as a multisig member.

2 Likes

If it is possible to recruit people who doesn’t know each other (so avoiding friends & colleagues) so we can’t have problems regarding a potential cartel.

If multisig threshold is high (4 of 5, 6 of 7) a cartel is not very useful since if a small portion of (non-cartel) members disagree the tx will fail anyway.

1 Like

These are all very reasonable. Can you give examples of community contributors? do we mean github? people who have voted/made/executed proposals? that guy with the cool spreadsheet from the other day?

By community contributors I mean hires, part time hires, contractors for doing specific tasks. More on a mandate basis. This can be code, education content/writing etc…

Thank you @rezan and am happy to help; would be great to have @deacix and Ameen Solemani as already active on other projects / non-anon (in Ameen’s case), are you sure they are keen to get involved? Would be good to hear from core members whether they are definitely not going for it so that we can include only viable options when voting starts. Agree about the Gnosis safe part and applications thread.
@bt11ba you make a good point on ideally trying to avoid multisig members who know each other. @poma is right about a high threshold offering cartel-resistance though. The community will decide signers, allocation and one out of few x-out-of-y possibilities once voting is open.

@Byron-McKeeby

Some key contributor roles (KCRs) may include:

Developers who work on passed and deployed proposal contracts
Auditors who review code and find bugs/vulnerabilities
Proposal architects (folks who don’t code, but refine designs)
Helpful forum member who go out of their way to help newcomers
Community organizers who mobilize action (conversations, votes, etc)
Content creators (blogs, videos, memes, etc)

These some KCR that were identified in this conversation with @ethdev

3 Likes