Tribeca Protocol: Ecosystem

Tribeca allows other protocols to easily integrate into the existing protocol by making use of Cross Program Invocations. This is made extremely simple (compared to using vanilla rust) by the use of Anchor in the design of the Tribeca Protocol, as well as the design choice of breaking apart the functions of Tribeca into three separate Solana programs (smart contracts).

If you want more detail on the function of the three programs, read my article on the Architecture of Tribeca Protocol. What’s important in the context of the Tribeca Ecosystem is that system integrators are able to interact with the specific program they intend on targeting. For example, an integration for payment processing may only need to interact with the wallet program — not the locker or the govern program. This minimizes the amount of errors caused by code that isn’t fully compatible, and also makes development more efficient.

Current State of the Tribeca Ecosystem

Within a month of deploying the Tribeca Protocol on Solana mainnet, various integrations have been made to the core protocol that highlight the power of composability for increasing the speed of development:

• Quarry Protocol - Gauges. Quarry is an open source protocol for launching liquidity mining programs. Quarry Gauges allow voting escrows to allocate the rewards of a set of liquidity mining pools.

Fig 2. Example of gauges in Saber Governance, where the user can view the current/next shares, and vote.

Fig 3. Gauges are implemented to directly interact with the Quarry protocol rewards pools (seen above) weekly

VenkoApp - Grant Management. Venko is a protocol for issuing streams of tokens. Using Tribeca, DAOs can issue grants that are vested linearly, can have a cliff period, and may be cancelled by the issuer. DAOs can also manage streams of voting escrow (ve) tokens to manage token cliffs for salaries and grants while providing core teams the governance power they may require early on.

Fig 4. Venko is the rails for realtime finance on Solana. Mix of Anatoly’s last name and a popular fintech name

• Cardinal - Basic Identity w/ Twitter. Cardinal Labs is providing valuable infrastructure for NFTs by allowing conditional ownership based on parameters like time-based, use-based, or data-based expiry. One use case implemented in the Tribeca interface allows users to claim an NFT that corresponds to their twitter, and then ties that NFT to their wallet once they make proposals or votes on Tribeca.

Fig 5. Cardinal Labs lets voters link their identity to their governance account using NFTs

• Saber - Voting Escrow Snapshots. Saber is a cross chain stable-swap and AMM, but they also have extensive open source tooling available on their github. VE Snapshots allow protocols to record veToken balances at set periods, allowing for a history of holdings in escrow in order to enable fee distribution from the protocol and airdrops to veToken holders.

Fig 6. VE Snapshots allow protocols to share revenue from their fees, and create incentives for holding veToken by becoming eligible for airdrops — opening the door to many possible use cases

What’s next

Our goal is to see more teams build on top our framework, which will support the need for more integrations, which in turn supports the development for more tooling — in a decentralized and composable on chain system.

Fig 14. Tribeca and SPL Governance are currently the two main options for DAO tooling on Solana

As you can see, there remains some open challenges which must be resolved in order to have a blooming DAO ecosystem:

• Improved treasury management UI needed for Tribeca, by allowing the ability to add treasury accounts for different assets and requiring users to set some configurable governance parameters for each account
• Reputation score and contribution tracking tools required, for optimal use of compensation infrastructure
• Integrate and fund sub-DAOs within a main DAO (currently technically exists as the emergency/executive councils- but not flexible for users)
• Open the bribery market for entities to offer emissions in return for control over veToken voting balances. Makes use of set_vote_delegate from the locked_voter program for this.

You can read the docs to learn more about how Tribeca differs from SPL governance- but the most important point is that it’s much easier to build on Tribeca because of it’s modular, anchor based design. Nonetheless, neither DAO framework has much additional (non-critical) tooling seen in other chains that may increase adoption:

• Solana-integrated knowledge management and discussion platforms
• User-generated electorate programs, which may be customized versions of the locked_voter but with the ability to decide when to begin decaying tokens, or enabling the linear unlocking of tokens alongside locks
• Detailed Analytics Platforms, that track veTokens and voting statistics
• Added option to enable NFT deposits in exchange for governance power
• Rule-Based Emissions, e.g. base rate x % circulating (non-locked) supply
• Represent veToken balances as mutable NFTs, along with their voting power, time to decay, and ability to claim locked token. (May not be optimal if legal risks are lowered by having non-transferabilty)

If any of these open challenges sound interesting to you, reach out to the Tribeca team in discord. Regardless, be sure to follow Tribeca on Twitter and Medium for more information on how to onboard your own DAO, as well as info on what additional functionality that DAO will be able to leverage.

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.