TempleDAO (English)

Admin Controls

Contract Ownership

TempleDAO currently relies on a Gnosis Safe multisignature contract for the protocol’s administrative and treasury operations. The TempleDAO Multisig owns all of the protocol contracts. The multisig’s address is 0x4D6175d58C5AceEf30F546C0d5A557efFa53A950. Every Temple master is an owner on the multisig.
All protocol policies and on-chain operations are restricted by onlyOwner. Additionally, none of Temple’s smart contracts are upgradeable, so if a contract’s logic needs to be changed, the contract must be entirely redeployed.
We are working on building out a series of AMO contracts to further automate and decentralize our treasury and governance decisions. Read more about our vision for governance at TempleDAO.

Mutable Policies

There are several coefficients and variables that can be updated to reflect Temple’s policy decisions. These policies are implemented by calling specific functions from the Temple Multisig. Below is a list of the various mutable policies the multisig can control.
First, the AMM Router can be updated and redeployed as a new contract. Each liquidity pair (e.g. Temple-FRAX) can have its router updated by the multisig. We have enacted this in the past as we updated our AMM router to include Temple-FEI liquidity.
Second, Temple's intrinsic value is set as a ratio between Stable:TEMPLE. This ratio is set in the IV treasury contract and can be updated by the multisig. While there have been many discussions for methods to increase IV, the only mechanism currently implemented is when the AMM trades above the price threshold and Temple Growth is activated. The multisig can also add or remove minters for the Temple ERC20 token. This is necessary for the custom AMM to be able to mint new tokens upon activating Temple Growth. Since Temple Defend is one of the core products of the Temple protocol, we have no intention to manipulate IV or expand circulating supply without treasury growth or expanding our stable backing.
Last, the multisig is currently needed for Temple Core to manage vault operations manually. Specifically, the multisig can manually withdraw tokens from vaults, redeem exposures to vaults, update the hourly joining fee, adjust a vault’s share of revenue, and add revenues. While today this is a lengthy process to manage vaults behind the scenes, the team is actively developing AMO contracts to automate all of the vault operations.

Pause Controls

The Temple Team Payments contract is the only part of the protocol that is pausable by the Temple Multisig. This pause control would allow Temple to halt claims of team payments in the event of an emergency, such as a mistake in how much $Temple is claimable for a given team member.
The remainder of the TempleDAO protocol remains immutable and forever functional in the face of adversity. If there were truly a catastrophic event, Temple could emigrate its liquidity to effectively pause the AMM. Anyone else, however, would still be able to permissionlessly provide liquidity on the Temple AMM. We want this immutability to serve as a symbol of trust that Temple cannot rug critical mechanisms such as Temple Defend or the Core Vaults.


A Timelock is a smart contract that requires any calls made to a contract to pass through a time delay, allowing users to exit the contract in advance of the change taking effect if they so desire. Since the protocol has no upgradeable contracts, and governance is not handled on-chain by the DAO, Temple does not implement any timelocks.