KVORUM
aaveSource: Aave governor v2 · #48

Add Fireblocks as a whitelister on Aave Arc

executedNov 21, 2021, 10:45 AM UTCbyB50xb5fe…a424

01Summary

AISummary by Kvorumclaude-haiku-4-5

Fireblocks LLC is being appointed as a whitelister on Aave Arc, a permissioned version of Aave V2. Whitelisters conduct KYC/KYB checks, onboard users, and grant permissions to interact with the protocol. The proposal adds Fireblocks as a Permission Admin, unpauses the Aave Arc pool, transfers emergency admin role to Arc Timelock's Veto DAO, and transfers ownership to Arc Market Multisig. This passed snapshot voting with 98.33% approval.

Type
governance change

Key changes

  • Fireblocks LLC added as Permission Admin to manage KYC/KYB checks and grant user permissions on Aave Arc(high)
  • Aave Arc pool unpaused to enable live operations(high)
  • EmergencyAdmin role transferred to Arc Timelock's Veto DAO for governance oversight(high)
  • System ownership transferred to Arc Market Multisig temporarily pending handover to Aave Governance(medium)

Notable concerns

  • Whitelisters have veto power over governance proposals affecting compliance risk
  • Centralized gatekeeping function concentrated with whitelisters may impact protocol accessibility
  • Fireblocks required to maintain active license/registration and robust AML/CFT compliance programs
Contracts0xF4a1F5fEA79C3609514A417425971FadC10eCfBE0x4e1c7865e7BE78A7748724Fa0409e88dc14E67aA0x686a12A79008246F4dF2f1Ea30d136BD6DE748B4
Generated by Kvorum
model: claude-haiku-4-5
provider: anthropic
profile: anthropic-fast-v1
prompt: v1.0
generated: 2mo ago
Read the description ↗

02Description

612 words

Simple Summary

Fireblocks asks the Aave Governance community to approve the appointment, adoption, and authorization of Fireblocks LLC, a Fireblocks company, as a “whitelister” on the Aave Arc market.

Abstract

Aave Arc is a “permissioned” version of the software underlying V2 of the Aave protocol that employs an additional smart contract layer to only allow “whitelisted” or “permissioned” users to engage with the protocol.

Only regulated entities that (a) employ KYC/KYB principles in accordance with FATF guidelines to identify and accept their clients; (b) have robust AML/CFT compliance programs; and (c) are currently in good standing with an active license/registration in the entity’s operating jurisdiction will be accepted as “whitelisters” on Aave Arc.

We believe that Fireblocks LLC, a Fireblocks company, satisfies all the qualification requirements to be a whitelister. We have performed a detailed analysis and documented it here for the consideration of the Aave Governance community.

Motivation

DeFi is considered by institutional users to be one of the more complex markets to navigate across security, compliance, and risk perspectives. We are eager to be at the forefront of this transformational opportunity with Aave Arc by extending access to even our most compliance-conscious customers, who have been searching to engage with DeFi in a way that comports with their own internal requirements.

Approval of Fireblocks LLC can potentially also facilitate the integration of other “whitelisters” and institutions into instances of the Aave protocol. This may have multiple benefits, including the creation of sustainable governance practices for Aave Arc whitelisters and whitelister customers, as well as the enablement of benefits to the ecosystem, such as the onboarding of regulated fiat on/off ramps and protocol deployments connected to debit cards, high yield savings accounts and other innovative fintech products.

Specification

“Whitelisting” is the gatekeeping function performed by whitelisters on users of Aave Arc. The term refers specifically to the process of:

  1. Conducting KYC/KYB checks on the user;
  2. Onboarding the user with appropriate disclosures, terms, and conditions;
  3. Granting specific permissions (e.g., borrow, supply, liquidate) to the Ethereum wallet address(es) provided by the user.

In addition, Aave Arc whitelisters perform a similar role on Arc as guardians do on Aave V2. Specifically, whitelisters can use a multi-sig veto on governance proposals that add excessive compliance risk on the Aave Arc protocol. For example, existing whitelisters can veto the addition of a privacy coin if such a coin is impermissible in the relevant jurisdiction, or veto the addition of a whitelister that has a poor reputation for compliance.

The whitelisting is managed via a PermissionManager contract, in which whitelisters are designated as Permission Admins. Permission Admins are permitted to add or remove wallets grants to the Aave Arc market by calling addPermissions() and removePermissions() contract methods, respectively.

Rationale

The Aave community voted on the Snapshot proposal with Yes 149.2k AAVE (98.33%) and No 2.54k AAVE (1.67%).

Test Cases

Test cases for an implementation are mandatory for AIPs but can be included with the implementation.

Implementation

Proposal

Executes the proposal deployed at:

https://etherscan.io/address/0xA7fC6E204c2069edb0ed5Fed451F419B985eC416#code

The proposal executes the following:

IPermissionManager(0xF4a1F5fEA79C3609514A417425971FadC10eCfBE).addPermissionAdmins([0x686a12A79008246F4dF2f1Ea30d136BD6DE748B4]);

ILendingPoolConfigurator(0x4e1c7865e7BE78A7748724Fa0409e88dc14E67aA).setPoolPause(false);

provider.setEmergencyAdmin(ARC_TIMELOCK_VETO_DAO_ADDRESS);

  • Transfers ownership of the system to the ARC Market Multisig temporarily until handed over to Aave Governance.

provider.transferOwnership(ARC_MARKET_MULTISIG_ADDRESS);

Aave Arc Timelock

Aave Arc Timelock gives a guardian address the opportunity to cancel an approved governance action prior to its execution. The timelock implementation can be found here.

Copyright

Copyright and related rights waived via CC0.

03Mismatch analysis

AIMismatch analysis by Kvorummedium confidenceclaude-sonnet-5
Consistent

The proposal's decoded calldata contains a single top-level action: a call to the Aave governance short executor's queue() function, which schedules a delegatecall to the execute() function of the payload contract at 0xA7fC6E204c2069edb0ed5Fed451F419B985eC416. This target address exactly matches the address cited in the description's 'Implementation > Proposal' section as the contract that will perform the four listed sub-actions (add Fireblocks as Permission Admin, unpause the pool, transfer EmergencyAdmin, transfer ownership). Because Aave governance proposals typically bundle multiple state changes into a single payload contract that is executed via delegatecall, the on-chain decoded data available here (just the queue() call) does not itself unpack those four sub-actions — that logic lives inside the payload contract's bytecode, which is not decoded in the provided data. This is the standard and expected pattern for Aave governance proposals, so it is not treated as an omission or mismatch. Since the address referenced in the description matches the address being queued exactly, there is no target, value, or action mismatch to report. Confidence is medium (not high) because the underlying sub-call details could not be independently verified from the decoded data provided, only inferred from address correspondence and standard proposal structure.

Generated by Kvorum
model: claude-sonnet-5
provider: anthropic
profile: anthropic-strong-v1
prompt: v1.0
generated: 2mo ago
Review the decoded actions ↗

04Actions

1 total
#0queue(address[],uint256[],string[],bytes[],bool[])chain 0x1
Target
0xace1…1218
Value
0 wei
Function
queue(address[],uint256[],string[],bytes[],bool[])
Arguments
{
  "0": [
    "0xA7fC6E204c2069edb0ed5Fed451F419B985eC416"
  ],
  "1": [
    "0"
  ],
  "2": [
    "execute()"
  ],
  "3": [
    "0x0000000000000000000000000000000000000000000000000000000000000000"
  ],
  "4": [
    true
  ]
}
Calldata

05Tally

Summed from votes

Voters18
VP participating703.6K
Outcome (current)For
Current support100%

06Voters

18 total
Filter:
VoterChoice% of totalRationale
DD0xdd70…8202For189.9K26.99%—5y ago
320x32b6…4a4dFor172.9K24.58%—5y ago
9B0x9b5e…0499For111.2K15.81%—5y ago
F60xf63e…78c8For108.7K15.45%—5y ago
C10xc17c…64e1For103.3K14.69%—5y ago
450x458c…730eFor10K1.42%—5y ago
700x704d…a0dfFor3.1K0.44%—5y ago
800x80dc…c146For2.6K0.37%—5y ago
3A0x3a25…e9d2For673.30.10%—5y ago
CA0xca76…6f46For5500.08%—5y ago
950x9548…65c7For181.30.03%—5y ago
ED0xed9c…54feFor127.20.02%—5y ago
AF0xaf29…9795For119.50.02%—5y ago
5B0x5b3b…7c98For100.50.01%—5y ago
8D0x8d07…a265For500.01%—5y ago
A50xa550…668fFor18.10.00%—5y ago
F80xf85c…0ee1For8.80.00%—5y ago
A00xa0ef…2d56For80.00%—5y ago
Showing 18

07Forum

AIForum synthesis by Kvorumclaude-sonnet-5
sentiment · favorablethread · constructive

Arguments for

  • Fireblocks is a proven institutional-grade custody and security technology provider trusted by major banks and crypto players, making it well-suited to help onboard institutions into DeFi.— salmanblocks, CallamIngram, fig
  • Fireblocks meets the regulatory qualification requirements for a whitelister, being a FinCEN-registered MSB with KYC/KYB and AML/CFT compliance programs in accordance with FATF guidelines.— salmanblocks
  • This proposal represents an important and beneficial step toward bridging institutions into DeFi via Aave Arc.— Zer0dot, fig, CallamIngram
  • Approving Fireblocks could create shared expertise and mutual benefit between Aave and Fireblocks, and set a precedent simplifying future whitelister onboarding.— fig, salmanblocks

Arguments against

None surfaced.

Unresolved concerns

  • Questions about the mechanics of how Aave Arc governance will develop over time, particularly regarding the process for whitelister governance and onboarding of new fintech benefits, were not answered.— eek637
  • Uncertainty about whether the whitelister role has a term limit or would need to be periodically re-voted on was left unaddressed.— Deep9
  • Clarification was sought on whether Fireblocks acting as a whitelister could let it arbitrarily deploy Aave markets covered by the safety module, and confirmation that governance retains ultimate control including revocation power, was not explicitly confirmed by the proposer.— Zer0dot
  • Concern that the proposal passed the snapshot vote without the community's questions about governance implications being answered, raising doubts about the responsiveness of the process.— eek637
  • Request for the Aave Arc whitepaper referenced in the original proposal went unanswered for an extended period before eventually being located separately.— JC7

Notable participants

  • salmanblocksProposer who submitted the detailed proposal for Fireblocks as a whitelister and answered some clarifying questions.
  • G-BlockchainRaised detailed questions about how KYC/whitelisting would actually function between Fireblocks, institutions, and end customers.
  • eek637Repeatedly pressed for clarification on governance implications and noted unresolved concerns after the snapshot vote passed.
  • Zer0dotSought clarification on safety module and governance control implications before expressing support.
  • Deep9Raised concern about the complexity of the topic and asked about term limits for the whitelister role.
  • CallamIngramVoiced support on behalf of Blockchain@Berkeley based on positive experiences with Fireblocks.
  • figExpressed support citing Fireblocks' technology and potential shared benefits with Aave.
  • JC7Asked about the location of the referenced Aave Arc whitepaper.
  • OskarAKJNew participant who questioned whether the proposal had already been voted on and noted it seemed overlooked.
Generated by Kvorum
model: claude-sonnet-5
provider: anthropic
profile: anthropic-strong-v1
prompt: v1.0
generated: 2mo ago
Open the thread ↗