Kali

long arms of the law, distributed hands

FEL8PaoXIAABPQK (1)

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:

image

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.

image

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.

image

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.

image

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

Arbitrum

KaliDAOfactory: 0xd53B46aE3781904F1f61CF38Fd9d4F47A7e9242B

FixedERC20factory: 0xF85e8B97c058cb13DB8651217f69AD7D7efFf877

KaliNFT: 0x5F43Ff59ee5aE5a98cF59764C094e9aba830ecEE

LexLocker: 0xc0d255983316d72e2CCa3bCd601a0d2D9b96D0F3

Polygon

KaliDAOfactory: 0x582eAF6a83E55d60615A5FfB80913bE5c1724c41

FixedERC20factory: 0xafB6aC447f765a6BFD6B0D08D03a509D028BD11a

KaliNFT: 0x1401B932839421B5db90cCd07417Bc4583e98729

LexLocker: 0x8D9779bFe26CC35eacF677b51e10BfFe9567EFc5

Rinkeby

KaliDAOfactory: 0x6106375F8549fD1a688956F7070aa8bA3fdF51b2

FixedERC20factory: 0x6aBab95BB30710159B3e40bF6e049f935547D12b

KaliNFT: 0xA503f9F9350C5A6C5a550fa0FCA9fCE1dd5ab7c6

LexLocker: 0x5F0d15EF165D670F82510bb56a28B4bA48cf08Fc

image

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.