Saffron Finance
DeFi · Decentralized Yield ServicesToken Transparency Filing
Project & Team
Description of Project
Provide a concise narrative that clearly states each of (a)–(e) below.
- (a) Problem the project solves — The problem the project is solving.
- (b) Operational priorities — Provide a high-level description of how the project expects to support ongoing development and operations over time.
- (c) High-level project overview — How the project works at a high level.
- (d) Primary token functions — The primary functions of the token (e.g. gov participation).
- (e) Control surface reliance — If any, briefly describe the anticipated or possible evolution of the protocol's governance/control model.
(a) Problem the project solves
Saffron is a new fixed yield DeFi primitive. Saffron vaults split fees earned on Uniswap into fixed and variable yield. Fixed yield is paid upfront. Variable yield buyers earn all future yield from the deposited Uniswap position. Saffron vaults are permissionless, immutable, and non-upgradable smart contracts live on all EVM chains. Uniswap fees are the first underlying yield source for Saffron vaults.
Saffron is the first structured yield liquidity layer for DeFi.
Saffron can be used for many practical applications:
- earn an upfront payment with a productive asset
- incentivize onchain liquidity for any token
- buy a hedge before a price movement
- loop liquidity to earn more yield by accepting higher path dependency
- borrow against yield from the future
(b) Operational priorities
Saffron funds development and operations from the protocol fee, currently set at 1250 bps of gross variable side earnings and deducted before distribution. The rate is fixed in each vault at initialization and cannot be changed for a vault that exists. Saffron Finance, inc will continue to develop and maintain the protocol.
Saffron raised over $2 million from Coinbase Ventures, Dragonfly Capital, Multicoin Capital, CMS Holdings, Tally Capital, DeFi Technologies, and many other leading crypto firms and prominent industry leaders.
(c) High-level project overview
Saffron Fixed Income Vaults enable zero-coupon swaps on Uniswap V3 liquidity positions. The fixed side provides liquidity and sells their future trading fees for a guaranteed upfront payment. The variable side pays this premium, speculating that the yield earned will exceed their cost.
Participants
- Fixed side — Provides a Uniswap V3 position. Receives a guaranteed premium upfront instead of uncertain trading fees. Limited to one depositor per vault.
- Variable side — Pays the premium in exchange for all trading fees generated during the vault’s duration. Multiple depositors can participate, sharing yield proportionally.
Vault Mechanics
- A vault is created with configured duration, capacities, and pool parameters
- The fixed side deposits token0 and token1, minting a Uniswap V3 position
- The variable side deposits the premium amount
- Once both sides reach capacity, the vault starts automatically
- The fixed side calls
claimto receive their premium - The Uniswap position earns trading fees for the configured duration
- After maturity, the fixed side withdraws their original liquidity (token0/token1)
- The variable side withdraws all accumulated trading fees
(d) Primary token functions
SFI is used to vote on governance proposals and controls the DAO and treasury.
Voting runs in the space saffron-finance.eth on snapshot.org.
80% of protocol fees earned on Saffron are used to buyback SFI from the open market.
(e) Control surface reliance
Vault contracts are immutable at deployment. Contracts have no upgrade path, and admin keys have no control over user funds. No evolution is anticipated.
Known Project Team
For each existing entity: Labs/DevCo (e.g., Founder, CEO, CTO, COO), Foundation (e.g., President, Executive Director, CFO, COO), and DAO / onchain governance leadership (if applicable) list the:
- (a) full names,
- (b) official titles,
- (c) and prior experience of key team members.
For any non-existent entity, explicitly mention it does not exist. External links may be included but they will not factor into the score.
Labs / DevCo
Full Name | Official Title | Prior Experience |
|---|---|---|
Joseph Fiscella | CEO | Senior Blockchain Developer, Galaxy Digital |
Davi Ortega, PhD | Chief Scientist | International Fellow, California Institute of Technology |
Foundation
Full Name | Official Title | Prior Experience |
|---|---|---|
No Foundation exists. | No Foundation exists. | No Foundation exists. |
DAO / Onchain Governance
Full Name | Official Title | Prior Experience |
|---|---|---|
No named DAO leadership exists | No named DAO leadership exists | No named DAO leadership exists |
DAO Structure
Provide a structured description of the DAO's governance, powers, and economic rights. If a DAO does not exist, state so for each sub question. Even if there is no DAO, there must be an answer to (d). Address the lettered items below.
- (a) IP ownership & control — State what IP the DAO owns or controls (e.g., codebases/repos, trademarks/brands). Note any license if relevant.
- (b) Contract/admin powers — List on-chain or administrative authorities and limits: pause/upgrade roles (e.g., multisig pause), governance-executor authorities, and the method of authority for each (e.g., veto, majority, super-majority).
- (c) Locked-token rights (conditional) — If locking/staking for additional rights exists, explain the additional rights and what tokenholders can and cannot decide. If no locking mechanism exists, leave absent.
- (d) Current tokenholder governance rights and economic arrangements — If any, describe the current governance rights of tokenholders and any presently operative rights or arrangements relating to treasury actions, fee-routing, rewards, buybacks, or other protocol-controlled resources. If none, state that explicitly.
- (e) Control surface reliance — If any, briefly describe the anticipated or possible evolution of the protocol's governance/control model.
- (f) Dissolution authority — State who can dissolve/wind up the DAO and by what mechanism (e.g., on-chain vote threshold, board resolution of a legal wrapper).
(a) IP ownership & control
The DAO controls the treasury and protocol fee adjustments. Saffron Finance, Inc. controls all Saffron IP.
(b) Contract/admin powers
- Vault factory,
0x7fe802b891734db681b7353bff9e6c85ce0ab200
- Deploy vaults, set fee recipient, single key
- Factory owner,
0x58ca1eaed80896400122164abe16d77b2b4ff7c9
- No admin, pause, upgrade, or setter exists, EOA
- Treasury,
0x810908b50eCc5e8A177729ea8f9f888b8C6Fec08
- Holds protocol funds and SFI, Gnosis Safe, 4 of 7
- SFI token,
0xb753428af26E81097e7fD17f40c88aaA3E04902c
set_governance,set_minter,erc_sweep, single key
- SFI governance,
0x2885402c22fbd63952f759ad380402b63d0355ea
- No admin, pause, upgrade, or setter exists,EOA
(c) Locked-token rights (conditional)
Saffron operates no locking or staking mechanism. In a previous iteration a staking mechanism was utilized, which is currently deprecated.
(d) Current tokenholder governance rights and economic arrangements
Tokenholders decide treasury actions and buybacks. Treasury spending, grants, liquidity provision, buybacks, staking reward programs are controlled by SFI token voting.
(e) Control surface reliance
No evolution is anticipated.
(f) Dissolution authority
DAO dissolution can only be actioned by a successful governance vote on snapshot.org.
Primary Foundation
For the Primary Foundation do the following independently. If a Foundation does not exist, state so for each sub question. Items (a)–(f) apply only if that entity exists; state explicitly that the entity doesn't exist. Definition: The primary Foundation can be explained as the entity which is directly involved in the issuance of the native token at launch.
- (a) Entity — Type and jurisdiction.
- (b) IP ownership & control — What IP the entity owns/controls (repos/code, trademarks/brand; license optional)
- (c) Powers over DAO, treasury, protocol-controlled resources, and token administration — If any, describe the current powers over DAO governance, treasury actions, protocol-controlled resources (e.g. revenue), token administration, or reward parameters, and the method/threshold for each.
- (d) Powers over DevCo — Explain whether the foundation can exert direct or indirect influence over decision-making of the DevCo.
- (e) Contract/admin powers — Pause/upgrade/governance-executor authorities, and the method/threshold for each (e.g., veto/majority/super-majority).
- (f) Current economic arrangements and distribution policies — Describe any current governance-approved, contractual, or programmatic mechanisms, if any, by which protocol-controlled resources, treasury assets, fees, revenue, rewards, or token distributions may be directed to this entity, its equityholders, contributors, or other participants. If no such mechanism currently exists, state that explicitly.
(a) Entity
No Foundation exists.
(b) IP ownership & control
No Foundation exists.
(c) Powers over DAO, treasury, protocol-controlled resources, and token administration
No Foundation exists.
(d) Powers over DevCo
No Foundation exists.
(e) Contract/admin powers
No Foundation exists.
(f) Current economic arrangements and distribution policies
No Foundation exists.
Primary DevCo
For the Primary DevCo do the following independently. If an entity does not exist, state that explicitly across each sub-question. Items (a)–(f) apply only if that entity exists; state explicitly that the entity doesn't exist. Definition: The primary DevCo can be explained as the entity which is directly involved in the issuance of the native token at launch.
- (a) Entity — Type and jurisdiction.
- (b) IP ownership & control — What IP the entity owns/controls (repos/code, trademarks/brand; license optional)
- (c) Powers over DAO, treasury, protocol-controlled resources, and token administration — If any, describe the current powers over DAO governance, treasury actions, protocol-controlled resources (e.g. revenue), token administration, or reward parameters, and the method/threshold for each.
- (d) Powers over Foundation — Explain whether the DevCo can exert direct or indirect influence over decision-making of the Foundation.
- (e) Contract/admin powers — Pause/upgrade/governance-executor authorities and the method/threshold for each (e.g., veto/majority/super-majority; "3/5 multisig").
- (f) Current economic arrangements and distribution policies — Describe any current governance-approved, contractual, or programmatic mechanisms, if any, by which protocol-controlled resources, treasury assets, fees, revenue, rewards, or token distributions may be directed to this entity, its equityholders, contributors, or other participants. If no such mechanism currently exists, state that explicitly. Do not discuss hypothetical future dividends, repurchases, or distributions unless formally adopted.
(a) Entity
Saffron Finance, Inc. is a corporation incorporated in Delaware, United States. Its registered address is 874 Walker Rd Ste C, Dover, DE 19904. Contact is info@saffron.finance.
(b) IP ownership & control
Saffron Finance, Inc. owns the intellectual property. It holds the repositories and the codebase, and it holds the trademarks and the brand.
(c) Powers over DAO, treasury, protocol-controlled resources, and token administration
Saffron Finance, Inc. holds no formal power over the DAO's governance process. Voting is open to any SFI holder, weighted by balance, and the entity holds no special voting rights or veto.
With respect to the treasury: 1 of the 7 signers on the 4-of-7 treasury Safe (0x810908b50eCc5e8A177729ea8f9f888b8C6Fec08) is affiliated with Saffron Finance, Inc. The affiliated signer cannot unilaterally execute or block transactions under the 4-of-7 threshold.
With respect to token administration: the SFI token's governance key (0x2885402c22fbd63952f759ad380402b63d0355ea) is held by Saffron Finance, Inc. and can call set_governance, set_minter, and erc_sweep.
With respect to protocol-controlled resources: Saffron Finance, Inc. holds the vault factory owner key (0x58ca1eaed80896400122164abe16d77b2b4ff7c9), which carries authority to deploy vaults and set the vault fee recipient. The current fee recipient is the DAO treasury Safe, 0x810908b50eCc5e8A177729ea8f9f888b8C6Fec08.
No other reward, emission, or incentive parameters exist in the protocol contracts. The fee rate itself settable only at vault deployment.
Minting is not currently possible, as the maximum supply was fixed following the governance vote that closed 2026-07-07 and no active minter is set. The erc_sweep function serves solely to recover ERC-20 tokens accidentally sent to the token contract. It cannot access holder balances or protocol funds.
(d) Powers over Foundation
No Foundation exists.
(e) Contract/admin powers
The vault factory (0x7fe802b891734db681b7353bff9e6c85ce0ab200) is owned by a single key (0x58ca1eaed80896400122164abe16d77b2b4ff7c9) with authority to deploy vaults and set the fee recipient. This key is held by Saffron Finance, Inc.
The SFI token contract's governance key (0x2885402c22fbd63952f759ad380402b63d0355ea, an EOA) holds set_governance, set_minter, and erc_sweep authority and is held by Saffron Finance, Inc.
With respect to protocol-controlled resources: Saffron Finance, Inc. holds the vault factory owner key (0x58ca1eaed80896400122164abe16d77b2b4ff7c9), which carries authority to deploy vaults and set the vault fee recipient. The current fee recipient is the DAO treasury Safe, 0x810908b50eCc5e8A177729ea8f9f888b8C6Fec08.
No other reward, emission, or incentive parameters exist in the protocol contracts. The fee rate itself settable only at vault deployment.
Saffron Finance, Inc. holds no other admin, pause, upgrade, or setter authority over protocol contracts.
(f) Current economic arrangements and distribution policies
Saffron Finance, Inc. holds no allocation of SFI supply, owns no portion of the DAO treasury, and holds no entitlement to protocol revenues. The 1250 bps vault fee referenced in 1b accrues to the fee recipient set on the vault factory (0x7fe802b891734db681b7353bff9e6c85ce0ab200). The current recipient is the DAO Treasury (0x810908b50eCc5e8A177729ea8f9f888b8C6Fec08), and disposition of those funds is under the exclusive jurisdiction of the DAO and token holders.
No mechanism currently directs protocol resources, fees, or treasury funds to Saffron Finance, Inc., its equityholders, or its contributors. As disclosed in 1b, Saffron Finance, Inc. performs ongoing development and operations; historically and currently it has done so without compensation from the protocol or treasury, and no DAO-approved grants or treasury payments to Saffron Finance, Inc. have been proposed or approved to date.
As disclosed in 5c and 5e, Saffron Finance, Inc. holds the vault factory owner key (0x58ca1eaed80896400122164abe16d77b2b4ff7c9), which carries the technical authority to change the vault fee recipient, including to an address controlled by Saffron Finance, Inc. This authority has not been exercised for the entity's benefit; the fee recipient has remained the DAO treasury Safe.
Token Supply & Allocations
Initial Allocation
Download the Worksheet, enable macros, complete the Initial Allocation sheet, then use Convert To CSV to export the file for import here. To make edits after importing, update the worksheet, use Convert To CSV again, then re-import the new CSV.
Ticker | Date | Allocation Category Name | Recipient Type | Allocation % | Allocation Tokens | TGE Unlock % | TGE Unlock Tokens | Cliff Months | Cliff Unlock % | Linear Vesting Months | Cadence Months | Circulating Treatment | Notes on what each category is used for | If applicable: Contract / Wallet address |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
SFI | 2020-11-15 | Liquidity mining | Emissions | 0.65177225512 | 65177.225512 | 0.460283477308751 | 30000.0 | 0 | 0 | 10 | 1 | Yes | All Saffron v1 epochs 2020-11-15 to 2021-08-22. 65177.225512 SFI minted of which 61777.0215 to 233 pool contracts. 1982 distinct external recipients | 0xdc41bbb87200d4e28a244e008cfe39a459a87fde |
SFI | 2020-11-15 | Team and contributors | Insiders | 0.15 | 15000 | 0.6666666666666666 | 10000.0 | 0 | 0 | 1 | 1 | Yes | The team share of the first two epoch mints at 25% of each paid to a multisig on 2020-11-15 and 2020-11-29. It distributed 15000 to 13 accounts held by team and contributors by 2020-11-29. Fully minted and unlocked | 0x866f288397fa0e8c0551f97bf4419097686bfc7b |
SFI | 2020-12-13 | DAO | Treasury | 0.119452763 | 11945.276337 | 0 | 0.0 | 0 | 0 | 8 | 1 | Yes | The protocol share of every epoch mint from 2020-12-13 to 2021-08-22. Fully minted and unlocked at 2021-08-22 | 0x09e9ff67d9d5a25fa465db6f0bede5560581f8cb |
SFI | 2026-07-21 | DAO supply completion | Treasury | 0.078774982 | 7877.498151 | 1 | 7877.5 | 0 | 0 | 0 | 0 | Conditional | Minted 2026-07-21 in a single event following the vote that closed 2026-07-07 to fix maximum supply. Forwarded to the DAO Treasury 0x810908b50eCc5e8A177729ea8f9f888b8C6Fec08. Tokens are held there until a vote passes and tokens are released. | 0x810908b50eCc5e8A177729ea8f9f888b8C6Fec08 |
Airdrop Process
State the project's airdrop status plainly, and back it up:
- Never conducted and none planned for TGE: state so plainly.
- Planned but not yet executed: state the target user segments (e.g., "stakers of X," "Aave users") and the allocation method (e.g., proportional to balance or net position), and commit to publishing a recipient wallet list in a public channel and providing it to Blockworks quarterly until the initial TGE airdrop is fully completed.
- Already executed: state the covered user segments and the allocation method, and point to a per-address source such as CSV/TSV/JSON files, a Dune table, a full Merkle dump, GitHub repo files embedding per-address allocations, or RPC endpoints that expose claim/amount data; explorer links alone do not count.
Never conducted and none planned.
Transactions & Market Structures
Market Maker Agreements & Deals
Projects must disclose all material terms of market-making arrangements that affect token liquidity. If the project has no agreements or deals with market makers, state that explicitly. For each market maker, include in a table:
- (a) Market maker's name — the market maker's name;
- (b) Token allocation or loaned amount — the token allocation or loaned amount as a percentage of total supply;
- (c) Duration/term of agreement — the duration/term of the agreement; and, where applicable,
- (d) Name of agreement structure — label the financial vehicle being used in the agreement (i.e. loan, option/call, retainer model).
If no native tokens were loaned or allocated to market makers, state that explicitly; cash/fiat retainers or fees are not required for (b).
Market Maker Name | Token Allocation Committed | Term Duration | Structure Name |
|---|---|---|---|
Saffron has no market maker agreements and has never loaned or allocated SFI to a market maker. | Saffron has no market maker agreements and has never loaned or allocated SFI to a market maker. | Saffron has no market maker agreements and has never loaned or allocated SFI to a market maker. | Saffron has no market maker agreements and has never loaned or allocated SFI to a market maker. |
Exchange Agreements & Deals
Projects must disclose all material terms of centralized or decentralized exchange listings that affect token liquidity. For each listing, include in a table:
- (a) Exchange name / DEX pool — the exchange name (and, for DEX, the specific pool/pair);
- (b) Token allocation for listing — the token allocation supplied or committed for listing as a percentage of total supply;
- (c) Term Duration — the duration/term of any listing lockups, liquidity, or incentive programs; and, where applicable,
- (d) Native-token listing fees — whether any listing fees were paid in native tokens, with amounts (tokens or % of supply), recipients, and any vesting or lock terms tied to the partnership.
If the project has no agreements or deals with CEX or DEX, state that explicitly; doing so earns full credit; cash/fiat fee amounts are not required for this item.
Exchange Name | Token Allocation Committed | Term Duration | Native Token Listing Fees |
|---|---|---|---|
Gate.io | 0 | None. no lockup, liquidity commitment, or incentive program | No listing fee was paid in SFI or any other form of native tokens. |
Uniswap (SFI/ETH and other pairs) | 0 | Permissionless | None. Uniswap pools are permissionless; no agreement exists with Uniswap Labs and no listing fee applies. |
Financial Disclosures & Risks
Prior Token Sales & Fundraising
Disclose all prior token sales by the Project — including fundraising rounds, any material OTC sales to investors, and any discounted market-maker sales. For each sale, provide:
- (a) Series Name;
- (b) Early-Stage Investment Instrument used (i.e. SAFT, STAMP, SAFE, SAFE+Token Warrant, etc.);
- (c) Date of sale (at least month & year);
- (d) Number of tokens sold (or % of total supply);
- (e) Vesting schedule.
If no prior sales occurred, state that explicitly (e.g., "No prior fundraising, OTC, or discounted MM sales have occurred.").
Series Name | Investment Instrument | Date Of Sale | Number of tokens sold | Vesting Schedule |
|---|---|---|---|---|
Seed | Spot Commodity Sale | March 8th 2021 | 8000 | 2 Years |
Previous Exploits Affecting The Native Token
If any, list prior exploits or incidents that directly affected the token, token supply, tokenholder balances, token contract, minting controls, burn mechanics, or custody of token supply. This question is not asking about general protocol, application, or smart contract exploits unless the incident directly affected the native token itself. If no prior incidents, state this explicitly (e.g., "No exploits affecting tokenholders or protocol funds as of YYYY-MM-DD").
- (a) Date & component affected — Date (YYYY-MM or YYYY-MM-DD), chain(s)/component affected.
- (b) Exploit vector summary — Plain-language summary of the exploit vector (what the hack was).
- (c) Quantified impact — Quantified impact (assets/tokens affected or a clear "no loss of funds" statement).
- (d) Remediation/response taken — Remediation/response taken (patches, upgrades, governance actions, compensation).
- (e) Current status — Current status (resolved, in litigation, under investigation, refunded, etc.).
- (f) References — Link(s) to post-mortem/advisory/PR.
(a) Date & component affected
No exploits affecting tokenholders or protocol funds as of 2026-08-05
(b) Exploit vector summary
N/A
(c) Quantified impact
N/A
(d) Remediation/response taken
N/A
(e) Current status
N/A
(f) References
N/A
Material Risk Factors (Regulation, Technology, Token Economics)
Describe material risk factors across the three categories below. Each category includes prompts to address at a minimum.
-
(a) Regulatory, Legal & Tax Risks — Describe how evolving laws and regulations could affect the project by answering, at a minimum, questions like:
-
Impact of Regulatory Change on TGE and Listings: (If applicable) How could evolving or conflicting laws and regulations affect your ability to complete the TGE, deliver tokens to purchasers, and list or maintain the token on trading venues in key jurisdictions?
-
Entity-Level Regulatory Impact: (If applicable) How could regulatory or legal changes impact your core entities (Foundation, DevCo, DAO, affiliated service providers), including enforcement actions, licensing requirements, or forced changes to structure or operations?
-
Tokenholder Tax Treatment: (If applicable) What uncertainties exist around how tokenholders may be taxed, and make clear that tokenholders are responsible for understanding their own tax obligations?
-
Jurisdictional & User Access Restrictions: (If applicable) If the project restricts access for certain jurisdictions or user types (e.g., U.S. persons, sanctioned countries, retail vs. professional), what are those restrictions and what risks do they create for users and for the project?
-
(b) Protocol, Technology & Security Risks — Describe risks to network and contract reliability, correctness, and safety by answering, at a minimum, questions like:
-
Bugs and Design Flaws: (If applicable) What bugs, design flaws, or implementation errors could exist in your core protocol code, smart contracts, and any bridges, rollups, or oracles that you depend on, and how could these lead to loss of funds or disruption of the protocol?
-
Security Measures & Their Limitations: (If applicable) What security measures have you taken (audits, formal verification, bug bounties), and what types of failures might these measures still fail to detect or prevent?
-
(c) Token Economics, Unlocks & Incentive Risks — Describe how the token's economic design and supply schedule could affect holders by answering, at a minimum, questions like:
-
Critical Economic Assumptions: (If applicable) Which economic assumptions (e.g., staking yields, fee revenue, liquidity incentives, MEV capture, demand for blockspace) are critical for protocol security, utility, and governance, and what happens if those assumptions fail?
-
Governance Control over Monetary Policy & Rewards: (If applicable) To what extent can governance change monetary policy, fee parameters, or reward allocations (e.g., inflation rate, treasury flows, incentive programs), and how could such changes adversely affect tokenholders?
(a) Regulatory, Legal & Tax Risks
SFI was issued in November 2020 by an anonymous developer. There was no token sale or airdrop, all tokens were minted by users depositing DAI to a Compound Finance market during a liquidity mining event. SFI supply is fixed at a 100,000 token cap, it is fully minted, no further issuance is possible, and no outstanding delivery obligation exists.
SFI is a standard ERC-20 token, and as a result, any venue, bridge, or aggregator can delist or block it as they could with any other ERC-20 token.
Saffron Finance, Inc. is a Delaware corporation that holds the intellectual property.
Treatment of SFI as an asset class different across jurisdictions and is subject to regional guidelines applying to ERC-20 tokens.
Tokenholders are responsible for determining and meeting their own tax obligations, and Saffron provides no tax advice, reporting, or cost basis records.
(b) Protocol, Technology & Security Risks
Vault code is immutable once deployed. A defect found after deployment cannot be patched in a live vault, and the response available is to stop creating new vaults with the affected configuration. Existing vaults run until end of their lifecycle.
The Saffron smart contract system has been fully audited by industry leading security experts:
- 0xleastwood (2026-01-14)
- ChainSecurity (2025-12-15)
- WebThree (2025-11-18)
- Internal (10-25-2025)
- Sherlock (2025-10-18)
- Pashov (2025-07-21), (01-28-2024)
- Halborn (2025-06-19)
- QuantStamp (01-13-2023)
For more information, see: https://docs.saffron.finance/security/audits
(c) Token Economics, Unlocks & Incentive Risks
SFI carries no security or revenue dependency. Supply has been fully distributed since 2020 with no vesting, no cliffs and no unlock overhang outstanding.
Protocol fee parameters, treasury flows, and subsidy programs do sit with governance, which sets the fee rate applying to vaults created after a change and funds incentive programs from the treasury.
This Token Transparency Filing is provided for general informational purposes only. Blockworks reviews completeness only and does not verify or warrant the accuracy of individual answers. saffron.finance is solely responsible for the content, accuracy, and legality of its disclosures.
