To add a new data type to Tellor, you'll just need to define a new queryType. That's how you form a question so that Tellor reporters know exactly what data is being requested. You'll need to determine three things: a unique queryType name, inputs, and outputs. So let's say you want a query for getting the price of any asset in any currency. In human-readable form, your question might look like this: What is the price of asset in currency ? Adding this query to a dataSpecs doc, you might define your query like this: Name: SpotPrice Inputs:

Does a minion introduce perverse incentives to the moloch dao structure? If you use a minion to invest some DAO assets in an external project, those assets are no longer available to members who choose to ragequit. Attack Invest a significant portion of moloch-dao assets into a DeFi project using a minion Create attacker contract ‘owned’ by 51% of DAO share membership Submit moloch proposal to transfer all assets in Guild bank to attacker contract Those 51% of attackers vote to approve that proposal Other 49% of share members face choice between

The Minion Public resolver takes the regular minion contract and narrows its functionality to one thing. It allows a minion to change an ENS content hash via a moloch DAO minion proposal. Using this tool, a DAO can control an IPFS website. Any changes to the website have to be approved via a DAO proposal. This can also be a solution for managing a DAO’s metadata. In order for the MPR to function, the MPR’s address must be set as the ‘controller’ for the ENS domain. The DAO’s general minion ought to be set as the domain ‘registrant’ so that more complex interactions beyond changing the ENS content hash can be handled accordingly. In order to create this tool, I consulted the ENS public resolver contract. The function setContentHash(bytes32 node, bytes calldata hash) is used to change the ENS content hash, and this is the single function that the MPR gives access too. To make an MPR proposal, one must call proposeSetContentHashand input a node(unique identifier for each domain), hash (the domain’s content hash record), and description (standard text description for moloch dao proposals). Once this is called correctly, a standard moloch DAO proposal is created and just waiting to be sponsored. Something to consider Part of this experiment is looking at using a refined minion (as opposed to a general minion). The MPR only allows one specific function call type to one specific contract. It would be cheaper in terms of gas costs to launch a single general minion for a DAO. The general minion can handle any arbitrary function call to any contract. This means that one can already control ENS content hashes with the general minion. It is possible, however, that the costs of launching refined minions for a DAO, in addition to a general minion, could be justified. It may be easier for DAO members to make sense of minion proposals when they come from a contract with more constrained functionality. Those familiar with the MPR, for example, would see a new proposal from the MPR and know exactly what type of function call is being proposed by virtue of it being the only function call available to the MPR.

How JSON blobs work JSON blobs contain the ABI data for a contract. New ABIs for various Defi contracts can be found via Github, Etherscan, etc. Add them to moloch-minion/src/abi/xxx.json These blobs get imported into the project in the /src/App.vue file ... import abiDecoder from "abi-decoder"; import gql from "graphql-tag";