The Gavel Protocol — Token Curation Methodology

Version: 2.0 Last updated: 23 June 2026

PUBLISHER: This document is published by Aletheia Analytics SASU as the administrator of the ListingService and NFTListingService smart contracts. It describes the curation methodology applied by Aletheia Analytics to the token whitelist accessible through the thegavel.io interface. It does not describe the operation of the permissionless Protocol Layer, any user lending or borrowing decision, or any own-account activity that Aletheia Analytics may conduct with its own assets. The Gavel Protocol itself (LoanProtocol, NFTLoanProtocol, PositionNFT, NFTPositionNFT) is open-source software authored by Jamie Frame personally and is documented separately in the Risk Disclaimers and in the Protocol's source code repository.

1. Purpose and Scope

This document describes only the methodology used by Aletheia Analytics SASU (the "Company") to curate the list of digital asset tokens displayed on the Gavel Protocol interface at thegavel.io, through the ListingService and NFTListingService smart contracts (collectively, the "Curation Layer"). It does not govern, restrict, recommend or supervise the use of the underlying permissionless smart contracts.

The Curation Layer exists to reduce the risk that users of the interface encounter fraudulent, malicious, or technically defective tokens. It is a technical safety filter, not a financial recommendation service.

This methodology is a public description of interface-level curation criteria. It is not a regulatory analysis, a risk disclosure document, or a user suitability assessment.

1.1 Context: The Gavel Protocol and its Administration

The Gavel Protocol is open-source software authored by Jamie Frame (a French resident, in his personal capacity) and published under the MIT licence. It consists of smart contracts deployed permissionlessly on the Arbitrum blockchain. The Protocol itself — LoanProtocol, NFTLoanProtocol, PositionNFT, NFTPositionNFT — is fully autonomous and accepts any ERC-20 token or ERC-721 collection without restriction. The Protocol has no operating entity. Risk and operational documentation for the Protocol itself is published separately by its author.

The Curation Layer — ListingService and NFTListingService — consists of separate smart contracts that sit above the core Protocol. They maintain whitelists of tokens and NFT collections, and they have an admin key that controls which assets appear on the whitelist.

The Curation Layer forms part of the user interface and analytics environment operated by Aletheia Analytics around the open-source Gavel Protocol, alongside the thegavel.io interface and the data analytics products. This document describes the criteria that Aletheia Analytics applies when managing the Curation Layer whitelists.

1.2 What This Document Covers

This document describes the criteria, process, and governance for adding tokens to and removing tokens from the Curation Layer whitelist. It applies to both ERC-20 tokens (used as collateral or loan denomination in the LoanProtocol) and ERC-721 NFT collections (used as collateral in the NFTLoanProtocol).

1.3 What This Document Does Not Cover

This document does not constitute:

A recommendation, endorsement, or guarantee regarding any token or NFT collection
An assessment of the investment merits, future value, or financial suitability of any asset
A comprehensive security audit of any token's smart contracts
A guarantee that whitelisted tokens are free from all risk

Users are solely responsible for evaluating whether any asset is appropriate for their purposes.

2. Architecture: Protocol Layer vs. Curation Layer

Understanding the relationship between the Protocol and the Curation Layer is essential to understanding this methodology.

2.1 The Protocol Layer (Permissionless, Autonomous)

The core Gavel Protocol smart contracts (LoanProtocol, NFTLoanProtocol) are fully permissionless. They accept any ERC-20 token as collateral and any ERC-20 token as loan denomination. They accept any ERC-721 NFT as collateral. There is no restriction at the protocol level on which assets can be used.

Any user can interact directly with the Protocol smart contracts — without using the interface at thegavel.io or the Curation Layer — to create auctions, place bids, and manage loans using any token or NFT. The interface does not operate an off-chain order book, matching engine or discretionary trade execution system. Auctions, bids, finalisation and settlement are performed by the underlying smart contracts according to their published code. Documentation for direct smart contract interaction is available at the public The-Gavel-Protocol repository: https://github.com/JamieFrame/The-Gavel-Protocol.

The core Protocol has no owner and no admin keys that affect its business logic. Certain emergency pause functions exist during the initial deployment phase and are planned for progressive renunciation.

2.2 The Curation Layer (Administered)

The ListingService and NFTListingService are separate smart contracts that maintain whitelists of tokens and NFT collections. When a user interacts with the Gavel Protocol through the interface at thegavel.io, the Curation Layer restricts the available assets to those on the whitelist.

The Curation Layer does not receive, transmit or execute user instructions. It limits the assets made available through the interface according to the criteria described below.

The Curation Layer has no effect on the core Protocol itself. Tokens that are not whitelisted remain fully usable through direct smart contract interaction. The whitelist controls only what is displayed and accessible through the thegavel.io interface.

The Curation Layer has an admin key that controls the whitelists. That authority is held through the multi-signature wallet governance described in Section 6.1, and whitelist changes are traceable through on-chain events. This key is administered according to the methodology described in this document.

2.3 Architectural Diagram

`` USER ┌───────────────────────────┬───────────────────────────┐ │ Via thegavel.io │ Via direct contract access│ │ (curated interface) │ (permissionless) │ └─────────────┬─────────────┴─────────────┬─────────────┘ │ │ ┌─────────────────▼──────────────────┐ │ │ Curation Layer (administered) │ │ bypasses the │ ListingService / NFTListingService│ │ Curation Layer │ Whitelisted tokens only │ │ └─────────────────┬──────────────────┘ │ │ │ ┌─────────────────▼───────────────────────────▼─────────────┐ │ Gavel Protocol Layer (autonomous) │ │ LoanProtocol — accepts ANY ERC-20 — no restrictions │ │ NFTLoanProtocol — accepts ANY ERC-721 — no restrictions │ │ Authored by Jamie Frame, MIT licensed, │ │ deployed permissionlessly on Arbitrum │ └─────────────────────────────────────────────────────────────┘ ``

3. ERC-20 Token Curation Criteria

The Curation Layer maintains two distinct ERC-20 whitelists: one for collateral tokens and one for loan tokens. The criteria differ because the risk profiles differ.

3.1 Collateral Token Whitelist

Collateral tokens are assets that borrowers deposit to secure loans. The primary risk to lenders is receiving an asset that may be technically incompatible, non-transferable, or lack observable market activity at the relevant time. The curation criteria focus on observable technical compatibility, source-code accessibility, and publicly verifiable market activity, and do not assess investment merit or future value.

Mandatory criteria (all must be met):

(a) Smart contract verification. The token's smart contract source code must be verified and publicly readable on a block explorer (e.g., Arbiscan). Unverified contracts are excluded.

(b) Standard compliance. The token must implement the ERC-20 standard without non-standard transfer mechanics that could interfere with the Protocol's escrow logic. Specifically, the following token types are excluded:

Fee-on-transfer tokens (tokens that deduct a percentage on each transfer)
Rebasing tokens (tokens whose balances change automatically)
Tokens with transfer callbacks that could interfere with Protocol operations (e.g., ERC-777 hooks)

(c) No known malicious functionality. The token contract must not contain functions that allow the deployer or any party to arbitrarily freeze transfers, modify balances, mint unlimited supply, or otherwise manipulate the token in ways that could harm Protocol users. This assessment is based on publicly available source code review.

(d) Established market presence. The token must be listed and actively traded on at least one established decentralised exchange with verifiable on-chain liquidity, or be a widely-recognised stablecoin pegged to a fiat currency. This criterion is based on observable market activity and settlement practicality, not on any assessment of financial suitability or future value.

Additional considerations (informing but not determinative):

Age of the token contract (older, established contracts carry lower risk)
Presence on other established DeFi protocol whitelists (Aave, Compound, Uniswap default list)
Known issuer identity and jurisdiction (for stablecoins and wrapped assets)
Audit history of the token contract

3.2 Loan Token Whitelist

Loan tokens are the assets that lenders provide and borrowers receive. They represent the denomination of the loan. The curation criteria are limited to technical and operational considerations, including token-standard compatibility, observable liquidity, price stability at the time of review, and settlement practicality. They do not assess whether lending or borrowing in any token is economically appropriate for any user.

Mandatory criteria (all collateral token criteria, plus):

(e) Observable liquidity and price stability. Loan tokens are generally limited to stablecoins (USDC, USDT, DAI) and well-established major cryptocurrencies (WBTC, WETH) with observable liquidity depth and price stability at the time of review. Inclusion does not guarantee future liquidity, price stability, redemption, or settlement.

(f) Compatibility with the Protocol's fixed-rate design. Since the Gavel Protocol uses fixed-rate, fixed-term loans without liquidation oracles, loan tokens should have sufficient observable market depth for the auction and repayment mechanics to operate in a technically practical manner. This criterion does not constitute a liquidity guarantee or an assessment of any user's ability to repay.

3.3 Minimum Bid Step Calibration

When a token is added to the loan token whitelist, the administrator also sets a minimum bid step (minBidStep) for that token. This parameter defines the smallest allowed improvement between consecutive bids in an auction denominated in that token.

Why a per-token minimum bid step is necessary. Tokens vary enormously in their decimal precision and unit value. A bid step of 1 unit means something very different for USDC (6 decimals, ~$1 per unit) than for an 18-decimal token with a low unit price. Without a calibrated minimum, auctions could either be locked up by meaninglessly tiny bid improvements (forcing participants through thousands of increments to reach a meaningful rate change) or suffer from bid steps so large that genuine price discovery becomes impossible.

Calibration criteria. The minimum bid step is set per token based on:

The token's decimal precision (6 decimals for USDC/USDT; 8 for WBTC; 18 for most ERC-20s)
The token's approximate market value at the time of whitelisting
A target of meaningful economic granularity — the minimum bid step should represent a small but non-trivial change in repayment amount (for example, a fraction of one US dollar equivalent for stablecoins)
Consistency with bid steps for similar tokens on the whitelist

What this parameter does and does not do. The minimum bid step is a technical parameter that ensures auction mechanics function properly across tokens with different unit economics. It does not constrain lender behaviour beyond this floor — lenders remain free to bid any amount that improves on the current best bid by at least the minimum step. It is not a fee, a rate cap, or an interest rate floor.

Transparency. The minimum bid step for each whitelisted token is stored on-chain in the ListingService contract and is publicly readable. Changes to the minimum bid step are recorded as on-chain events.

Future recalibration. As token values change over time, a minimum bid step that was appropriate at the time of whitelisting may become too large or too small in economic terms. The administrator may update the minimum bid step for any whitelisted token, applying the same calibration criteria.

3.4 Tokens at Launch

At mainnet launch, the following tokens are whitelisted:

Collateral tokens: WBTC
Loan tokens: USDC, USDT

This initial list is deliberately conservative. It will expand over time as additional tokens are evaluated against the criteria above. WETH and DAI are not whitelisted at launch and may be evaluated for addition in a later phase.

No ERC-721 NFT collection is whitelisted at launch. The NFT-backed lending functionality is deployed and visible, but it is not available through the interface until at least one NFT collection has been reviewed and added to the Curation Layer whitelist.

4. ERC-721 NFT Collection Curation Criteria

NFT collections are used as collateral in the NFTLoanProtocol. The risk profile is distinct from ERC-20 tokens because NFTs are non-fungible and their valuation is inherently subjective.

Mandatory criteria (all must be met):

(a) Smart contract verification. The collection's smart contract must be verified and publicly readable.

(b) Standard compliance. The collection must implement the ERC-721 standard correctly and support safeTransferFrom.

(c) No transfer restrictions that could impair the Protocol. The collection must not contain pausable transfers, blocklists, or other mechanisms that could prevent the Protocol from releasing collateral on repayment or transferring it to the lender on default.

(d) Established provenance. The collection must have a verifiable history of trading activity on recognised NFT marketplaces, demonstrating genuine market interest and price discovery.

(e) No known fraudulent origin. The collection must not be a known copy, counterfeit, or derivative of another collection created with intent to deceive.

Additional considerations:

Floor price history and trading volume over time
Community size and activity
Creator identity and reputation (where applicable)
Presence on other DeFi protocol whitelists

5. Curation Process

5.1 Initial Review

When a token or NFT collection is identified for consideration, whether through external suggestion or the administrator's own monitoring of the market, a review may be conducted against the criteria set out in Sections 3 and 4. External suggestions do not create any right to review, listing, response, explanation or inclusion on the whitelist. The review is conducted using publicly available information: block explorer data, smart contract source code, market data from on-chain sources, and published audit reports where available.

5.2 Decision

The decision to add or remove a token from the whitelist is made by the administrator based on the objective criteria described in this document. Curation decisions are made solely on the basis of the technical and operational criteria described in this document. Any potential conflict of interest between a curation decision and Aletheia Analytics' own on-chain activity is documented and resolved in favour of those criteria. Aletheia Analytics does not accept and has no current intention to accept any payment or other consideration in exchange for whitelisting decisions. This policy may be updated in future versions of this document.

5.3 Addition to Whitelist

If a token meets all mandatory criteria, the administrator may add it to the appropriate whitelist by calling the relevant function on the Curation Layer smart contract. For loan tokens, this operation also sets the minimum bid step parameter as described in Section 3.3. Addition to the whitelist is an interface configuration decision only and does not constitute endorsement, recommendation, certification, or approval of the asset. All whitelist changes, including bid step configuration, are recorded as on-chain events and are publicly auditable.

5.4 Removal from Whitelist

A token may be removed from the whitelist if:

New information reveals that the token no longer meets the mandatory criteria (e.g., discovery of a vulnerability, introduction of a fee-on-transfer mechanism, regulatory action against the issuer)
The token's on-chain liquidity falls below levels sufficient for safe use as collateral
The token's smart contract is upgraded in a way that introduces non-standard behaviour

Removal from the whitelist does not affect existing loans or auctions that use the removed token. It only prevents new auctions from being created through the thegavel.io interface using that token. It does not prevent users from interacting directly with the core Protocol smart contracts, where technically possible, outside the interface.

5.5 Public Record

All whitelist additions and removals are recorded on-chain through the CollateralTokenUpdated, LoanTokenUpdated, and CollectionWhitelistUpdated events emitted by the Curation Layer contracts. Anyone can verify the current whitelist state and its history by reading the smart contract directly.

6. Governance and Administration

6.1 Current and Target Administration

The Curation Layer is administered by Aletheia Analytics SASU. The admin authority is held in a multi-signature wallet (Gnosis Safe) under the governance arrangements described below. Changes to the whitelists or to the bid step parameters require approval from multiple signers before execution. This mechanism is intended to support operational control, internal accountability and on-chain traceability of curation decisions. Pending completion of Aletheia Analytics' incorporation and transfer of the relevant administrative rights to a dedicated Aletheia Safe, these rights remain held by the current multi-signature Safe. Following incorporation, they are intended to be transferred to the dedicated Aletheia Safe.

The Company's administrative actions are limited to managing the Curation Layer (whitelists and bid step parameters). The Company has no administrative authority over the core Gavel Protocol itself, which is autonomous open-source software authored by Jamie Frame personally.

6.2 Smart Contract Constraints

The Curation Layer smart contracts impose the following constraints on administration:

Fee changes are capped by hardcoded maximums in the contract (1% maximum for auction fees, $100 maximum for marketplace listing fees). At launch, fees are set to zero and there is no plan to activate them — the business model does not rely on protocol-level fees. Any activation of protocol-level fees, marketplace fees, listing fees, or transaction-linked fees would constitute a material change to the current operating model.
Batch whitelist operations are limited to 50 tokens per transaction to prevent gas-related issues.
All administrative actions emit on-chain events, providing a complete and immutable audit trail.

6.3 What the Administrator Cannot Do

Aletheia Analytics, as administrator of the Curation Layer, cannot:

Access, move, freeze, or redirect any user's funds or assets
Modify the terms of any existing loan or auction
Alter the Gavel Protocol Layer's smart contract logic
Override the Protocol's permissionless access — users can always interact directly with the core Protocol contracts regardless of Curation Layer whitelist status

6.4 Path to Renunciation

The administrative controls described in this document are considered appropriate for the current operational phase. During this phase, those controls are constrained by published criteria, multi-signature approval and on-chain event traceability, and are not intended to amount to discretionary management of the Protocol Layer. The Company may, in due course, reduce or transfer these controls — for example by migrating curation decisions to a community governance mechanism, by progressively renouncing parameters that no longer require active management, or by other means that further reduce the administrative surface. Updates to the governance arrangements will be published in future versions of this document.

This public methodology is supplemented by an internal governance policy governing operational procedures, roles, records and on-chain decision processes applicable to curation decisions.

7. Important Disclaimers

7.1 No Guarantee of Safety

Inclusion of a token or NFT collection on the whitelist does not guarantee that the asset is safe, that its value will be maintained, or that it is suitable for any particular purpose. The curation criteria assess technical integrity and market presence, not financial merit.

7.2 No Financial Recommendation

The whitelist is a technical safety filter. It is not a "recommended assets" list, an investment recommendation, a financial analysis, or advice of any kind. Users must conduct their own evaluation of any asset before using it in a lending or borrowing transaction. Aletheia Analytics does not receive, transmit or execute user orders, does not hold user assets, does not provide investment advice, portfolio management, brokerage, custody, transfer or trading platform services, and does not act as an intermediary between borrowers and lenders.

7.3 Limitations of the Review

The review is based on publicly available information at the time of assessment. It does not constitute a formal security audit. Smart contracts may contain undiscovered vulnerabilities. Market conditions may change. Issuers may take actions that affect a token's properties after the review has been conducted. Whitelisting does not guarantee liquidity, market depth, execution, repayment, collateral recovery, exit from any position, or absence of asset-specific risks. Specific risk disclosures, including risks relating to stablecoins and asset issuers, are addressed in separate Risk Disclaimers.

7.4 Direct Protocol Access

Users who wish to use tokens or NFT collections that are not on the whitelist may do so by interacting directly with the core Protocol's smart contracts. The thegavel.io interface and the Curation Layer do not restrict or control access to the core Protocol. Documentation for direct interaction is available at the public The-Gavel-Protocol repository: https://github.com/JamieFrame/The-Gavel-Protocol.

7.5 No Regulatory Classification Analysis

This document does not constitute a regulatory analysis of the classification of any asset, position, token, on-chain right or activity under applicable financial instruments, banking, credit, crypto-assets or other financial services laws.

8. Changes to This Methodology

This methodology may be updated from time to time to reflect changes in the market, developments in smart contract security practices, operational experience, or regulatory guidance. Material changes will be published at this document's canonical location on the thegavel.io interface (currently https://thegavel.io/curation-methodology), together with the version history below.

All changes to the whitelist itself — regardless of whether the methodology has changed — are recorded on-chain and publicly verifiable.

9. Version History

Version 2.0 — 23 June 2026. Current published version. Sets out the curation criteria for ERC-20 collateral and loan tokens and for ERC-721 collections, the minimum bid step calibration, the launch whitelist (WBTC as collateral; USDC and USDT as loan tokens; no NFT collection at launch), the Curation Layer governance, and the transitional multi-signature Safe arrangement pending incorporation.

Prior versions were internal working drafts and do not form part of the public record.

This document is published by Aletheia Analytics SASU and describes the token curation methodology applied to the thegavel.io interface to the Gavel Protocol. The Gavel Protocol itself is open-source software authored by Jamie Frame in his personal capacity and is not a service of Aletheia Analytics. This document does not describe any own-account activity of Aletheia Analytics and does not create any obligation, warranty, guarantee, recommendation, intermediation service or client mandate.