oSnap

[md0x]

NOTE

• If you would like to add a volume adapter please submit the PR here.
• If you would like to add a liquidations adapter, please refer to this readme document for details.

1. Once your adapter has been merged, it takes time to show on the UI. If more than 24 hours have passed, please let us know in Discord.
2. Sorry, We no longer accept fetch adapter for new projects, we prefer the tvl to computed from blockchain data, if you have trouble with creating a the adapter, please hop onto our discord, we are happy to assist you.
3. The protocol is usually listed within 24 hours of merging the PR
4. Please fill the form below only if the PR is for listing a new protocol else it can be ignored/replaced with reason/details about the PR
5. For updating listing info It is a different repo, you can find your listing in this file: https://github.com/DefiLlama/defillama-server/blob/master/defi/src/protocols/data2.ts, you can edit it there and put up a PR
6. Do not edit/push package-lock.json file as part of your changes, we use lockfileVersion 2, and most use v1 and using that messes up our CI
7. No need to go to our discord and announce that you've created a PR, we monitor all PRs and will review it asap

---

Name (to be shown on DefiLlama):

oSnap

Twitter Link:

https://twitter.com/UMAprotocol

List of audit links if any:

https://blog.openzeppelin.com/uma-optimistic-governor-audit/

Website Link:

https://docs.uma.xyz/developers/osnap

Logo (High resolution, will be shown with rounded borders):

https://umaproject.notion.site/oSnap-circle-logo-da3398b724a6447da4eb846ce4774858

Current TVL:

44.95M

Treasury Addresses (if the protocol has treasury)

N/A

Chain:

Ethereum, Polygon, Optimism, Arbitrum, Avalanche, Gnosis Chain

Coingecko ID (so your TVL can appear on Coingecko, leave empty if not listed): (https://api.coingecko.com/api/v3/coins/list)

N/A

Coinmarketcap ID (so your TVL can appear on Coinmarketcap, leave empty if not listed): (https://api.coinmarketcap.com/data-api/v3/map/all?listing_status=active,inactive,untracked&start=1&limit=10000)

N/A

Short Description (to be shown on DefiLlama):

oSnap (Optimistic Snapshot Execution) enables on-chain execution of successful Snapshot proposals utilising UMA's optimistic oracle

Token address and ticker if any:

N/A

Category (full list at https://defillama.com/categories) *Please choose only one:

Services

Oracle used (Chainlink/Band/API3/TWAP or any other that you are using):

UMA

forkedFrom (Does your project originate from another project):

N/A

methodology (what is being counted as tvl, how is tvl being calculated):

Calculates the total value held by the Avatars of all deployed Optimistic Governors (a.k.a oSnap) modules

[llamatester]

The adapter at projects/osnap exports TVL:

avax                      0
optimism                  0
arbitrum                  0
xdai                      0
polygon                   0
ethereum                  44.95 M

total                    44.95 M 

[llamatester]

Error while running adapter at projects/osnap:

Error: 
    Found export keys that were not part of specification: timeTravel

    List of valid keys: 
				
				tvl
				staking
				methodology
				pool2
				misrepresentedTokens
				fetch
				timetravel
				borrowed
				start
				doublecounted
				treasury
				hallmarks
				incentivized
				offers
				deadFrom
				broken
				ownTokens
				vesting

[llamatester]

The adapter at projects/osnap exports TVL:

avax                      0
xdai                      0
optimism                  0
arbitrum                  0
polygon                   0
ethereum                  43.66 M

total                    43.66 M 

[g1nt0ki]

hi @md0x, these avatars seem be teams' multisig, is that correct?

also, the amount of ACX counted towards tvl is 4x the current circulating supply according to coingecko

[mrice32]

hi @md0x, these avatars seem be teams' multisig, is that correct?

also, the amount of ACX counted towards tvl is 4x the current circulating supply according to coingecko

@g1nt0ki this is correct. oSnap is a governance module that plugs into gnosis-safe that's powered by the UMA oracle to allow anyone to bring the snapshot votes on-chain, post a bond, and execute it after the liveness passes with no dispute. It allows teams to decentralize their governance/gnosis-safe without needing to run a full on-chain voting process. The included avatars are the safes that have added the module and are secured by oSnap.

also, the amount of ACX counted towards tvl is 4x the current circulating supply according to coingecko

This is because it's the ACX treasury, which are the tokens that are excluded from the circulating supply. Should these be treated differently?

[g1nt0ki]

I will be honest, the major issue I see is, the tokens are in multisigs controlled by protocols and users have no interaction with them (depositing/withdrawing tokens). This is why I think we cant list them, sorry.

[pemulis]

@g1nt0ki the tokens are in Safes that are controlled by oSnap modules which is why they're included. The purpose of oSnap is to decentralize control of the assets in a Safe, as well as any permissions the Safe has in other contracts, so if the assets aren't reflected in your data your TVS calculation for UMA will not be accurate.

[g1nt0ki]

@pemulis sorry, I am still not convinced by your argument, if it has no interaction how is it defi?

[pemulis]

@g1nt0ki it does have interaction. Once transactions are approved on Snapshot, any address can propose and execute them with the Safe permissionlessly. Those transactions can do anything: Moving assets out of a Safe, executing a swap, lending or borrowing, adjust LP positions, triggering functions in other contracts where the Safe has admin permissions, and so on.

[pemulis]

@g1nt0ki these are the key functions in the contract that allow permissionless interaction:

proposeTransactions
https://github.com/UMAprotocol/protocol/blob/master/packages/core/contracts/optimistic-governor/implementation/OptimisticGovernor.sol#L226

executeProposal
https://github.com/UMAprotocol/protocol/blob/master/packages/core/contracts/optimistic-governor/implementation/OptimisticGovernor.sol#L298

[g1nt0ki]

*sorry, I meant if users have no interaction. If the multisig decide, can they move all the tokens in this contract to somewhere else without the approval from the users?

[pemulis]

*sorry, I meant if users have no interaction. If the multisig decide, can they move all the tokens in this contract to somewhere else without the approval from the users?

If the DAO keeps the multi-sig around after deploying oSnap, yes. However, there is no need for the multi-sig signers to interact with the Safe after oSnap is deployed, and it is the explicit goal of most of our early partners to transition away from multi-sigs, first by letting ordinary users execute transactions approved on Snapshot and ultimately by disabling the multi-sig's permissions entirely.

You yourself could propose and execute any transactions approved on Snapshot by any DAO if they have oSnap deployed. You could even use an oSnap proposal to disable a multi-sig. After that, the DAO's Safe could only be controlled permissionlessly through oSnap, possibly in combination with a back-up on-chain voting system.

UMA does not have any reliance on multi-sigs, unlike some other oracle systems that have opaque multi-sigs with significant power to upgrade contracts or overrule their core protocol mechanisms.

As it is, an oSnap Safe with a redundant multi-sig is similar to a DeFi protocol that has upgradeable contracts or multi-sigs with admin powers. As a couple of examples, Compound has a community multi-sig that can switch price feeds (https://docs.compound.finance/v2/prices/#architecture), and GMX has a multi-sig (https://arbiscan.io/address/0x2c247a44928d66041d9f7b11a69d7a84d25207ba) with admin powers, but both protocols are counted towards Chainlink's TVS.

[g1nt0ki]

sorry, neither compound nor GMX is a valid comparison, are we counting the tokens on their multisig towards their tvl?

[pemulis]

@g1nt0ki We might be talking past each other a bit here since we're really not concerned about TVL for any given project, only TVS for UMA. The typical way of calculating TVS is to add up all the TVL of protocols that rely on an oracle's data. In the oSnap case, the TVS is coming from Safes, typically holding DAO treasuries. It's not clear that the value in a Safe is "TVL" for any protocol, unless you're calculating the TVL of Safe itself, a massive number. It is, however, value that is secured by UMA when there is an oSnap module, since transactions validated through oSnap and UMA can move all of the value locked in a given Safe. We're trying to figure out how to accurately reflect tokens in an oSnap Safe as UMA TVS but it's difficult because there is no obvious place to attribute the TVL.

[mrice32]

@g1nt0ki

Just to second @pemulis's comment here: oSnap is a product released by UMA. We are looking for the right way to attribute this to UMA's TVS in DefiLlama. The funds in these safes are secured by UMA because the UMA oracle determines the validity of transactions proposed to the Safe (and whether they can be executed or not) via the oSnap module that is added to the Safe on-chain (giving it the ability to execute transactions on that Safe). We see this as quite similar to other situations in which oracles secure funds in other types of smart contracts.

How do you think this should be represented on DefiLlama?

[0xngmi]

we can count this into UMA TVS, but:

• it needs to follow our rules and not include any unissued tokens, this means that all own protocol tokens (eg ACX) should be removed from this adapter
• this will require some changes in our backend to accommodate this special case, so will take longer to show up once merged than other protocols, we don't have an ETA on when

[pemulis]

we can count this into UMA TVS, but:

• it needs to follow our rules and not include any unissued tokens, this means that all own protocol tokens (eg ACX) should be removed from this adapter
• this will require some changes in our backend to accommodate this special case, so will take longer to show up once merged than other protocols, we don't have an ETA on when

Thanks @0xngmi, we'll make the updates to remove "own protocol tokens" from each Safe (ACX for Across, FOX for ShapeShift, BOND for BarnBridge, etc.).

[llamatester]

The adapter at projects/osnap exports TVL:

avax                      0
polygon                   0
arbitrum                  0
xdai                      0
optimism                  0
ethereum                  8.72 M

total                    8.72 M 

[md0x]

Hello, @0xngmi
We have done the adjustments to remove protocol issued tokens from all avatars in the new config file and recent changes in this PR.

Do you think these modifications could help speed up the process of merging the adapter?

Thanks!

[mrice32]

@0xngmi

this will require some changes in our backend to accommodate this special case, so will take longer to show up once merged than other protocols, we don't have an ETA on when

To avoid this work and delay, could oSnap be classified as a protocol with this TVL and set UMA as its Oracle? I totally get that it's unintuitive to classify this as TVL, but I think it's pretty reasonable:

• A user deposit funds in a Safe.
• A user grants oSnap control of this Safe via the module interface.
• Those funds are now managed by the oSnap protocol.

The user isn't depositing into a new contract, but they are transferring control of the existing contract to the protocol. This is similar in concept to depositing your funds into a DeFi protocol in that you still have rights to those funds, but you are trusting that protocol to administer them until you withdraw.

[pemulis]

The recent BarnBridge proposal is a good example of how oSnap/UMA secures treasury value.

Description: https://twitter.com/Barn_Bridge/status/1658191348111998976?s=20
Proposal: https://oracle.uma.xyz/?transactionHash=0xb5802cefa6968f1a8d804cd9280e8958b97cf6ea5e5292cbad25592b8a646859&eventIndex=339

They're using UMA to validate and secure the transfer of $138,093.69 to fund one of their contributing teams for Q2 2023, which was approved off-chain by a Snapshot vote. Because the oSnap module has permission to move tokens out of the Safe, or execute any other transaction on the Safe's behalf, UMA is securing not just this transfer but all of the value stored in the Safe.

[pemulis]

@0xngmi any updates on this?

[pemulis]

Do you have a sense of when this might get reviewed? Even if the answer is that it won't be reviewed for a few months, that would be helpful to know, so we can find alternatives for tracking and displaying this information in the meantime.