Tribeca Protocol: Architecture

Every DAO using the Tribeca Protocol is interacting with three underlying programs (aka smart contracts). All programs are verified on the Anchor verified build system then deployed on mainnet-beta and devnet. Each program serves a specific purpose in governance, and this article will go into detail on each component and its function in the governance process.

Having three separate smart contracts minimizes risk of failure across a distributed system, while maximizing flexibility and permitting upgradeability. It is also very general-purpose in its use, although designed primarily for protocols with large TVL in programs (such as AMMs) to decentralize their ownership and governance model, it can be used by any DAO which utilizes an SPL token for governance.

1. Goki Smart Wallet

Goki Protocol is a member of the Tribeca DAO, and their Smart Wallet is a programmable multisig wallet with Timelock capabilities which the Tribeca Governor is built on. It is based on Serum’s multisig implementation. This program executes transactions from proposals which are passed by the govern program.

• Goki wallet is an m-of-n multisig, where out of n owners of the wallet, m must approve a transaction to have the wallet sign it. Owners are defined upfront, and the owners of the wallet may elect to modify the signers in the future.
• The recommended configuration for a Locked Voter Tribeca DAO consists of a Smart Wallet with three signers. (1) The Governor, which is the governance account owned by the govern program. (2) The Executive Council, which is a group of trusted individuals specified in a Smart Wallet which sign via an Owner Invoker to execute passed tx. (3) The Emergency Multisig, which is a group of well-known individuals that may override governance in the event of emergency.

2. Govern Program

This program owns Governor accounts which each represent a collection of votes on proposals and determines which proposals may be executed. This program does not have authority to execute proposals, and does not have custody of user’s locked assets. In order for the protocol to operate, the governor account must be linked to a smart wallet, electorate, and parameters must be inputted. Parameters may be changed by passing a proposal with a transaction that invokes the govern.set_gov_params instruction with updated fields. Parameters include:

• Voting Delay — The number of seconds to wait before voting on a proposal may begin. Also determines earliest possible activation time for the proposal;
• Voting Period — The duration of voting on a proposal, in seconds;
• Quorum Votes — The required minimum votes to make proceeding valid;
• Timelock Delay — Time delay in seconds from which a proposal’s transaction can be executed after it has been queued. After Timelock Delay, an Executive Councelor may execute the proposal.

3. Electorate Program

By default Tribeca Protocol uses locked_voter (voting escrow locker) as the Electorate Program. There also exists a simple_voter program for use in the source code, but it is currently not in use. Electorate Programs generate an account which controls the Governor through cross-program invocations. Unlike the other two in the trinity, Electorates may be user-defined programs since they operate on CPI calls to the Governor. It can perform two actions:

• Activate Proposals, which moves proposals to a state where they can be voted on;
• Set votes, which logs the number of votes a voter has made on a proposal, and which side of the vote that voter is on.

The Electorate Program in the recommended configuration is the locked_voter program, which has a few parameters that must be set:

• Governance Token ID — The Mint Address of the SPL token to be used for governance. This is the token that the locker will accept for setting veToken balances;
• Min Stake Duration — Minimum time possible to lock token for 1x veToken balance multiplier;
• Max Stake Duration — Maximum time possible to lock token for (Max Vote Multiplier)x veToken balance multiplier;
• Max Vote Multiplier — Maximum multiplier that would apply if token is locked in voter escrow for Max Vote Duration;
• Votes To Activate A Proposal — Number of votes a user needs to move a proposal from the draft phase to the active voting phase.

Disclaimer

All claims, content, designs, algorithms, estimates, roadmaps, specifications, and performance measurements described in this project are done with the author’s best effort. It is up to the reader to check and validate their accuracy and truthfulness. Furthermore, nothing in this project constitutes a solicitation for investment.