Shaman

It’s not magic when you’re wielding the power of complex smart contracts. In the war for coordination, Shamans are tools in service to intentional communities. Use responsibly.

Shaman are one of the core features of Baal that were introduced in Moloch v2.5. A Shaman is a separate contract that the DAO approves. Shaman are very powerful as they can make critical changes to the DAO outside of the proposal process. This introduces a high degree of flexibility, but should be approached with intentionality and caution.

The Shaman emerged as a direct result of the design goal to provide flexibility to DAOs to change the underlying membership structure without needing to resummon. Shaman have their own set of functions and permissions.

Shaman Functions#

Admin Shaman#

function setAdminConfig(bool pauseShares, bool pauseLoot)
        external
        baalOrAdminOnly

Manager Shaman#

function mintShares(address[] calldata to, uint256[] calldata amount)
  external
  baalOrManagerOnly

function burnShares(address[] calldata from, uint256[] calldata amount)
  external
  baalOrManagerOnly

function mintLoot(address[] calldata to, uint256[] calldata amount)
  external
  baalOrManagerOnly

function burnLoot(address[] calldata from, uint256[] calldata amount)
  external
  baalOrManagerOnly

Governor Shaman#

function setGovernanceConfig(bytes memory _governanceConfig)
  external
  baalOrGovernorOnly

bytes packed params

(
            uint32 voting,
            uint32 grace,
            uint256 newOffering,
            uint256 quorum,
            uint256 sponsor,
            uint256 minRetention
        ) = abi.decode(
                _governanceConfig,
                (uint32, uint32, uint256, uint256, uint256, uint256)
            );

Shaman Permissions#

In order to be able to makes changes to loot and shares, Shaman need the persmission to do so. Everything settable by Shaman can be set by DAO via proposals. Shaman permissions are set by composing the values from a registry:

0 = no permission
  1 = admin only
  2 = manager only
  4 = governance only
  3 = admin + manager
  5 = admin + governance
  6 = manager + governance
  7 = admin + manager + governance

Using the above registry values, if a Shaman has a permission value of 0 then there are no permissions set. If a Shaman has a permission value of 7, then they have combined permissions of Admin, Manager, and Governance. The 7 is a sum of all of the combined permissions, ie. 7 is a combintion of 1 (admin only), 2 (manager only), and 4 (governance only).

There are boolean values that can be set for Shaman that relate to permissions:

bool public adminLock; /* once set to true, no new admin roles can be assigned to shaman */
    bool public managerLock; /* once set to true, no new manager roles can be assigned to shaman */
    bool public governorLock; /* once set to true, no new governor roles can be assigned to shaman */

There is a mapping that maps each Shaman addresss to the set permission levels:

mapping(address => uint256) public shamans; /*maps shaman addresses to their permission level*/

Projects Using Shaman#

Onborder Manager Shaman#

Easy onboard a new bember into a Loot position in the DAO through sending the chains native token or erc20.

Onboarder Shaman Contract

Since Shamans were introduced in Moloch v2.5 there are a few projects that have integrated this functionality.

Yeeter v2#

Yeeter

DAOgroni#

The DAOgroni NFT contract is a shaman. When someone mints a cocktail NFT and then they drink it, the shaman changes the number of shares that person has inside the MolochDAO, instantaneously, because it avoids the proposal process. First you buy the NFT and xDAI gets forwarded to DAO treasury, then you drink it, which gives you DAO shares. This is all done with a shaman.