Kali

long arms of the law, distributed hands

Optimized DAC Protocol
├─ KaliDAOfactory — "Deploys new Kali DAO with event and return of address"
│  ├─ KaliDAO — "DAO core module with Comp-style token voting and adjustment of membership, low-level calls on quorum/supermajority"
│  │ ├─IKaliDAOextension — "Interface for DAO to mint and burn shares as outputs of interactions with whitelisted external contracts, providing simple modularity"
│  │ ├─ReentrancyGuard — "Security module that provides reentrancy checks on core DAO functions"
│  │ ├─NFThelper — "Utility for DAO to receive `safeTransfer()` of NFTs under ERC-721 & ERC-1155 standards"
│  │ ├─KaliDAOtoken — "Pausable Comp-style voting token with metaTX support"

Kali is a protocol for on-chain orgs inspired by Compound and Moloch DAO governance. The smart contract code is simple to make it easier to read and secure assets on (less code, less to break). For example, Kali reduces Comp-style governance into a single contract, and can support extensions to add contracts as apps, such as crowdsales and redemptions against pooled funds. Kali contracts are further optimized for gas efficiency and functions are written to be easily adapted via modules through overrides.

Designed for DAC

Kali is built for on-chain companies and funds. Proposals are broken out into a variety of types that each can have their own governance settings, such as simple/super majority and quorum requirements. Further, Kali supports hashing and amending docs from deployment and through proposals, providing a hook to wrap organizations into legal templates to rationalize membership rules and liabilities. Legal forms are maintained as open source goods by LexDAO legal engineers. Incorporation, and full-service legal engineering support is also being integrated into an MVP UI to allow Kali users to solve their org painpoints quickly and cheaply (stay tuned).

Token Voting, Delegation & MetaTX

Kali tokens (KaliDAOtoken) represent voting stakes, and can be launched as transferable or non-transferable, with such settings being updateable via PAUSE proposal (see below). This allows for DACs to launch with closed membership (similar to Moloch-style 'clubs') but still retain the option to open their seats to the public. This configurability, in addition to appealing to different deployer preferences, can allow orgs to plan around compliance objectives.

Voting weight can also be delegated, and such weight automatically updates upon token transfers from delegators, incorporating functionality from Comp-style tokens (with an improvement of 'auto delegation' to new accounts to avoid an extra transaction for Kali users).

As a UX feature, meta-transactions can be made with Kali tokens, such as gas-less (relayed) transfers via EIP-2612 permit(), and delegation using EIP-712 off-chain signatures. Similarly, voteBySig() allows for voting meta-transactions, effectively allowing DAOs to subsidize and make voting free for members.

Kali tokens are further designed with gas efficiency in mind and have incorporated optimization techniques from RariCapital's solmate library.

NFT Vault

Kali supports both ERC-721 and ERC-1155 NFT safeTransferFrom() through the NFThelper module. NFTs can be managed through CALL proposals (see below).

Proposal Types

Proposals can be made under 10 types:

MINT: create more membership tokens.

BURN: burn membership tokens, similar to Moloch DAO ragekick().

CALL: make external calls to other smart contracts, similar to Moloch DAO Minion.

PERIOD: adjust voting period.

QUORUM: adjust voting quorum requirement, that is, the % of membership tokens that must vote for proposals to pass.

SUPERMAJORITY: adjust super-majority requirement, that is, the % of member approvals required for proposals to pass.

TYPE: set ProposalType to a VoteType.

PAUSE: toggle member token transferability.

EXTENSION: toggle approval for certain contract external calls via extensionCall().

DOCS: update docs string stored in smart contract that provides underlying context for membership and proposals.

Voting Types

VoteType is assigned to ProposalType upon Kali creation and determines threshold vote settings for proposals to pass.

SIMPLE_MAJORITY: Proposal must pass 51% threshold.

SIMPLE_MAJORITY_QUORUM_REQUIRED: Proposal must pass both 51% threshold and quorum setting.

SUPERMAJORITY: Proposal must pass supermajority threshold (which will be greater than 51%).

SUPERMAJORITY_QUORUM_REQUIRED: Proposal must pass supermajority threshold and quorum setting.

Extensions

Kali allows orgs to flexibly extend their rules for minting and burning shares through external contract calls by using an interface, IKaliDAOExtension and extensionCall(). In this manner, the core Kali contracts can remain simple and easy to verify, while still giving a great deal of optionality to orgs as they determine their goals.

For example, an org may wish to deploy with non-transferable tokens but open its membership to whitelisted contributors in order to expedite its growth beyond MINT proposals. To do this, an extension could be approved through an EXTENSION proposal that contains logic to check credentials and exchange tokens for contributions, allowing compliant fundraising.

Other use cases include: (i) Moloch-style ragequit() banking contract extension that exchanges a fair share of deposited capital in return for burning tokens, (ii) crowdsales open to public with transferable tokens, and (iii) merkle-style airdrops to upgrade existing DAOs into Kali or otherwise immediately grant voting rights to a large group at once.

TX Batching

Proposals support batching for membership (MINT/BURN) so that groups of accounts can be updated, as well as for EXTENSION external calls, so that complex contract interactions can be arranged, such as approving and executing DeFi positions.

Further, all Kali function calls can be batched using multicall(), adapted from Uniswap V3, which can allow members to make multiple proposals or process the same in a single transaction, saving gas and time.

Security

Kali adopts standard security conventions, including a ReentrancyGuard module for core functions to avoid the potential of reentrancy attacks, as well as an internal function, _computeDomainSeparator() to help protect against signature replay in the event of a blockchain fork. In addition, as much as possible, Kali incorporates well-tested and common solidity patterns to make the code easier to audit and avoid 'reinventing the wheel', which can lead to the known unknown of novel attack surfaces. Tests are also included in JavaScript to demonstrate the performance of Kali operations.

Deployments

Contributors

Special thanks to Auryn Macmillan and James Young for comments on early iterations of extensions concept, t11s for gas-golfing tips, and Q for help understanding how to develop dapp.

jordanteague/kalipleasework