# Spark Docs
## FAQ
For product-specific questions, see the FAQ on each product page:
* [Spark Savings FAQ](/products/spark-savings#faq)
* [SparkLend FAQ](/products/sparklend#faq)
* [Spark Liquidity Layer FAQ](/products/spark-liquidity-layer#faq)
### What is Spark?
Spark consists of three main products:
* **[Savings](/products/spark-savings)**: Earn yield on your stablecoin and ETH holdings via Spark Savings vaults.
* **[SparkLend](/products/sparklend)**: A USDS-centric money market protocol, combining liquidity directly from Sky with vertical integrations across DeFi.
* **[Spark Liquidity Layer (SLL)](/products/spark-liquidity-layer)**: Direct liquidity provision into DeFi markets across networks.
### What is Spark's Mission?
Spark was created to solve a structural problem that has existed since the inception of DeFi: fragmented liquidity, unstable yields, and idle stablecoin capital left underutilized across chains and protocols. Despite years of growth, this issue remained unsolved.
Spark operates as a two-sided capital allocator. On the ecosystem side, it borrows from Sky's stablecoin reserves and deploys capital across DeFi, CeFi, and RWAs. This provides deep, consistent liquidity while earning risk-adjusted yield at scale.
On the user side, Spark packages that yield into accessible products like Spark Savings vaults (sUSDS, spUSDC, spUSDT, spETH, and more), giving users seamless access to onchain, programmable income that is diversified, fee-free, and composable.
Rather than competing with other protocols, Spark powers them. It's not just another DeFi app, it is the core liquidity and yield infrastructure layer for onchain finance.
### What is Spark Sky Star?
Spark is a Sky Star, a part of the Sky Ecosystem. [You can read more about Sky Stars here.](https://forum.makerdao.com/t/sky-has-arrived/24959#p-98600-spark-the-first-sky-star-14)
Spark.fi is a front-end that gives access to the products offered by the Spark Sky Star.
## Getting Started
### Accessing Spark App
The Spark App can be accessed at:
* [app.spark.fi](http://app.spark.fi)
To enter the site, you must accept the [Terms of Service](https://spark.fi/terms-of-use.html).
### Application Overview
The Spark App consists of four main sections - click on a section title for specific tutorials:
1. [**Savings**](/products/spark-savings/guides/) - The landing page of the application hosts Savings. Savings enables you to earn savings on your assets using Spark Savings Vaults.
2. **SparkLend** - Contains three sections:
1. [**Borrow stablecoins**](/products/sparklend/guides/borrow-stablecoins), which enables you to borrow supported stablecoins using crypto assets as collateral. This section is focused on stablecoin borrowing only.
2. [**My portfolio**](/products/sparklend/guides/borrowing-assets) - Shows the state of your borrow and lending position. Here you can also manage lending and borrow positions of any supported asset.
3. [**Markets**](/products/sparklend/guides/overview-of-markets) **-** gives an overview of the total state of the supported lending markets, such as total liquidity and total borrows. Offers detailed information for each market, and the option to enter the markets.
3. **SPK** - Contains four sections:
1. [**Staking**](/staking/) - Enables users to stake SPK tokens to earn rewards.
2. [**Airdrop**](/airdrop/) - Displays summary of the airdrop campaign.
3. [**SPK Farming**](/user-guides/farming-rewards/) - Enables users to deposit USDS to farm SPK tokens.
4. [**Governance**](/governance/) - Enables users to delegate their voting power to a delegate.
4. [**Swap**](/user-guides/swap/) - Enables users to swap between supported stablecoins at no slippage.
*Spark App Landing Page*
#### Connecting Your Wallet
In order to access the Spark App you must connect a crypto wallet. You do so by clicking “Connect Wallet” in the top right corner of the app, select your wallet of choice, and finalize the connection process for the specific wallet.
*The Connect Wallet Button in the Top Right corner of the Spark App*
*Connect to Spark with your favorite wallet*
#### Selecting Network
Make sure you are connected to the desired blockchain network.
In the top right corner, you are able to change between blockchain networks supported by Spark. The current supported networks are Ethereum, Base, Arbitrum, Gnosis, Optimism, Unichain and Avalanche.
*Network Selection*
*Network Selection*
#### Sandbox Mode
If you wish to test out the Spark Application you can click on the three dots (…) next to Connect Wallet and click on the Sandbox mode. This will give you access to a newly generated test wallet with test funds on a test network, giving you the option to familiarize yourself with the application before spending any real funds.
*Sandbox Mode*
*Activate Sandbox*
#### Watch Wallet Mode
Watch Wallet mode lets you view another wallet exactly as if it were your own. You can browse all positions and data, but you won't be able to perform any actions or interact with the app. To enable Watch Wallet mode, click on the three dots (…) next to Connect Wallet and toggle on Watch Wallet. Enter the wallet address you wish to watch and click Enable.
*Watch Wallet Mode*
*Enter Wallet Address*
## Troubleshooting
### I cannot connect to the platform
* Make sure to select the correct network (Ethereum Mainnet or Gnosis Chain). Normally on the wallet provider you can switch the network in the settings option.
* On a non-custodial wallet app (e.g. Rabby):
* Make sure to unlock and select Ethereum app.
* Make sure contract data is allowed on the Ethereum app settings.
* On custodial wallet app (e.g. Coinbase):
* Use the scan QR option to connect.
* If you want to access directly from the wallet browser, just go to app.spark.fi.
* Using Wallet Connect:
* Use the scan QR code to connect
### Why is my Wallet Blocked?
Spark receives blockchain intelligence provided by [TRM Labs](https://www.trmlabs.com/). TRM combines on-chain data and real-world investigations to identify financial crime and other prohibited activities. This data blocks wallets from app.spark.fi that are associated with certain legally prohibited conduct.If you believe your address has been incorrectly flagged, please contact [legal@sparkfoundation.ioz](mailto\:legal@sparkfoundation.io).
**What information is shared with TRM Labs?** Your address is shared with TRM, but no metadata is tracked or shared. The request from the UI is routed to the SparkLend hosted API, which is used as a proxy endpoint, and the address is passed directly through to the TRM service. Users' IP addresses are not shared with TRM.
### I cannot send transactions
Make sure you have enough ETH in your wallet to pay the transaction fees. Depending on the network status, the cost of the transactions may vary. At least 0.05 ETH is required to interact properly.
#### Enable contract data on Ledger
If you are using a Ledger hardware wallet, make sure to select the Ethereum app and enable contract data.
To enable contract data:
* Connect and unlock your Ledger device.
* Open the Ethereum application.
* Press the right button to navigate to Settings.
* Then press both buttons to validate.
* In the Contract data settings, press both buttons to allow contract data in transactions.
* The device displays Allowed.
### The site does not load
The following steps may solve your problems:
* If you are using Brave browser, switch to another browser to see if the issues are related to Brave. If it is related to Brave browser some helpful actions are:
* Clearing cache data and cookies for the site
* Hard refresh with control + F5 (or cmd + r)
* Disable brave wallet (or the wallet not being used as default, e.g. metamask) or other extensions that might be interfering with proper connection with the wallet
* If the site still won't load after taking the steps above, you will have to use the platform in another browser.
* Make sure your internet connection is working and stable
* Restart the browser and try to connect again
* Try to hard refresh the site with control + F5
* Check if there are any updates for your browser or wallet provider. If so, update it to the latest version.
### My transaction is stuck pending confirmation
In this situation make sure to not keep sending transactions, as every new transaction will be stuck pending the oldest transaction to be confirmed. You can get rid of the stuck transaction by speeding it up or cancelling it. Depending on the wallet you are using, you may have that option natively.
For example, Metamask or Trust Wallet both have the options to cancel or speed up transactions.
Alternatively, if your wallet provider doesn't have this option, you can still drop the stuck transaction by sending a 0 ETH transaction, to your address (yourself) using the same nonce (number id) as the stuck transaction. You can inspect the nonce in your stuck transaction in [Etherscan](https://etherscan.io) and use interfaces such as [MyCrypto ](https://mycrypto.com/)to send a 0 ETH transaction with a higher gas cost to replace the one that is stuck.
Here is a guide about the topic for [MyCrypto](https://support.mycrypto.com/how-to/sending/checking-or-replacing-a-transaction-after-it-has-been-sent).
:::info
If you still have any questions or issues, feel free to reach out to the Spark team on the official [Discord](https://discord.com/invite/sparkdotfi).
:::
## Swapping Tokens
In this guide, you will learn how to swap between USDS, USDC and DAI. Spark enables easy conversion between these tokens with no slippage and, under current fee parameters, no protocol fee beyond gas.
On Ethereum mainnet, Sky's LitePSM wrapper is the canonical fixed-rate USDC ↔ USDS contract path. Integrators looking to build on that infrastructure can read the [LitePSM developer documentation](/dev/integration-guides/litepsm/).
### How to Swap
1. Navigate to [app.spark.fi](http://app.spark.fi) and go to the Swap page.
*Navigate to the Swap page*
2. Select the tokens and amounts you wish to swap from and to, for example 1000 USDC to 1000 USDS. Click Swap and submit the transactions in the Actions section.
*Input Tokens and Amounts*
3. Once you have finalized all the transactions, you have succesfully swapped your tokens, in this example USDC to USDS.
*Confirmation: USDC Swapped to USDS*
### Converting between Savings Vaults
To swap between Savings Vaults such as sUSDS and sUSDC, you must simply withdraw your assets from the Savings Vaults before swapping to the desired token, and depositing into the desired vault. In many cases you can deposit the stablecoin directly into the desired vault, and the stablecoin will be swapped for the Savings Vault token at no slippage or fee.
### FAQ
#### What is USDS?
USDS is the new version of DAI, issued by [Sky](http://sky.money). USDS is a stablecoin pegged to the US dollar. USDS is not issued or deployed by Spark.
USDS enables users to earn additional rewards, such as a higher APY on Savings USDS, and Sky Star token rewards.
See the [Converting between USDS and DAI](#converting-between-usds-and-dai) section above for how to upgrade to USDS.
## Notification Center
The Notification Center helps you stay informed about changes to your positions and account activity. You can choose your preferred notification channels and the types of alerts you want to receive. More features will be added soon.
### Overview
This guide is divided into four parts:
* Signing in to Notification Center
* Managing your account
* Adding wallets
* Managing wallet notification settings
### Sign In
1. Open the **More** menu in the Spark App and select **Notifications**.
*Open Notification Center from the More menu*
2. The welcome modal is shown the first time you open Notification Center. Click **Enable notifications** to begin signing in. If you close this modal, it will not be shown again, and you can continue later by clicking **Sign in** on the main Notification Center page.
*Welcome modal for Notification Center*
3. Enter your email address and click **Continue**.
*Enter the email address you want to use for notifications*
4. Spark will send a one-time verification code to your email address. Open the email, copy the code, and enter it in the OTP screen.
The sender will use the `notifications.spark.fi` domain.
*Example verification email*
*Enter the one-time code to finish signing in*
5. After signing in, you will see the main Notification Center view with:
* **Account:** Your signed-in email address.
* **Telegram:** An optional channel for receiving alerts in chat.
* **Wallets:** The wallets you want to monitor.
*Notification Center after signing in*
### Manage Your Account
1. To receive alerts in Telegram, click **Connect** in the Telegram panel and follow the Telegram prompt to complete the connection. This step is optional.
*Connect Telegram to receive alerts in chat*
2. To disconnect Telegram, click **Disconnect** in the Telegram panel and confirm.
*Disconnect Telegram if you no longer want Telegram alerts*
3. To sign out, open the three-dot menu in the **Account** panel and click **Sign out**.
*Use the Account menu to sign out or manage the notification account*
4. To permanently remove your Notification Center account and saved settings, open the same menu and choose **Delete notification account**, then confirm the deletion.
*Delete the notification account and its saved settings*
5. At the bottom of Notification Center, you can also use the **Share your feedback** panel to send feedback about the product and your experience using it.
*Use the feedback panel to share product feedback*
### Add Wallets
1. In the **Wallets** section, click **Link more wallets** to add a wallet address you want to monitor.
2. Paste a wallet address or click **Use connected** to use the wallet currently connected to the app. Only wallets with active SparkLend positions are supported.
*Link a wallet address for monitoring*
3. If the wallet does not have an active SparkLend position, Notification Center will show an error and the wallet will not be added. In that case, try another address.
*Only wallets with active SparkLend positions can be linked*
4. You can link more than one wallet. Each wallet has its own settings and can be managed separately.
*Notification Center supports multiple linked wallets*
5. To stop monitoring a wallet, click the trash icon next to that wallet and confirm the removal.
### Manage Wallet Settings
1. Once a wallet is linked, expand it to manage its alert preferences:
* **Health factor alert:** Turn alerts on or off for that wallet.
* **Health factor threshold:** Choose the threshold that should trigger the alert.
* **Email address:** Enable or disable email delivery.
* **Telegram:** Enable or disable Telegram delivery if Telegram is connected.
*Manage per-wallet alert settings and notification channels*
2. Turn on **Health factor alert** for the wallet you want to monitor, then set the threshold that should trigger the alert.
3. Enable the channels you want to use for that wallet. You can use email, Telegram, or both when Telegram is connected.
### Email Examples
When you sign in, Spark sends a one-time verification code by email.
The sender will use the `notifications.spark.fi` domain.
*Verification code email used during sign-in*
When a linked wallet falls below your configured health factor threshold, Spark sends an alert email with a link to review the position.
The sender will also use the `notifications.spark.fi` domain.
*Example health factor alert email*
You can also unsubscribe from email notifications from the link included in notification emails.
*Confirmation screen after unsubscribing from email notifications*
### FAQ
#### Do I need Telegram to use Notification Center?
No. Email notifications work without Telegram. Telegram is optional and can be connected later.
#### Can I monitor more than one wallet?
Yes. You can link multiple wallets, and each wallet can have its own notification settings.
#### Which wallets can be linked?
Only wallets with active SparkLend positions are supported.
#### What triggers a health factor alert?
Alerts are triggered when the wallet's health factor drops below the threshold you configured for that wallet.
#### Can I stop email notifications without deleting my account?
Yes. You can disable the **Email address** channel for a linked wallet, or use the unsubscribe link in a notification email.
### Important
Notification Center emails and related links will come from the `notifications.spark.fi` domain. If you receive a Notification Center email from a different domain, treat it with caution.
## Claiming Rewards
### Tutorial
1. Navigate to the SPK Farm page by clicking on **SPK** in the top navigation bar and selecting **Farm**.
*Navigate to the SPK Farm page*
2. On the SPK Farm page, you can see an overview of how many SPK tokens you have earned, and your deposit.
*Overview of your deposit*
3. To claim SPK rewards, click on the **Claim** button.
4. In the **Claim rewards** dialog, you will see a **Transaction overview**, which shows how many SPK tokens you are claiming. To claim the tokens, you must submit the transactions in the **Actions panel**.
*The Claim rewards dialog*
5. Once you have submitted the transactions, you will see the following confirmation.
*Confirmation for claimed rewards*
## Depositing Into the SPK Farm
### Tutorial
1. Navigate to the SPK Farm page by clicking on **SPK** in the top navigation bar and selecting **Farm**.
*Navigate to the SPK Farm page*
2. On the SPK Farm page, you will see an overview of which tokens can be deposited, and the projected rewards and historical data.
*SPK Farm Overview*
3. To deposit, you can either click on the **Deposit** button in the main panel, or in the **Tokens to deposit** section below, the **Deposit** button for the specific asset you wish to deposit.
*Tokens available for deposit*
*Depositing USDS into the SPK Farm*
4. Submit the transactions in the **Actions panel** to finalize the deposit into the farm.
*Confirmation of deposit into the SPK Farm*
## SPK Farming
Deposit USDS to earn SPK tokens through the SPK Farm. Visit [app.spark.fi/spk/farm](https://app.spark.fi/spk/farm) to start earning SPK.
:::info
Looking for other Sky farms? You can find a link to the external Sky farms page in the Settings menu of the Spark App.
:::
### Learn how to use the SPK Farm
Learn how to deposit, claim rewards, and withdraw using the following tutorials:
* [Depositing Into the SPK Farm](/user-guides/farming-rewards/depositing-into-farms)
* [Claiming Rewards](/user-guides/farming-rewards/claiming-rewards)
* [Withdrawing From the SPK Farm](/user-guides/farming-rewards/withdrawing-from-farms)
### SPK Farming FAQ
#### What is SPK Farming?
You can deposit USDS into the SPK Farm to earn SPK tokens. SPK is the governance token of Spark.
Learn how to deposit here:
* [Depositing Into the SPK Farm](/user-guides/farming-rewards/depositing-into-farms)
#### How much will I earn?
You earn SPK tokens based on the amount of USDS you deposit into the farm. On the farm page you will be able to see how many tokens you are earning in real time, and the APY based on the current token price.
#### When can I claim rewards?
You can claim earned SPK tokens any time you want as they accrue in real time.
Learn how to claim rewards here: [Claiming Rewards](/user-guides/farming-rewards/claiming-rewards)
#### Are there any withdrawal restrictions?
No, deposited funds can always be instantly withdrawn with no liquidity constraint and no fees beyond gas cost. No other actor than the user itself have access to deposited funds.
Learn how to withdraw here: [Withdrawing From the SPK Farm](/user-guides/farming-rewards/withdrawing-from-farms)
#### Can I deposit Savings USDS or Savings DAI?
You can only deposit USDS, however you are able to convert savings tokens to USDS and deposit into the farm in a single transaction. You are therefore not able to both earn the Sky Savings Rate and earn SPK farming rewards at the same time using the same funds.
#### What are the risks?
Funds deposited into the SPK Farm are not used in any liquidity pool or staking mechanism, meaning they can always be instantly withdrawn without liquidity constraints and with no fees beyond gas costs. Only the user has access to the deposited funds, ensuring complete control. As a result, there are no market or staking-related risks associated with the deposited funds.
However, the value of earned SPK tokens may fluctuate based on the market price.
## Withdrawing From the SPK Farm
### Tutorial
1. Navigate to the SPK Farm page by clicking on **SPK** in the top navigation bar and selecting **SPK Farming**.
*Navigate to the SPK Farm page*
2. On the SPK Farm page, you can see an overview of how many SPK tokens you have earned, and your deposit.
*Overview of earned rewards and your deposit*
3. To withdraw your deposit, click on the **Withdraw** button.
*Click Withdraw to withdraw your deposit*
4. Finalize your withdrawal by completing the transactions outlined in the **Actions panel**.
*Withdrawing USDS*
:::info
**Note:** When withdrawing whole deposit, you can also click the toggle to withdraw accrued SPK rewards in the same transaction.
:::
5. Once you have submitted the transactions you will see the following confirmation window.
*Confirmation of withdrawal*
## SPK Staking
SPK staking enables users to stake their SPK tokens to secure Spark and earn staking rewards in return. Spark leverages [Symbiotic’s](http://symbiotic.fi) staking infrastructure for SPK staking. This guide explains how staking works, how to participate, and important details about rewards and withdrawals.
### What is SPK Staking?
SPK staking allows token holders to stake their SPK to secure Spark. In return, stakers earn Spark Points. The staked SPK helps increase the security of the system, by securing Spark token bridges and other future innovations for the protocol.
### How do I stake SPK?
To stake SPK tokens:
1. Navigate to the staking page at [app.spark.fi/spk/staking](https://app.spark.fi/spk/staking) and connect your wallet. Then click "Stake".
*Staking page overview. Click "Stake" to start staking.*
2. Input the amount of SPK you wish to stake, and execute the transactions in the Actions pane.
*Input the amount of SPK you wish to stake, and execute the transactions in the Actions pane.*
3. Once you have executed the transactions, you will get a confirmation.
*Confirmation of the staking transaction.*
4. Rewards will start accruing immediately.
*Overview of points earned.*
### What are the rewards?
* As soon as you stake SPK, you will start earning points. You can see these points in the Spark App UI and on [https://points.spark.fi/](https://points.spark.fi/)
* [You can read more about the Spark Points program here](/points).
### How do I withdraw my stake?
To queue your staked SPK for a withdrawal:
1. On the staking page, click "Unstake" in the main overview.
*Click "Unstake" to queue your staked SPK for a withdrawal.*
2. Specify how much SPK to withdraw and execute the transactions in the UI. Note: There is a minimum withdrawal delay of 2 weeks. The UI will show when the withdrawal can be claimed.
*Unstaking dialog*
3. Once the withdrawal is queued, you can see the withdrawal in the main overview.
*Withdrawal queue overview*
4. Once the withdrawal delay has passed, you can click "Finalize" to withdraw your SPK.
*Finalize withdrawal*
5. Execute the transaction in the UI to finalize the withdrawal.
*Finalize withdrawal*
5. Once you have finalized the withdrawal, you can see the SPK in your wallet.
#### Withdrawal Process
Below is a more detailed explanation of the withdrawal process:
* Once you initiate unstaking SPK, the SPK enters a withdrawal queue.
* There is a minimum withdrawal delay of 2 weeks.
* The delay can extend up to 4 weeks depending on when you withdraw.
* The UI will show you when you are able to withdraw SPK to your wallet.
* Execute the transaction in the UI to withdraw SPK to your wallet.
### How does the withdrawal delay work?
The withdrawal delay is part of the underlying staking infrastructure provided by Symbiotic:
* Withdrawals can only happen after the current epoch and the next one are finished.
* Each epoch is set to two weeks.
* There is always a minimum 2-week withdrawal delay and a maximum of 4 weeks delay depending on when you initiate the withdrawal.
**Example:**
* User withdraws 7 days into epoch 38.
* User cannot withdraw until epoch 39 ends.
* Since each epoch is 14 days long, and the user is 7 days into epoch 38 they can withdraw their stake in 21 days (7 days remaining in epoch 38 + 14 days for epoch 39).
### Will I earn Spark points while my stake is in the withdrawal queue?
Yes, users in the withdrawal queue will earn Spark points.
### Why is there a withdrawal delay?
The withdrawal delay is a security feature that:
* Provides guarantees of a certain stake size for predetermined periods.
* Ensures systems can rely on stake size for a minimum of 2 weeks in the future.
* Prevents potential security issues of large instant withdrawals of stake.
### What is the staked SPK used for?
The staked SPK is used to secure token bridges that are part of the Spark Liquidity Layer. Furthermore, the stake may be used to secure other future products of the Spark Ecosystem.
### Staked SPK token (stSPK)
When you stake SPK, you will receive a staked SPK token (stSPK). This token is a representation of your stake. Keep this token safe as it is required to withdraw your stake.
### Supported Networks and Token Addresses
Below are the only official deployments of staked SPK (stSPK). Beware of scammers and false staked SPK tokens.
| Network | Token | Address |
| -------- | ----- | --------------------------------------------------------------------------------------------------------------------- |
| Ethereum | stSPK | [0xc6132FAF04627c8d05d6E759FAbB331Ef2D8F8fD](https://etherscan.io/address/0xc6132FAF04627c8d05d6E759FAbB331Ef2D8F8fD) |
### What are the risks?
Staking involves the risk of slashing. The specific mechanism for slashing depends on the product that is being secured. Once networks are integrated, more information on the mechanics will be made available.
### Can I vote with my staked SPK?
Yes, users can vote with their full amount of SPK even when their SPK is staked.
### What platform is used for staking?
Spark leverages [Symbiotic](https://symbiotic.fi/) as its staking platform. You can read more about the withdrawal delay and epoch system in their [documentation](https://docs.symbiotic.fi/).
## Spark Savings AVAX Rewards Campaign (Avalanche)
:::info
**The AVAX campaign has ended on March 10, 2026.** AVAX rewards may be activated elsewhere in the future. Follow [@sparkdotfi](https://x.com/sparkdotfi) for updates on future campaigns.
:::
### Overview
The AVAX Rewards Campaign allowed users to earn **AVAX tokens** by supplying **USDC to spUSDC on Spark Savings on Avalanche**.
This program was designed to deepen stablecoin liquidity on Avalanche while maintaining predictable, transparent, and time-based emissions.
**Campaign Start Date:** 10 December 2025
**Campaign End Date:** 10 March 2026 (90 days)
Reference AVAX price used for emission calibration:
**$14.03** (average closing price over the previous 7 days)
### Reward Distribution
Rewards were distributed based on the following key factors:
* **Weekly distributions of approximately 4,434.94 AVAX**
(based on a 7-day average AVAX price of $14.03 and subject to adjustment depending on market conditions and target APY sustainability)
* **Total campaign allocation: 57,020.67 AVAX**
distributed over 90 days
* **Rewards accrued every second**
based on the user's proportional share of total **spUSDC on Avalanche**
* Emissions streamed continuously at approximately **0.00733 AVAX per second**
* Users could claim rewards at any time during the campaign and within the post-campaign claim window
### Campaign Parameters
* **Daily Prize Pool:** 8,889 AVAX (target emission basis)
* **Weekly Emission (USD equivalent):** 62,222
* **Weekly Emission (AVAX):** \~4,434.94 AVAX
* **Total Emission (AVAX):** 57,020.67 AVAX
* **Net AVAX Reserve Buffer:** 9,979.33 AVAX
The reserve buffer was maintained to manage rounding, volatility adjustments, and potential campaign optimization.
### Campaign Details
* **Duration:** 10 December 2025 – 10 March 2026
* **Distribution Network:** Avalanche
* **Reward Token Distribution Network:** Avalanche only
* **Eligible Asset:** spUSDC on Avalanche
Rewards were calculated solely based on spUSDC balances on Avalanche.
There was a single-chain reward calculation and claim process.
### Claim Process
Users can claim their remaining rewards at [https://app.spark.fi/rewards](https://app.spark.fi/rewards). (Make sure to select Avalanche as the network).
Rewards were distributed through the SparkRewards contract deployed on Avalanche.
### Token Information
#### Reward Token
* **Token:** AVAX
* **Network:** Avalanche
#### Eligible Savings Token
* **spUSDC (Avalanche):** [0x28B3a8fb53B741A8Fd78c0fb9A6B2393d896a43d](https://snowscan.xyz/address/0x28B3a8fb53B741A8Fd78c0fb9A6B2393d896a43d)
### Claim Deadlines
* Users must claim their rewards within **3 months after the campaign ends** (by June 10, 2026). Rewards not claimed within this 3-month window will expire and will no longer be claimable.
### Restricted Geographies
No country-level restrictions applied. However, the [Spark Terms of Use](https://spark.fi/terms-of-use) still apply, meaning that e.g. sanctioned users are not able to claim rewards.
### Program Design Principles
This campaign was structured to:
* Drive sustainable USDC liquidity growth on Avalanche
* Maintain predictable and transparent emissions
* Align incentives with long-term protocol health
* Preserve capital efficiency through time-based streaming rewards
The structure balanced attractive participant yield with disciplined token distribution and treasury protection.
## Spark Rewards
### What is the Spark Rewards program?
The Spark Rewards program offers weekly token rewards to users who participate in campaigns rewarding specific actions that contribute to the growth of the Spark ecosystem. The rewards are sourced from and offered in collaboration with other DeFi projects. The goal is to bring different crypto projects together to make decentralized finance more accessible and useful for everyone.
### What are the rewards?
The rewards will mainly be tokens from partners of Spark, this being other DeFi projects or companies that Spark has a partnership with. An example was the [Redstone campaign](/rewards/redstone), which rewarded users who supplied cbBTC into the SparkLend market, which is powered by RedStone oracles.
### How do I earn rewards?
You can start earning rewards immediately by navigating to [app.spark.fi](https://app.spark.fi) and going to the [Rewards](https://app.spark.fi/rewards) page.
*Navigating to the Rewards page*
Here you will see an overview of the active campaigns and rewarded actions, and how to get started. As soon as you are participating in a campaign, you will start to accrue rewards.
*Active campaigns*
### How do I check my rewards?
Your rewards accrue in real time, and you will be able to see accrued rewards in the top panel of Spark App, or on the Rewards page of the app.
*Rewards overview*
### How often are rewards distributed?
While rewards accrue immediately, rewards are only distributed once per week on Mondays. This means you will be able to see how much you have earned in real time, but will not be able to claim until the rewards are distributed each Monday. The application will show an overview of much of the rewards are able to be claimed immediately, and what is pending the next weekly distribution.
### How do I claim the rewards?
You claim the rewards on the Spark App Rewards page. Navigate to [app.spark.fi/rewards](http://app.spark.fi/rewards) and click "Claim All” on the right hand side and follow the instructions to claim your rewards.
*Claiming rewards on the Spark App*
### Do I need to claim each week?
No, you do not have to claim rewards each week. Rewards will continue to accrue and accumulate and you can claim multiple weeks rewards in a single transaction. The application will show an overview of much of the rewards are able to be claimed immediately, and what is pending the next weekly distribution.
### Is there a claim deadline?
Yes, unclaimed rewards will eventually expire depending on the campaign. However there will always be a grace period between when a campaign ends and when the rewards expire of a few months, so users should have ample time to claim their rewards in time. The unclaimed rewards will be used to further reward active users of Spark.
### Restricted geographies
Campaigns might restrict participation of users from specific countries for legal reasons. Check the specific campaign to see the details.
## OP Rewards Campaign
:::info
**The OP campaign has ended.** OP rewards may be activated elsewhere in the future. Follow [@sparkdotfi](https://x.com/sparkdotfi) for updates on future campaigns.
:::
### Overview
The OP rewards campaign allowed users to earn OP tokens by supplying USDC to sUSDC on Spark Savings across both Optimism Mainnet and Unichain. The campaign ran from June 3rd, 2025 at 01:00 UTC until the end of 2025.
### Reward Distribution
Rewards were distributed based on these key factors:
* Weekly distributions of approximately 76,525.69 OP tokens (subject to weekly adjustments based on market APY)
* Total campaign allocation: 2,000,000 OP tokens over 7 months
* Rewards accrued every second based on the user's share of total sUSDC across both chains
* Distributions occurred once per week (Every Monday), starting June 10th, 2025
### Campaign Details
* **Campaign Duration:** June 3rd, 2025 – End of 2025 (Approx 7 months)
* **Distribution Networks:**
* Rewards were distributed on Optimism Mainnet only
* Rewards were calculated based on sUSDC holdings on both Optimism Mainnet and Unichain
* Single claim process for rewards from both chains on OP Mainnet
### Claim Process
* Users can claim their remaining rewards at [https://app.spark.fi/rewards](https://app.spark.fi/rewards). (Make sure to select Optimism Mainnet as the network).
* You can find more information on how to claim rewards [here](/rewards/).
* Claims are processed through the [SparkRewards contract](https://optimistic.etherscan.io/address/0xf94473Bf6EF648638A7b1eEef354fE440721ef41#code) on Optimism Mainnet
* The Merkle root contains combined rewards for both chains
### Token Information
#### Reward Token
* **Token:** OP
* **Contract:** [0x4200000000000000000000000000000000000042](https://optimistic.etherscan.io/token/0x4200000000000000000000000000000000000042)
* **Network:** Optimism Mainnet (distribution only)
#### Involved Tokens
* **sUSDC on Optimism Mainnet:** [0xCF9326e24EBfFBEF22ce1050007A43A3c0B6DB55](https://optimistic.etherscan.io/address/0xCF9326e24EBfFBEF22ce1050007A43A3c0B6DB55)
* **sUSDC on Unichain:** [0x14d9143BEcC348920b68D123687045db49a016C6](https://unichain.blockscout.com/address/0x14d9143BEcC348920b68D123687045db49a016C6)
### Claim Deadlines
* Users must claim their rewards within 3 months from the end of each epoch. Rewards not claimed within the 3-month window expire and cannot be claimed.
* Epochs ran quarterly, with the first epoch starting June 3rd, 2025.
### Restricted Geographies
No country restrictions applied. However the [Spark Terms of Use](https://spark.fi/terms-of-use) still apply, meaning that e.g. sanctioned users are not able to claim rewards.
## Redstone Rewards Campaign
:::info
**The RED campaign has ended on Sept 4, 2025.** RED rewards may be activated elsewhere in the future. Follow [@sparkdotfi](https://x.com/sparkdotfi) for updates on future campaigns.
:::
### Overview
The Redstone rewards campaign allowed users to earn RED tokens by supplying cbBTC on SparkLend (Ethereum Mainnet). The campaign started on April 10 at 15:00 UTC and ended on Sept 4, 2025.
### Reward Distribution
Rewards were distributed based on these key factors:
* Weekly distributions of 200,000 RED tokens.
* Rewards accrued every second based on the user's share of total cbBTC supplied.
* Per second reward share was calculated using this formula:
`User Share = (cbBTC Supplied - cbBTC Borrow Amount / cbBTC Liquidation Threshold) / Total cbBTC Supplies`
* Borrowing cbBTC reduced the reward allocation
* Looping (repeated borrowing and supplying cbBTC) was not rewarded
* Distributions occurred once per week (Every Monday), starting April 21st, 2025.
### Campaign Details
* Campaign duration: April 10 – Sept 4, 2025
* Network: Ethereum Mainnet
* Eligible Asset: cbBTC
### Claim Deadlines
* Users have 3 months from issuance to claim their rewards. Rewards not claimed within 3 months expire and cannot be claimed.
### Restricted Geographies
Users from the following countries were not able to claim rewards:
* USA
## Spark Liquidity Layer
The Spark Liquidity Layer (SLL) operates as a non-custodial capital allocator for Spark across DeFi/CeFi and TradFi opportunities. It has been operating without fault since November 2024. At its core, the SLL is designed to ensure that capital movement is constrained, predictable, and bounded under all conditions, including periods of market stress.
### Risk Architecture
The key security feature of the SLL is that Spark governance must set approved venues in advance, subject to strict rate limits. The automation wallets can only move funds between these pre-approved venues at the defined rate limits.
These constraints ensure that capital cannot be rapidly drained from any single venue, and that allocation changes occur gradually rather than reflexively under stress conditions. This directly addresses a core failure mode observed in recent market events: unconstrained capital movement leading to rapid liquidity depletion and cascading stress across markets.
The threat model assumes a `RELAYER` can be fully compromised. Smart-contract constraints are designed to prevent value from moving outside the ALM system, while rate limits, slippage constraints, and emergency freezing bound the damage such a relayer can cause.
Even under this assumption, capital remains restricted to predefined venues and rate limits, ensuring no single component can introduce unbounded risk to the system.
#### Roles
The SLL uses a small set of governance-controlled operational roles:
* **`RELAYER`** — can call controller functions to move capital between approved venues. These calls remain constrained by approved integrations, balances, slippage checks where applicable, and rate limits.
* **`FREEZER`** — can freeze controller actions in an emergency to stop a compromised `RELAYER`; governance can then reassign or revoke the relayer.
#### Monitoring
The SLL is actively monitored across several independent layers:
* Price movements and collateral valuations across all venues where SLL capital is deployed.
* Oracle deviation and liveness tracking, including heartbeat checks and price-deviation thresholds, to detect stale or manipulated feeds.
* Utilization rate alerts on sudden spikes that may signal abnormal borrowing activity or liquidity stress at integrated venues.
* LTV distribution tracking across active borrower positions in markets where the SLL is allocated, to identify concentration near liquidation thresholds.
* Real-time threat detection through third-party security monitoring, with automated alerts routed to on-call team members for immediate response.
* Sky ecosystem-level oversight on top of Spark-internal monitoring.
Public dashboards: [data.spark.fi](https://data.spark.fi), [info.skyeco.com](https://info.skyeco.com).
#### Liquidity Backstop
The SLL can inject capital into a SparkLend reserve, a Morpho vault curated by Spark, or a Spark Savings vault to support depositor withdrawals while liquidations or redemptions settle through normal channels. This backstop is bounded by approved venues, rate limits, and risk parameters set by governance.
#### Where to Verify
| Item | Source |
| ---------------------------------------- | ----------------------------------------------------------------------------------------------------------------------- |
| All Spark contract addresses (canonical) | [Spark Address Registry](/dev/deployments) |
| SLL addresses in Sky Atlas | [Spark Liquidity Layer Addresses (A.6.1.1.1.2.6.1.2.1.1.1)](https://sky-atlas.io/#f3885398-6641-437b-a413-276ac48e624a) |
| Developer reference | [Spark ALM Controller](/dev/spark-liquidity-layer/spark-alm-controller) |
| Audit reports | [Spark Liquidity Layer Audits](/dev/security/security-and-audits#spark-liquidity-layer) |
| Current configuration | [Sky Forum — Spark Prime](https://forum.skyeco.com/c/spark-prime/) |
| USDS collateral backing composition | [Sky Financial Dashboard](https://financial.skyeco.com/usds/collateral-backing) |
#### Atlas Sources
The following Sky Atlas sections govern the controls described above:
* [A.6.1.1.1.2.6.1](https://sky-atlas.io/#cd70b9f1-1a59-407c-9945-05e52bf5a3b6) — Allocation System Primitive
* [A.6.1.1.1.2.6.1.2.1.1](https://sky-atlas.io/#e9d83462-27f2-4bc0-a63a-596dd7c517b4) — Spark Liquidity Layer Architecture
* [A.6.1.1.1.2.6.1.2.1.1.1](https://sky-atlas.io/#f3885398-6641-437b-a413-276ac48e624a) — Spark Liquidity Layer Addresses
* [A.6.1.1.1.2.2.2](https://sky-atlas.io/#f60887de-a4eb-4e4b-8aa6-e22cf724772a) — Spark Root Edit Primitive
### FAQ
#### What integrations are supported by SLL?
The ALM Controller currently supports the following integration types:
* Aave-compatible lending markets, including SparkLend and Aave
* ERC4626 vaults, including Spark-curated Morpho vaults
* PSM3 contracts on supported L2s
* Mainnet PSM swaps between USDS and USDC
* USDS minting and burning
* USDC transfers through CCTP
* Ethena USDe minting and burning
* Ethena sUSDe cooldown and unstaking
Additional integrations can be onboarded over time through governance-controlled configuration and controller upgrades.
#### What networks are supported by SLL?
The following networks are currently supported by the SLL:
* Ethereum
* Base
* Arbitrum
* Optimism
* Unichain
* Avalanche
Additional networks will be integrated on a continuous basis.
#### What are the liquidity constraints for cross-chain liquidity?
The SLL ensures there is always ample liquidity for users to enter or exit Spark Savings vaults on supported networks. Sky aims to keep a substantial portion of [USDS collateral backing](https://financial.skyeco.com/usds/collateral-backing) in cash reserves, providing a healthy buffer for redemptions even at large volumes.
#### Why is there a 1-of-2 SAFE authorized on the ALM Controller contract?
This SAFE is used as a smart wallet for the SLL automation to enable batching of transactions and rotating of hot wallet keys (the second signer). Funds are not custodied by this wallet, and it is only capable of allocating to governance-approved venues. This is similar to the ALLOCATOR role in the Morpho curation model.
#### Where are whitelists enforced in the ALM Controller contract?
Every allocation function in ALM Controller has an associated call to the RateLimits contract. This request for a rate limit is keyed on the asset argument which provides a whitelist on that parameter. If the asset is not whitelisted then the rate limit will return 0 (not set) and the call will revert.
#### Has the Spark Liquidity Layer been audited?
Yes, you can find the audit reports here: [Spark Liquidity Layer Audit Reports](/dev/security/security-and-audits#spark-liquidity-layer)
#### Who controls the Spark Liquidity Layer?
Sky Governance determines the use cases supported by the SLL, such as networks and protocols, as well as the accepted risk parameters for each use case, including rate limits, maximum fund amounts or maximum volumes.
## Spark Savings
Spark Savings lets users deposit supported assets into savings vaults to earn a risk-adjusted savings rate. Different vaults use different yield sources and have different operators, mechanics, and risk profiles.
Spark currently supports the following Savings Vaults:
| Vault | Token | Asset | Yield Source | Operator | Version |
| --------------------- | ------- | ----- | ---------------------------------------- | -------- | ------- |
| Spark USDC | spUSDC | USDC | Spark Liquidity Layer | Spark | V2 |
| Spark USDT | spUSDT | USDT | Spark Liquidity Layer | Spark | V2 |
| Spark PYUSD | spPYUSD | PYUSD | Spark Liquidity Layer | Spark | V2 |
| Spark ETH | spETH | ETH | Spark Liquidity Layer | Spark | V2 |
| Savings USDS | sUSDS | USDS | Sky Savings Rate | Sky | — |
| Staked USDS | stUSDS | USDS | stUSDS Rate (SKY-collateralized lending) | Sky | — |
| Savings USDC (Legacy) | sUSDC | USDC | Sky Savings Rate | Spark | V1 |
| Savings DAI (Legacy) | sDAI | DAI | DAI Savings Rate | Sky | — |
All Spark Savings vault tokens follow the [ERC-4626 tokenized vault standard](https://eips.ethereum.org/EIPS/eip-4626) — a common interface for yield-bearing vaults where each token represents a share of the underlying assets and accrues yield through an increasing redemption rate. They are transferable, integrable into other DeFi protocols, and continue to accrue yield wherever they are held.
Currently, Savings USDS, Spark USDT, and Spark ETH earn [Spark Points](/points). Other savings vaults do not currently earn Spark Points.
For per-vault contract addresses across all supported networks, see the [Spark Address Registry](/dev/deployments), the [Sky Chainlog](https://chainlog.sky.money/), or the [Spark App](https://app.spark.fi/).
#### Spark Savings USD Vaults
spUSDC, spUSDT, and spPYUSD are V2 vaults fully backed by USDS (see [USDS Collateral Backing](https://financial.skyeco.com/usds/collateral-backing)). Yield is generated via the Spark Liquidity Layer; rates are managed by Spark Governance. For the USDT-specific liquidity management framework, see [USDT Strategy](/products/spark-savings/risk-architecture/usdt-strategy). See also [Risk Architecture](#risk-architecture).
#### Spark Savings ETH Vault
spETH is a V2 vault backed by Spark's balance sheet and insurance. Yield is generated via the Spark Liquidity Layer; rates are managed by Spark Governance. See [Risk Architecture](#risk-architecture).
#### Sky Stablecoin Vaults
sUSDS and stUSDS are Sky products with rates set by Sky Governance. sUSDS provides direct exposure to the Sky Savings Rate. stUSDS lends USDS to borrowers using SKY tokens as collateral and has a different risk profile — see [Staked USDS](#staked-usds).
#### Legacy Vaults
sUSDC (V1) deposits USDC into the Sky Savings Rate; sDAI deposits into the DAI Savings Rate. Users are encouraged to migrate to Spark Savings Vaults V2 for enhanced features, though both remain supported as legacy vaults.
### Guides
Use these guides for Spark Savings workflows:
* [Deposit & Withdraw](/products/spark-savings/guides/tutorial)
* [Savings Liquidity Intents](/products/spark-savings/guides/liquidity-intents)
### Risk Architecture
Spark Savings Vaults V2 (spUSDC, spUSDT, spETH, spPYUSD) generate yield by deploying their underlying assets through the [Spark Liquidity Layer (SLL)](/products/spark-liquidity-layer), which strategically allocates capital across various protocols and yield strategies to optimize returns while maintaining liquidity and managing risk. The Sky vaults (sUSDS, stUSDS) and legacy vaults (sUSDC V1, sDAI) earn from rates set by Sky Governance instead.
You can find an overview of the collateral composition for each vault on the [Savings page in the Spark App](http://app.spark.fi/).
#### Conservative & Secure
Spark Savings V2 vaults allocate conservatively through the SLL:
* Minimizes exposure to riskier collateral (e.g., perpetual futures) to protect against market stress
* Allocates across a mix of DeFi and RWA yield sources to outperform traditional DeFi lending rates
#### Institutional-Grade Liquidity
Spark Savings V2 vaults are designed to support institutional-scale activity:
* Backed by [Sky's balance sheet](https://financial.skyeco.com/financials/balance-sheet) to facilitate 24/7 withdrawals at any individual depositor's size
* Supports large-scale transactions ($100M+) without significant market impact
* Leverages the SLL's deep liquidity across integrated protocols
#### First Loss Capital
USDS (and Spark Savings) has multiple layers of protection for loss events, starting at the Prime level.
**Layer 1 – Internal Junior Risk Capital (Prime-level):** Junior Risk Capital is the first capital to absorb losses on investments under the Allocation System. Each Prime is responsible for holding junior capital in its treasury in proportion to its risk-weighted allocations, which serves as a first line of defense in the event the allocation incurs losses. Spark is well-capitalized, with over $35 million in stablecoin equity capital (see live financials on [data.spark.fi/financials](https://data.spark.fi/financials), and the [Spark Treasury wallet on Etherscan](https://etherscan.io/address/0x3300f198988e4C9C63F75dF86De36421f06af8c4)).
**Layer 2 – Prime-External Junior Risk Capital:** Primes can source additional Junior Risk Capital from other Primes. This risk capital sits at equal preference with the Prime's Internal Junior Risk Capital, helping cover losses related to the Prime's allocation and risk exposures.
**Layer 3 – External Senior Risk Capital (srUSDS):** This feature is planned for deployment in the near future. External Senior Risk Capital is provided from the srUSDS smart contract, which allows users to supply USDS to Sky Core to serve as senior risk capital, beginning to absorb losses only after Junior Risk Capital has experienced 100% losses.
**Layer 4 – The Surplus Buffer (Internal Senior Risk Capital):** The Sky Protocol Buffer — known as the Surplus Buffer — is an accumulation of stability fees and liquidation penalties held by the protocol to cover bad debt in the event of residual losses.
**Layer 5 – Aggregate Surplus Buffer:** After the surplus buffer is exhausted, losses are covered via Sky's Aggregate Surplus Buffer, which allows Sky to encumber the portion of other Primes' Internal Junior Risk Capital that was seeded by Sky to cover critical loss events.
**Layer 6 – Token Backstop:** If losses exceed the sources of risk capital above, Sky will mint SKY tokens to recapitalize the protocol and cover any residual bad debt.
**Equitable Loss Socialization:** If, and only if, all other sources of Junior Risk Capital and token backstops are exhausted, any residual losses are applied equally across all USDS holders, including Spark Savings stablecoin vaults (which are fully backed by USDS).
The Sky ecosystem's multi-layered approach to capital backstops provides high assurance that Spark Savings vault users will not incur losses. Taking the sum of all sources noted above, Spark Savings vaults are covered by several hundred million dollars worth of protection against losses and risk events.
#### Liquidity
Spark Savings vaults maintain industry-leading levels of instantly available liquidity, making them suitable for institutional use cases. The Spark Savings USDT vault maintains an instant liquidity buffer of over 400 million USDT available for redemptions, while the Spark Savings USDC vault has capacity for billions of dollars of redemptions via integration with the Sky PSM.
Savings Vault contracts maintain a liquidity buffer of up to $10 million to serve typical withdrawal volume via atomic redemptions. For larger-scale withdrawals, Spark offers an asynchronous liquidity intents mechanism allowing users to sign a withdrawal request for any amount, with the withdrawal then fulfilled rapidly via the Spark Liquidity Layer; in most cases, large withdrawal requests are filled in less than 1 minute (5 Ethereum blocks).
#### Transparency and Third-Party Ratings
Spark Savings vaults operate with industry-leading transparency into backing assets and related allocation strategies. Real-time data on Spark and Sky backing is available via various open resources, including:
* **Spark Data Dashboard:** [data.spark.fi](https://data.spark.fi)
* **Sky Info Dashboard:** [info.skyeco.com](https://info.skyeco.com)
* **Sky USDS Collateral Backing Dashboard:** [financial.skyeco.com/usds/collateral-backing](https://financial.skyeco.com/usds/collateral-backing)
* **Spark App:** [app.spark.fi](https://app.spark.fi)
Additionally, Spark has [secured ratings](/products/spark-savings/risk-architecture/credora-rating) for Spark Savings products from Credora, an independent, leading crypto-native risk ratings provider.
#### Incident Response
In the event of a potential loss affecting Spark Savings vaults, Spark can put vaults into recovery mode to mitigate risk. Temporarily halting withdrawals ensures that all users receive equal treatment and avoids bank run scenarios.
#### Staked USDS
stUSDS carries increased risk relative to other Spark Savings vaults, including potential liquidity constraints and lack of automatic liquidations.
#### Where to Verify
| Item | Source |
| ---------------------------------------- | ------------------------------------------------------------------------------- |
| Spark Savings vault contracts | [Spark Savings Vaults V2](/dev/savings/spark-vaults-v2) |
| Savings Vault Intents contract | [Savings Vault Intents](/dev/savings/savings-vault-intents) |
| All Spark contract addresses (canonical) | [Spark Address Registry](/dev/deployments) |
| All Sky contract addresses (canonical) | [Sky Chainlog](https://chainlog.sky.money/) |
| Vault collateral composition | [Spark App](https://app.spark.fi/) |
| Spark balance sheet and treasury | [Spark Data Dashboard](https://data.spark.fi) |
| Sky backing and capital dashboards | [Sky Info Dashboard](https://info.skyeco.com/) |
| USDS collateral backing composition | [Sky Financial Dashboard](https://financial.skyeco.com/usds/collateral-backing) |
| Audit reports | [Savings Audits](/dev/security/security-and-audits#savings) |
#### Atlas Sources
The following Sky Atlas sections govern the capital structure and controls described above:
* [A.3.2](https://sky-atlas.io/#55999acf-75fe-4adf-8584-9746ef50d3e4) — Risk Capital
* [A.3.2.1.2](https://sky-atlas.io/#be7589f5-32c0-42d2-8d10-38bceb1de28b) — Total Risk Capital and types of capital
* [A.3.2.1.2.2.1.2](https://sky-atlas.io/#c201122a-75d2-44fa-b221-4e7c09bf42f2) — Junior Risk Capital loss allocation rules
* [A.3.5](https://sky-atlas.io/#3eb6f099-2736-4f62-9cb8-096a8fcca757) — Surplus Buffer and Smart Burn Engine
* [A.3.6](https://sky-atlas.io/#4d8b0d82-97da-4041-b185-4b98c2779cbe) — SKY Backstop
* [A.6.1.1.1](https://sky-atlas.io/#dee2f5a4-279a-488c-9a9d-9583e3216fbf) — Spark (Prime Agent definition)
### FAQ
#### What is the Sky Savings Rate?
The Sky Savings Rate (SSR) is a feature of the Sky Protocol that enables any USDS holder to earn a savings rate on their USDS, paid out in USDS. It is funded by borrowing fees accrued by the Sky Protocol and is set by Sky Governance. Spark has no control over the Sky Savings Rate. The current rate is shown on the [Savings page in the Spark App](http://app.spark.fi/savings).
The Sky Savings Rate powers the sUSDS and sUSDC (V1) vaults. Spark Savings V2 vaults (spUSDC, spUSDT, spETH, spPYUSD) earn yield through the Spark Liquidity Layer instead.
#### How do I deposit into Spark Savings on other networks?
On [app.spark.fi/savings](http://app.spark.fi/savings) you can deposit accepted assets (USDS, USDC, USDT, PYUSD, ETH, etc.) on any supported network to obtain the corresponding Spark Savings vault token. The Spark Liquidity Layer routes liquidity across networks so deposits and withdrawals work on each supported chain.
See [Spark Savings Guides](/products/spark-savings/guides/) for step-by-step workflows.
#### How can I exit my Spark Savings position?
You can swap your vault tokens (sUSDS, sUSDC, spUSDC, spUSDT, spETH, spPYUSD) back into supported stablecoins or ETH on [app.spark.fi/savings](http://app.spark.fi/savings). The Spark Liquidity Layer ensures ample liquidity for redemptions on all supported networks. For larger withdrawals from spUSDC and spUSDT on Ethereum that exceed the idle liquidity buffer, the app submits a Savings Liquidity Intents request that is typically fulfilled within minutes — see [Savings Liquidity Intents](/products/spark-savings/guides/liquidity-intents).
#### What's the difference between Spark Savings Vaults V2, V1, and Sky Savings Vaults?
Spark Savings Vaults V1 only supported USDC, depositing it into the Sky Savings Rate. V2 expands this to any asset — USDC, USDT, PYUSD, ETH, and more — using the Spark Liquidity Layer to deploy assets across optimized yield strategies. All Spark Savings USD vaults (V1 and V2) are [backed by USDS](https://financial.skyeco.com/usds/collateral-backing), giving them the same underlying risk profile regardless of which stablecoin you deposit.
#### Do I need to migrate my funds to Spark Savings Vaults V2?
You can continue using your current vaults.
#### Where does Spark Savings Vaults V2 allocate my deposits?
Spark Savings Vaults V2 deploy your deposits through the Spark Liquidity Layer (SLL), which is designed to generate yield across Spark's entire balance sheet. The SLL strategically allocates assets across various protocols and yield strategies to optimize returns while maintaining liquidity and managing risk. You can see an overview of the collateral composition for each vault on the [Savings page in the Spark App](http://app.spark.fi/).
#### How are vault rates determined and how often do they change?
**Spark Savings Vaults V2 (spUSDC, spUSDT, spETH, spPYUSD):**
* Rates are managed by Spark Governance based on market dynamics and underlying yield strategies
**Spark Savings Vaults V1 (sUSDC) - Legacy:**
* Rates are set by Sky Governance based on Sky Protocol's revenue from crypto-collateralized loans, U.S. treasury bills, and liquidity provisioning
* Changes are made by Sky Governance and updated as needed
**Sky Savings Vaults (sUSDS, sDAI):**
* Rates are set by Sky Governance based on Sky Protocol's revenue from crypto-collateralized loans, U.S. treasury bills, and liquidity provisioning
* Changes are made by Sky Governance and updated as needed
#### How does the Spark Liquidity Layer ensure liquidity?
The Spark Liquidity Layer is designed to always maintain sufficient liquidity for vault deposits and withdrawals. It does this by:
* Keeping a sufficient liquid reserve to cover all expected withdrawals at any given time
* Borrowing from [Sky's balance sheet](https://financial.skyeco.com/financials/balance-sheet) and potentially swapping to shore up liquidity in emergency situations
* Dynamically managing asset allocations across integrated protocols
* Maintaining strategic liquidity reserves
This ensures users can always enter and exit vaults, even for large transactions.
#### Is there slippage on deposits and withdrawals?
When you deposit a token into its native vault, there is **no slippage**. For example:
* Depositing **USDC** into **Spark USDC (spUSDC)** or **Savings USDC (sUSDC)**
* Depositing **USDT** into **Spark USDT (spUSDT)**
* Depositing **USDS** into **Savings USDS (sUSDS)**
* Depositing **ETH** into **Spark ETH (spETH)**
#### Are vault tokens transferable?
Yes, all vault tokens follow the [ERC-4626 tokenized vault standard](https://eips.ethereum.org/EIPS/eip-4626), which extends ERC-20 — so they can be transferred or integrated into other DeFi protocols like any ERC-20 token. Your vault tokens represent your share of the vault and will continue accruing yield wherever they are held.
#### Can I withdraw at any time?
There are no lockup periods for any of the Savings Vaults. Spark Savings Vaults V2 keep an idle liquidity buffer in the vault for instant withdrawals. For larger withdrawals from **Spark Savings USDC** and **Spark Savings USDT** on **Ethereum Mainnet** that exceed the currently available idle liquidity, the app can submit a Savings Liquidity Intents request to the Spark Liquidity Layer, which is usually fulfilled within a few minutes. [Learn more about Savings Liquidity Intents](/products/spark-savings/guides/liquidity-intents).
## SparkLend
SparkLend is Spark's permissionless money market for supplying assets, borrowing against collateral, and managing lending positions. It has always been operated conservatively relative to peers, with a narrow collateral set, multi-oracle pricing, strict rate limits, and first-loss capital.
### Guides
Use these guides for step-by-step SparkLend workflows:
* [Overview of Markets](/products/sparklend/guides/overview-of-markets)
* [Supplying Assets](/products/sparklend/guides/supplying-assets)
* [Borrowing Assets](/products/sparklend/guides/borrowing-assets)
* [Borrow Stablecoins](/products/sparklend/guides/borrow-stablecoins)
* [Adjusting Your Position](/products/sparklend/guides/adjusting-your-position)
* [Repaying Your Loan](/products/sparklend/guides/repaying-your-loan)
* [Liquidations](/products/sparklend/guides/liquidations)
* [E-Mode](/products/sparklend/guides/e-mode)
* [Isolation Mode](/products/sparklend/guides/isolation-mode)
* [Oracles](/products/sparklend/guides/oracles)
### Risk Architecture
SparkLend's risk pillars exist in isolation. They are designed to stack, so that a failure in any single component (oracle, issuer, liquidator, market liquidity) does not cascade into bad debt.
#### Restricted Collateral Set
SparkLend lists a deliberately short set of assets. ETH e-mode is limited to wstETH and rETH. BTC e-mode is being fully removed: the deprecation has been publicly noticed on the Sky forum and is tentatively targeted for the June 4 spell, with forced liquidation of remaining positions on June 8. Exposure in the affected buckets is already small (one material borrower at \~$1.6M plus a handful of smaller positions), and the removal is being done through a publicly telegraphed timeline rather than an immediate parameter flip.
#### Supply and Borrow Caps
Each listed asset has per-market supply and borrow caps configured by Sky Governance. Supply caps bound total exposure to any single asset, mitigating infinite-mint and oracle-manipulation risk on listed collateral. Borrow caps modulate how much of an asset can be drawn out, capping insolvency risk under stress. Caps integrate with the [Cap Automator](/dev/sparklend/features/supply-borrow-caps) so they scale with on-chain market depth rather than waiting on each governance cycle.
#### Minimal Rehypothecation
Collateral supplied to SparkLend reserves stays in the reserve. It is not redeployed into external strategies.
#### Rate Limits
Every cross-module flow into and out of SparkLend is rate-limited at the smart-contract level: deposits, withdrawals, cross-chain bridging, and PSM swaps each have configured rate limits. On top of that, Spark's allocation system enforces per-market debt ceilings and inventory min/max bands. A single depositor or a single adverse event cannot drain the protocol in a single block, and rate limits cap the maximum capital at risk on any single route per unit of time.
#### Three-Oracle Median
Pricing is aggregated using a three-oracle median that pulls data from RedStone, Chainlink, and Chronicle. When all three return valid, non-stale values, the median is used. When two are valid, their average is used. A single-feed fallback also exists. The outcome is that a compromised or faulty single oracle does not drive SparkLend prices.
#### Killswitch Oracle for Pegged Assets
For collateral that trades against a hardcoded or exchange-rate price (wstETH, rETH, weETH, cbBTC, WBTC, LBTC), a peg-ratio oracle continuously compares the asset's market price to its underlying. When the deviation breaches a per-asset threshold, the killswitch halts new borrowing on SparkLend, preventing users from posting distressed collateral at a stale "face value" price and walking out with healthy debt.
#### Programmatic Liquidity Injection
SparkLend's liquidity buffer is not static. The Spark Liquidity Layer automatically moves USDS, USDC, and USDT into and out of SparkLend based on target borrow rates, utilization, and available inventory at other venues. If SparkLend utilization runs high, the SLL tops up idle liquidity to allow withdrawals and liquidations to clear. If a venue elsewhere offers better risk-adjusted yield, idle capital rotates there. This is what it means for Spark to be the largest depositor in its own market: liquidity responds to demand rather than being rationed by utilization alone.
#### USDC via USDS Routing
A periphery integration can offer USDC delivery from a USDS-denominated position by sourcing USDS and swapping it 1:1 through Sky's mainnet LitePSM wrapper. In that pattern, the debt or source asset remains USDS while the wallet receives USDC. Verify the active SparkLend frontend and periphery contracts before relying on this as a specific transaction path. See the [LitePSM developer documentation](/dev/integration-guides/litepsm/) for the underlying Sky contract mechanics.
#### Variable Liquidation Close Factor
If a position's Health Factor drops below 1 but stays above 0.95, up to 50% of the position's debt can be covered in a liquidation call. Below 0.95, up to 100% can be covered. The collateral transferred depends on the debt covered, oracle prices, and the applicable liquidation bonus. See [Liquidations](/products/sparklend/guides/liquidations) for the full mechanics.
#### Granular Borrowing Power Control
The borrowing power of any asset can be reduced down to 0% without impacting existing borrowers. This lets governance phase out a collateral type or tighten exposure on a live market without forced liquidations as the first response. Liquidating existing positions remains available where the situation requires it.
#### Where to Verify
| Item | Address or source |
| -------------------------------- | ------------------------------------------------------------------------------------ |
| Live market parameters | [Spark App](https://app.spark.fi/markets) |
| Supply and borrow caps mechanism | [Supply & Borrow Caps](/dev/sparklend/features/supply-borrow-caps) |
| Oracle configuration | [Oracles](/products/sparklend/guides/oracles) |
| Liquidations | [Liquidations](/products/sparklend/guides/liquidations) |
| Cap Automator audits | [SparkLend Cap Automator](/dev/security/security-and-audits#sparklend-cap-automator) |
| SparkLend audits | [SparkLend Audits](/dev/security/security-and-audits#sparklend) |
| Core contract addresses | [Spark Address Registry](/dev/deployments) |
| Source code | [Spark GitHub](https://github.com/sparkdotfi) |
#### Atlas Sources
The following Sky Atlas sections govern the controls described above:
**SparkLend specific:**
* [A.6.1.1.1.3.2.1](https://sky-atlas.io/#d9ff0cd2-8999-4d3d-9670-2c7b49c1fe51) — SparkLend (parameters and operational processes)
* [A.6.1.1.1.3.2.1.1.1](https://sky-atlas.io/#667abf8c-64a3-4029-b218-e7a6e7000bbd) — SparkLend Risk Parameters Definitions (LTV, Liquidation Threshold, Liquidation Bonus, Reserve Factor, Supply Cap, Borrow Cap, Interest Rate Model, Reserve State, E-Mode, Isolation Mode, Siloed Borrowing, Flash Loans)
* [A.6.1.1.1.3.2.1.1.2](https://sky-atlas.io/#cb959917-c29c-4d2f-b151-ded03618357c) — SparkLend Risk Parameters Current Configuration (per-asset values)
* [A.6.1.1.1.3.2.1.1.3](https://sky-atlas.io/#6ffdb8ee-b083-40f5-b51b-1c91e954b68b) — SparkLend Cap Automators
* [A.6.1.1.1.2.6.1.1.2.1.1](https://sky-atlas.io/#c4a1d0ca-0794-4ad0-9920-7f8a837b6bfa) — SparkLend Mainnet Instances Directory
* [A.6.1.1.1.2.6.1.3.1.1](https://sky-atlas.io/#1fdebcff-990a-40ac-8db6-8ef993edd57a) — SparkLend Instance Configuration Documents
**Cross-cutting:**
* [A.6.1.1.1](https://sky-atlas.io/#dee2f5a4-279a-488c-9a9d-9583e3216fbf) — Spark (Prime Agent definition)
* [A.6.1.1.1.2.6.1](https://sky-atlas.io/#cd70b9f1-1a59-407c-9945-05e52bf5a3b6) — Allocation System Primitive
* [A.6.1.1.1.2.2.2](https://sky-atlas.io/#f60887de-a4eb-4e4b-8aa6-e22cf724772a) — Spark Root Edit Primitive
* [A.3.3](https://sky-atlas.io/#6478afd5-7c3f-4bed-a2b7-9f8ee402bb64) — Asset Liability Management
### FAQ
For step-by-step questions on supplying, borrowing, repaying, and liquidations, see the [SparkLend Guides](/products/sparklend/guides/) — in particular the [Supplying Assets FAQ](/products/sparklend/guides/supplying-assets#faq) and [Borrowing Assets FAQ](/products/sparklend/guides/borrowing-assets#faq).
#### On which networks is SparkLend supported?
SparkLend is currently supported on Ethereum and Gnosis Chain.
#### What is the cost of interacting with SparkLend?
Interacting with the protocol requires onchain transactions, so users pay the standard transaction fees of the network they are on. Fees depend on network conditions and transaction complexity.
#### What is the difference between transparent and variable rate?
Transparent rates act as a fixed rate in the short-term, but can change based on Sky Governance. The variable rate is set by supply and demand within SparkLend and changes continuously.
#### What is the health factor?
The health factor is the ratio between your collateralization ratio (the value of your collateral vs the value of your debt) and the liquidation loan-to-value. A higher health factor means your position is further from liquidation. If the health factor falls below 1, the position becomes liquidatable. See [Liquidations](/products/sparklend/guides/liquidations) for how to manage and avoid this.
## Adjusting Your Position
### Tutorial
Having an active borrow position on Spark requires ongoing monitoring and management. These steps will guide you through how to effectively manage your position and to avoid liquidation.
1. To monitor your Spark position, navigate to the **My portfolio** page.
*The Dashboard*
2. The section **Your position** will show:
* The value of the supplied collateral in USD
* The value of the borrowed funds in USD. This accrues over time based on the borrow rate.
* The maximum that can be borrowed, before violating the Loan-To-Value requirements.
**Note:** If you do not have an active position, it will show an empty position, and a button below to create one using the **Easy Borrow Flow**.
*Your Position: Shows collateral value, loan value, and the max borrow amount*
3. The **Dashboard** also displays the current Health Factor of the borrow position.
* The **Health Factor** is a measure of how close the position is to liquidation based on the current LTV. A Health Factor **below 1** means the position can be liquidated. Users are therefore responsible for keeping a Health Factor above 1, in order to avoid liquidation. The LTV of the position can change over time if the underlying collateral changes in value, and as debt accrues due to interest rates.
* **Current Price** shows the current market price of the collateral asset.
* If the price of the collateral asset reaches the **Liquidation Price**, the position can be liquidated.
**Note:** If you are using more than one collateral type, the current price and liquidation price information is not displayed.
*The Health Factor for your Spark position*
4. On the **My portfolio page** you have the necessary functionality to adjust your position.
* In the **Supply** section you can supply and withdraw assets. [See the steps here](/products/sparklend/guides/supplying-assets).
*Supply Section*
* In the **Supply** section you can also enable or disable assets as collateral. Learn about this here.
* In the **Borrow** section you can borrow or repay assets. [See the steps here](/products/sparklend/guides/borrowing-assets).
*Borrow Section*
For example, if your position is close to liquidation you can either repay some or all of your loan, or supply more collateral. See the [supply assets](/products/sparklend/guides/supplying-assets) and [borrow asset](/products/sparklend/guides/borrowing-assets) sections for the step by step guide.
5. If your position is liquidated, your position will be updated accordingly and automatically. Depending on the exact situation for the liquidation you might still have an open borrow position. [You can read more about liquidations here](/products/sparklend/guides/liquidations).
### FAQ
Find relevant FAQs here:
* [**Supplying Assets FAQ**](/products/sparklend/guides/supplying-assets#faq)
* [**Borrowing Assets FAQ**](/products/sparklend/guides/borrowing-assets#faq)
## Borrow Stablecoins
### Tutorial
On the **Borrow Stablecoins** page, you can borrow stablecoins, by supplying crypto assets as collateral. If you wish to borrow other assets than stablecoins, navigate to the **My portfolio** page and follow the [supply assets](/products/sparklend/guides/supplying-assets) and [borrowing assets](/products/sparklend/guides/borrowing-assets) steps instead.
1. Navigate to the **Borrow Stablecoins** page.
*Navigating to Borrow DAI and USDS*
*The Borrow Stablecoins page*
2. Under **Supply** you can select the crypto asset in the dropdown menu you wish to supply as collateral for the loan.
*Easy Borrow Flow*
3. In the input bar on the left you specify the amount of collateral you wish to supply, denominated in the asset. The dollar value is displayed below.
4. On the right under Borrow, using the dropdown menu you can specify the asset you wish to borrow.
*Selection of which asset to borrow.*
5. Click on **Add more +** to add more crypto assets to be used as collateral. This will generate an additional supply bar, where you can select the asset and amount.
*Supplying multiple collateral assets*
6. On the right side under **Borrow**, you specify the stablecoin amount you wish to borrow.
7. Below you are able to see the simulated state of the borrow position based on the current price of the collateral assets and the borrow amount. It displays:
* **Loan to Value (LTV):** The percentage value of the borrow amount in USD in respect to the collateral amount in USD.
* **The LTV slider:** Shows the current LTV percentage and its associated risk level ranging from Conservative to Moderate to Aggressive. You can drag the slider to adjust the borrow amount to specify an LTV percentage, which will adjust the Dai borrow amount above accordingly.
* **Liquidation Indicator**: The LTV slider also shows the LTV at which the position can be liquidated. The different collateral assets have a different liquidation LTV. Creating a position with multiple collateral assets will use an aggregate liquidation LTV based on the amount of each collateral.
* **Max LTV:** The maximum allowed percentage value of the borrow amount in USD in respect to the collateral amount in USD.
* **Borrow rate:** The annual percentage rate (APR) for borrowing. For USDS and DAI, this rate is set by Sky Governance.
:::warning
**Note:** Crypto assets are volatile so even conservative borrow positions should be monitored on an ongoing basis to prevent unwanted liquidations. [You can read more about liquidations here.](/products/sparklend/guides/liquidations)
:::
8. Once the parameters for the borrow position has been set, you click **Borrow**.
9. This will showcase the *Health Factor*, the *Liquidation Price* and the current *Collateral Pricing* for the position.
*The Health Factor Overview*
* The **Health Factor** is a measure of how close the position is to liquidation based on the current LTV. A Health Factor **below 1** means the position can be liquidated. Users are responsible for keeping a Health Factor above 1, in order to avoid liquidation. The LTV of the position can change over time if the underlying collateral changes in value, and as debt accrues due to interest rates.
* **Current Price** shows the current market price of the collateral asset provided by the price oracle.
* If the price of the collateral asset reaches the **Liquidation Price**, the position can be liquidated.
:::info
**Note:** If you are using more than one collateral type, the current price and liquidation price information is not displayed.
:::
10. The **Actions** section below shows the transactions necessary to create the borrow position. You must click the buttons to sign each transactions with the connected wallet.
*Actions Window*
* **Token Permit/Approval:** You must approve the supply of the collateral token.
* **Supply:** You supply the collateral tokens into the borrow position.
* **Borrow:** You borrow the specified amount of assets.
11. Once every step is done, you will have received the borrowed Dai in your wallet, and a confirmation and overview of the actions. You can click on **View in dashboard** to view your new position.
*Confirmation Window*
### FAQ
You can find frequently asked questions relating to supplied collateral and borrowing here:
* [**Supplying Assets FAQ**](/products/sparklend/guides/supplying-assets#faq)
* [**Borrowing Assets FAQ**](/products/sparklend/guides/borrowing-assets#faq)
## Borrowing Assets
### Tutorial
In order to borrow assets, you must first supply assets as collateral. [Click here](/products/sparklend/guides/supplying-assets) for a step by step supply guide.
If you wish to borrow stablecoins in simple manner you can use the [**Borrow Stablecoins**](/products/sparklend/guides/borrow-stablecoins) page.
1. To borrow assets navigate to the **My portfolio** page and scroll down to the **Borrow** section.
*Borrow Section*
2. The **Borrow** section shows the following information:
* The assets that can be borrowed
* The available liquidity that can be borrowed
* Your current borrow amount
* The current borrow interest rate for the specific asset
3. If you are borrowing an asset that is correlated with the supplied collateral type, you can change the **E-Mode** to increase the borrow amount.
This is available between ETH correlated assets (ETH, wstETH, rETH) and stablecoin correlated assets (DAI, USDC, USDT), and allows for increased leverage. For example, you can enable E-mode if you are borrowing ETH using wstETH as collateral. If you are borrowing assets not supported in E-mode, you cannot enable E-mode. For example, if you have already borrowed Dai against ETH, you cannot enable E-mode until this loan has been repaid. [You can read more about E-mode here.](/products/sparklend/guides/e-mode)
*E-mode Categories*
4. You can borrow an asset by navigating to the asset row, and clicking **Borrow**.
5. In the **Borrow window** you specify the amount you wish to borrow. In the **Transaction overview** it will display the Health Factor of the borrow position. The **Actions** section will guide you through the steps to create the borrow position.
*Borrow Window: WETH*
6. Once you have done all the necessary transactions, you will receive the borrowed assets. Your overall position will be updated, which is reflected in the **Health Factor** and overview in **Your position**.
*Confirmation: Borrowing WETH*
7. If you wish to borrow more at a later stage, you simply repeat this process.
### FAQ
#### Why would I borrow instead of selling my assets?
By borrowing you are able to obtain liquidity without selling your assets. Users are mainly borrowing to leverage their holdings or for new investment opportunities.
#### How much I can borrow?
The maximum amount you can borrow depends on the value of the collateral you have supplied and the available liquidity. For example, you cannot borrow an asset if there is not enough liquidity or if your health factor does not allow you to.
#### What asset do I need to repay?
You repay your loan in the same asset you borrowed. For example, if you borrow 1000 DAI you will pay back 1000 DAI + interest accrued.
#### What is the difference between transparent and variable rate?
Transparent rates act as a fixed rate in the short-term, but will change based on Sky Governance. The variable rate is the rate based on the supply and demand in SparkLend, and will constantly change.
#### How much will I pay in interest?
The interest rate you pay for borrowing assets depends on the borrowing rate which is derived from the supply and demand ratio of the asset in the case of the variable rate. The interest rate of a variable rate changes constantly. You can find your current borrowing rate at any time in the Borrow section of your Dashboard.
#### What is the health factor?
The health factor is the ratio of your collateralization ratio (the value of your collateral vs the value of your debt) and the liquidation loan to value. The higher Health Factor value is, the safer the state of your funds are against a liquidation scenario. If the health factor goes below 1, a liquidation of your supplied collateral will be triggered.
#### What happens when my health factor is reduced?
Depending on the value fluctuation of your supplied collateral, the health factor will increase or decrease. If your health factor increases, it will improve your borrow position by making the liquidation threshold more unlikely to be reached. In the case that the value of your collateral assets against the borrowed assets decreases, the health factor is reduced, causing the risk of liquidation to increase.
#### When do I need to pay back the loan?
There is no fixed time period to pay back the loan. As long as your position is safe, you can borrow for an undefined period. However, as time passes, the accrued interest will grow making your health factor decrease, which might result in your supplied assets becoming more likely to be liquidated.
#### How do I payback the loan?
In order to payback the loan you simply go to the Borrowings section of your dashboard and click on the repay button for the asset you borrowed and want to repay. Select the amount to pay back and confirm the transaction.
#### How do I avoid liquidation?
In order to avoid the reduction of your health factor leading to liquidation, you can repay the loan or supply more collateral assets in order to increase your health factor. Learn more about liquidations here:
* [Liquidations](/products/sparklend/guides/liquidations)
#### How can I use permit?
The permit function of SparkLend allows you to move your funds from a wallet by simply signing an approval message instead of approving a transaction on the network to avoid gas fees.
## E-Mode
#### High Efficiency Mode (E-mode)
The E-mode feature maximizes capital efficiency when collateral and borrowed assets have correlated prices. For example, sDAI, USDC, USDT are all stablecoins pegged to USD. These stablecoins are all within the same E-mode category. Accordingly, a user supplying sDAI in E-mode will have higher collateralization power when borrowing assets like USDC or USDT.
Only assets of the same category (for example stablecoins) can be borrowed in E-mode.
E-mode does not restrict the usage of other assets as collateral. Assets outside of the E-mode category can still be supplied as collateral with normal LTV and liquidation parameters.
#### How do I enter E-mode?
To enter E-mode from the go to **My portfolio** and find the **Borrow** section. Here you will find an **E-Mode Toggle**, which you can click.
You can then select which E-mode category you wish to choose.
*Selection of E-Mode Category*
You then submit the transactions in the **Actions** section to enable E-Mode.
#### How do I exit E-mode?
To exit E-mode, go to the **My portfolio** page and navigate to the **Borrow** section. Click on the E-Mode toggle and select No E-mode in the popup window. Carry out the transactions in the **Actions** section to exit E-mode.
#### How does E-mode affect my borrowing power?
When E-mode is enabled, you will have higher borrowing power over assets of the same E-mode category.
## Feature Overview
This page summarises the core SparkLend features that determine how users supply, borrow, and manage positions on the protocol. For step-by-step workflows, follow the links into the relevant guides.
### Lending and Borrowing
On SparkLend, users supply assets to liquidity markets where they can be borrowed by other users. Suppliers earn interest on supplied assets, and can use those assets as collateral to borrow other assets. Borrowers pay interest to lenders based on the supply and demand of the borrowed asset.
For step-by-step workflows, see:
* [Supplying Assets](/products/sparklend/guides/supplying-assets)
* [Borrowing Assets](/products/sparklend/guides/borrowing-assets)
### Efficiency Mode (E-Mode)
E-Mode allows borrowers to extract higher borrowing power from their collateral when supplied and borrowed assets are correlated in price — typically derivatives of the same underlying asset (e.g. ETH-correlated assets, or USD-pegged stablecoins).
See [E-Mode](/products/sparklend/guides/e-mode) for how to enter and exit E-Mode.
### Isolation Mode
New assets can be listed as *isolated*. Borrowers supplying an isolated asset as collateral cannot use other assets as collateral at the same time (other supplied assets can still earn yield). Positions in isolation mode can only borrow up to a per-asset debt ceiling.
See [Isolation Mode](/products/sparklend/guides/isolation-mode) for the user flow.
### Siloed Borrowing
Siloed borrowing allows assets with potentially manipulatable oracles to be listed on SparkLend as a single borrow asset: if a user borrows a siloed asset, they cannot borrow any other asset at the same time. This contains the risk associated with such assets so it cannot impact the overall solvency of the protocol.
## SparkLend Guides
Use these guides to supply assets, borrow against collateral, manage your position, and understand SparkLend market features. For the product overview, risk architecture, and verification sources, start with [SparkLend](/products/sparklend).
If you are new to SparkLend, start with the [Feature Overview](/products/sparklend/guides/feature-overview) for a concept-level introduction to lending, E-Mode, isolation mode, and siloed borrowing.
### Core Workflows
* [Overview of Markets](/products/sparklend/guides/overview-of-markets)
* [Supplying Assets](/products/sparklend/guides/supplying-assets)
* [Borrowing Assets](/products/sparklend/guides/borrowing-assets)
* [Borrow Stablecoins](/products/sparklend/guides/borrow-stablecoins)
* [Adjusting Your Position](/products/sparklend/guides/adjusting-your-position)
* [Repaying Your Loan](/products/sparklend/guides/repaying-your-loan)
* [Liquidations](/products/sparklend/guides/liquidations)
### Market Features
* [E-Mode](/products/sparklend/guides/e-mode)
* [Isolation Mode](/products/sparklend/guides/isolation-mode)
* [Oracles](/products/sparklend/guides/oracles)
## Isolation Mode
Isolation mode allows Sky Governance to list new assets as isolated assets, which have a specific debt ceiling and can only be used as the sole collateral for a position. Wrapped Ether.fi ETH (weETH) is an example of an isolated asset in SparkLend.
The debt ceiling for an isolated asset is represented as the maximum amount in USD that can be borrowed against the user’s collateral.
#### How can I enter isolation mode?
The steps to entering isolation mode are as follows:
1. From the My portfolio page select an isolated asset to supply.
2. You will then see an information notification explaining that you are entering into isolation mode.
3. Once you have successfully entered isolation mode, you will then be able to supply an isolated asset.
4. You can also borrow assets once in isolation mode; however, you will only be able to borrow stablecoins up to a certain debt ceiling.
#### How can I exit isolation mode?
To exit isolation mode, you will need to disable the collateralized isolated asset that you have supplied.
1. On the **My portfolio** page in the **Supply** section, click the **Collateral** toggle to disable the isolated asset.
2. Confirm the disabled isolation mode setting. You have now successfully exited isolation mode.
## Liquidations
### What is a liquidation?
A liquidation is a process that occurs when a borrower's [Health Factor](/products/sparklend/guides/borrowing-assets#what-is-the-health-factor) (HF) goes below 1 due to their collateral value not properly covering their loan/debt value. This might happen when the collateral decreases in value or the borrowed debt increases in value. In a liquidation up to 100 % (depending on your HF - [see below](#variable-liquidation-close-factor)) of a borrower's debt is covered by seizing the collateral and selling it to repay the debt.
#### Variable Liquidation Close Factor
The variable liquidation close factor is based on the Health Factor (HF) and allows for partial or full liquidation of the borrow position. If the HF is `< 1` but `> 0.95`, 50% of the position collateral can be liquidated. If the HF is `< 0.95`, 100% of the collateral can be liquidated.
### How much is the liquidation penalty?
The liquidation penalty (or bonus for liquidators) depends on the asset used as collateral. The liquidation penalty for each individual asset can be found on the [Markets page](/products/sparklend/guides/overview-of-markets).
### How can I avoid getting liquidated?
It's important to monitor your health factor to avoid a liquidation. Keeping your health factor over 2, for example, gives you more of a margin to avoid a liquidation.
To avoid liquidation you can raise your health factor by supplying more collateral assets or repaying part of your loan.
### Can I participate in the liquidations ecosystem?
Yes, liquidations are open to anyone. Liquidators develop solutions and bots to be the first ones liquidating loans to get the liquidation bonus. You can find more details in the [developers liquidation section](/dev/sparklend/features/liquidations).
## Oracles
SparkLend uses oracle price feeds to power its lending markets. Depending on the asset, different types of oracles are used, to ensure the proper pricing and risk management. The oracle price feeds are used to calculate the value of user collateral, and consequently how much a user can borrow, and when the system must liquidate risky positions.
### Oracle Providers
SparkLend uses [Chronicle](https://chroniclelabs.org/), [Chainlink](https://chain.link/) and [RedStone](https://www.redstone.finance/) as oracle providers for the lending markets. You can see which Oracle is used for the specific market on the [Markets page](#where-can-i-check-what-oracle-is-being-used).
### Where can I check what Oracle is being used?
On the [Spark App](https://app.spark.fi), in the “Borrow” dropdown menu in the top navigation bar, you can select “Markets”. From there, you click “Details” on the specific asset you wish to inspect, and scroll down to **Oracle type** section at the bottom. Here you will see the Oracle type, the current price, and the contract address for the Oracle smart contract.
### Who selects the Oracles?
[Sky](https://sky.money) Governance controls which oracles are used by the SparkLend markets.
### Types of Oracles
SparkLend uses different types of oracle price feeds depending on the asset and the lending market.
#### Market Price
A Market Price oracle reflects the live market value of the asset. This means the price the asset is currently being traded at on various exchanges. An example is ETH which uses a Market Price oracle.
*Market Price Oracle for ETH*
#### Fixed Price
With a Fixed Price oracle, the asset price is set by a contract at a predefined value, adjustable only through Sky governance decisions. For example, stablecoins such as DAI uses a fixed price of 1.00 USD, and does not deviate even if the market price of DAI deviates from this value.
*Fixed Price Oracle for Dai*
#### Underlying Asset Price
For an Underlying Asset Price oracle, the asset price is derived from a market price oracle tracking the value of the *underlying asset*, and not the asset itself. For example, a derivative asset such as cbBTC, uses a market price feed for its underlying asset BTC, and not a market price for cbBTC.
*Underlying Asset Price for cbBTC*
#### Yielding Fixed
For a Yielding Fixed oracle, the asset price is calculated using both an exchange rate and a market price oracle. The exchange rate is a conversion rate of the asset and its underlying asset. An example is yielding assets such as wstETH (Wrapped Staked ETH), which uses the exchange rate between wstETH and its underlying asset WETH (Wrapped ETH), multiplied by the market price of the underlying asset WETH.
*Yielding Fixed Oracle for wstETH*
### Redundant Oracle Feeds
For certain assets SparkLend uses oracle price feeds from both Chronicle, Chainlink and RedStone, ensuring that in the unlikely event one price feed should fail, a redundant price feed will automatically be used. Finally, in the extremely unlikely event that price feeds from Chronicle, Chainlink and RedStone should fail at the same time, a Uniswap TWAP (time-weighted average price), is used as a fallback price feed. This ensures maximum protection for SparkLend users. You can see an example of this mechanism above in the Yielding Fixed Oracle used for wstETH. \
You can check if an asset uses redundant price feeds, by checking if it says "Redundant" in its Oracle type, on the specific Market page. [See here where to check the oracle type.](#where-can-i-check-what-oracle-is-being-used)
## Overview of Markets
The **Markets** page displays an overview of the state of the protocol and the supported assets. The displayed data is specific to the selected network, so if you wish to browse another network, use the network toggle in the top right hand corner.
*Navigate to Markets Page*
The Markets page displays:
* The total market size
* Total value locked (TVL)
* Total borrows
*The Markets Page*
In the section below it displays the following data for each supported asset:
* Total amount supplied
* Supply APY
* Total amount borrowed
* Borrow APY
* Status, which indicates certain risk modes for the assets:
* Can it be supplied or not
* Can it be used as collateral or not
* Can it be borrowed or not, or is it in isolation mode ([read more here](/products/sparklend/guides/isolation-mode)).
*Market Status: Specific for each asset*
For each asset you can click on the details button to get a more in-depth overview of the metrics for the asset, and its parameters, such as liquidation threshold and penalty, and whether the asset can be used in E-mode. The page also displays which oracle is being used for this asset ([you can read more about this here](/products/sparklend/guides/oracles)). It also displays a more in-depth overview of the interest rate model for the asset. You are also able to supply or borrow the asset directly from this page, using the sidebar on the right.
*Detailed Asset Overview*
## Repaying Your Loan
### Tutorial
1. To repay your loan, navigate to the **My portfolio** page and find the **Borrow** section. Assets that you have borrowed will show up in the **Your borrow** column.
*Borrow Section: Click on repay on the right to initiate repayment of loan*
2. To repay your loan, click on the **Repay** button for the specific asset.
3. In the **Repay window**, you specify the amount of borrowed assets you wish to repay. You can choose to fully or partially repay your loan. To fully repay the loan, click on **MAX** in the input bar.
*Repay USDS Loan*
4. Based on the specified amount, the transaction overview will display the remaining debt, and the health factor of the position.
5. The **Actions** section will guide you through the necessary transactions to repay the loan.
6. Once you have done all the necessary transactions, the specified amount of assets will be transferred from your wallet and be repaid to the pool. Your overall position will be updated, which is reflected in the **Health Factor** and overview in **Your position**.
*Sucessful repayment*
### FAQ
You can find more information here:
* [**Supplying Assets FAQ**](/products/sparklend/guides/supplying-assets#faq)
* [**Borrowing Assets FAQ**](/products/sparklend/guides/borrowing-assets#faq)
## Supplying Assets
### Tutorial
In order to borrow assets, you must first supply assets as collateral such as ETH or cbBTC. Supplied assets can be borrowed by other users and therefore earn interest. You can also simply supply assets without borrowing, to earn interest.
1. To supply assets to SparkLend, navigate to the **My portfolio** page.
*Navigate to My portfolio*
*My Portfolio Page*
2. Scroll down to the **Supply** section which shows the following information:
* **Assets:** The different assets that can be supplied to SparkLend
* **In Wallet:** Amount of the specific asset in your wallet, and its value in USD.
* **Supply**: Amount of the asset you have supplied to SparkLend.
* **APY:** The current annual percentage yield. Supplied assets can be borrowed by other users, and therefore earn yield.
*Supply Section*
3. You supply assets by clicking on the Supply button for the corresponding asset, which will open the **Supply window**.
4. The **Supply window** will display:
* **Amount:** Here you specify the amount of the specific asset you wish to supply.
* **Transaction overview:** Shows the supply APY for the asset and whether the asset is enabled as collateral.
* **Actions**: An overview of the necessary transactions you must do to create the supply position.
*Supply Dialog*
5. Once you supply assets, the position will be updated, which is reflected in the Health Factor and overview in **Your position**.
*Your Position Overview*
6. You receive spTokens in return which reflect your supply position in Spark. You need these tokens to withdraw your assets from the protocol, so keep them in your wallet.
7. If you wish to supply more assets, for example to increase the *Health Factor* of your borrow position, you simply repeat this process.
8. You can use the **Collateral toggle** to enable or disable an asset as collateral for your borrow position. Disabling an already supplied asset as collateral will impact the Health Factor of your position, as the asset will no longer count towards the collateral value and loan to value.
*Collateral Toggle: The toggle is green when the asset is enabled as collateral*
*Disabling an asset at collateral*
### FAQ
#### Is there a minimum or maximum supply amount?
You can supply any amount you want, there is no minimum or maximum limit. However, it's important to note that for low amounts it is possible that the transaction cost of the process is higher than the expected earnings. It is recommended that you consider this when supplying low amounts.
#### Where are my supplied funds stored?
Funds are supplied to a non-custodial smart contract. The code of the smart contract is public, open source, formally verified and audited by third party auditors. No centralized entity can access supplied funds.
#### How much will I earn?
Suppliers receive continuous yield that fluctuates due to market conditions based on:
* **The interest rate payment on loans:** Suppliers share the interests paid by borrowers. The higher the utilization of a reserve the higher the yield for suppliers.
Each asset has its own market of supply and demand with its own APY (Annual Percentage Yield) which fluctuates over time. You can find the average annual rate over the past 30 days to evaluate the rate evolution, and you can also find more data on the reserve overview of each asset in the home section on the app.
#### Can I opt-out my asset from being used as a collateral?
Yes. After supplying your assets, you are able to unselect the asset so that it will not be used as collateral. The opt-out is available in the **Supply** section within your dashboard. Simply switch the **Collateral** toggle on the asset you would prefer to opt-out from being used as a collateral.
You can withdraw your assets without opting out of using them as collateral, as long as those funds are not actively being lent out or the withdrawal would cause a liquidation on your loans.
[^1]: The **Health Factor** is a measure of how close the position is to liquidation based on the current LTV. A Health Factor **below 1** means the position can be liquidated. Users are therefore responsible for keeping a Health Factor above 1, in order to avoid liquidation. The LTV of the position can change over time if the underlying collateral changes in value, and as debt accrues due to interest rates.
## Credora Risk Assessment
Spark Savings vaults are subject to independent risk assessments by **Credora**, a DeFi risk analytics provider.
Credora assigns a model-driven credit assessment to each Savings vault based on the **Probability of Significant Loss (PSL)**, which estimates the likelihood of a material loss of principal under stressed conditions.
Ratings incorporate:
* Collateral composition
* Liquidity conditions
* Smart contract maturity
* Governance structure
**Current assessments (Credora update as of 23 Feb 2026):**
| Vault | Underlying Exposure | PSL | Rating |
| ------ | -------------------------------- | ----- | ------ |
| ETH | SparkLend ETH lending market | 0.25% | A |
| PYUSD | USDS collateral backing | 0.62% | A |
| USDC | USDS collateral backing | 0.76% | A- |
| USDT | USDS collateral backing | 0.76% | A- |
| USDS | USDS collateral backing | 0.79% | A- |
| stUSDS | SKY/USDS isolated lending market | 1.03% | B+ |
Ratings are model-driven and update when material changes occur in underlying exposures.
***
## Scope and Limitations
* Ratings measure incremental credit risk of the vault structure.
* Ratings exclude market price volatility of the deposited asset unless explicitly stated.
* Ratings are based on publicly observable on-chain data, third-party analytics, and Credora’s proprietary risk models.
* Ratings do not constitute investment advice.
All ratings, probabilities, and qualitative assessments displayed here are provided by [Credora](https://www.credora.network/) and do not represent Spark’s own analysis.
***
## Data Sources and Methodology
Credora ingests **position-level collateral data** and reconciles it against on-chain state across:
* Lending markets
* Liquidity pools
* Reserve assets
#### References
* [Credora rating methodology](https://docs.redstone.finance/docs/redstone-credora/how-to-rate-spark/)
* [Full Credora rating report](https://reports.credora.io/spark/latest.pdf)
## USDT Strategy
Spark Savings USDT (spUSDT) is a non-custodial, permissionless stablecoin savings vault backed by USDS (see [USDS Collateral Backing](https://financial.skyeco.com/usds/collateral-backing)).
We surface the USDT liquidity strategy in particular because of the more restrictive liquidity profile in comparison to USDC, as well as highlight how well it performed during the rsETH incident of April 18th, 2026.
This document sets out Spark's standing framework for idle liquidity management, how we approach venue selection, rate-setting, and liquidity buffers across market conditions, with the central goal of deploying capital above the **Minimum Liquidity Requirement (MLR)** efficiently without compromising SparkLend borrower liquidity or depositor redemption capacity.
### Core Principle: Tiered Deployment, Automated Liquidity Defense
Spark operates a tiered deployment model. Capital is allocated in priority order from most liquid to least liquid, with an automated planner that withdraws from junior venues first when liquidity tightens. The goal is to keep SparkLend fully liquid at all times while earning a return on every USDT above the MLR buffer.
* **SparkLend (Primary Venue).** SparkLend is the default and highest-priority deployment venue. USDT lent here is available on demand and earns the benchmark rate. Spark operates the largest on-chain USDT lending market by size, with cross-collateral capacity no other venue matches. Preserving SparkLend liquidity is non-negotiable - it underpins both depositor safety and borrower UX.
* **Morpho Blue Chip Vault (Overflow Deployment).** Capital beyond SparkLend's absorption capacity is deployed into the Spark Morpho vault across blue-chip collateral markets (WBTC, cbBTC, sUSDS, wstETH).
* **Duration Products (Capped, Risk-Adjusted).** A limited allocation to fixed-income, duration-bearing products (currently Maple Finance syrupUSDT) captures the yield premium available at the short end of the curve. This tier is intentionally capped. Duration allocation is sized against: (i) redemption lag relative to MLR stress scenarios, (ii) concentration of this allocation as a share of the total product, and (iii) the withdrawal cadence of large depositors. We do not increase this tier unless liquidity buffers and depositor composition clearly support it.
* **DEX Liquidity & Stablecoin Inventory Management.** A portion of idle USDT is deployed into DEX liquidity pools as a capital-efficient alternative to holding cash. Spark currently maintains a USDT/sUSDS pool on Curve, which serves a dual purpose: it earns fees on stablecoin flows while acting as an on-chain inventory mechanism, allowing the planner to swap between USDT and USDC/sUSDS programmatically as inventory needs shift. Spark will introduce a USDT pool on Uniswap v4, which provides meaningfully stronger price-making and market-making capability relative to Curve's stable AMM design, enabling tighter spreads and more efficient inventory rebalancing at scale.
USDT converted to USDC through these pools is deposited into Sky's sUSDS vault at \~3.65%, the effective risk-free rate in the Sky ecosystem, materially reducing cash drag on idle balances without taking on duration or counterparty risk beyond the Sky stack.
### Rate-Setting Philosophy
Spark sets spUSDT savings rates against three inputs: P\&L sustainability across the full deposit base, depositor composition, and on-chain borrow demand. Rates are adjusted to reflect what deployment yields can support. When borrow demand softens, rates move accordingly. We price for the full book, not the marginal depositor.
The automated planner enforces a rate-response feedback loop: as liquidity approaches MLR thresholds, rates rise automatically to attract deposits and incentivise borrower repayment. The system replaces excess idle buffers that are not required as insurance.
### How We Respond to Market Stress
The rsETH / KelpDAO incident in April 2026, $196M+ in Aave bad debt, $13.2B DeFi TVL drawn down in 48 hours, Spark Savings USDT was the only major lending venue that remained fully liquid throughout, never breaking below $400M in idle USDT. SparkLend TVL grew +50% in the days that followed.
The incident produced several durable changes to how we think about stress management:
**Conservative MLR anchoring.** MLR is sized to the largest single-depositor exposure. During stress, large depositors run liquidity checks and make partial withdrawals. Spark's approach is to hold enough idle USDT in Spark Savings at all times to absorb these without triggering rate spikes that squeeze borrowers.
**Duration risk is asymmetric.** In stress, the venues that fail first are duration products with redemption lags. Spark sizes duration allocations to ensure that even a full Morpho exit plus partial Maple redemption leaves SparkLend borrowers unaffected. Duration allocation is sized against the downside, not the yield.
**Avoid over-deployment into yield at the cost of liquidity.** The implicit lesson from Aave's experience with rsETH is that reaching for yield through concentrated, leveraged, or bridge-backed collateral creates contagion pathways. Spark's collateral profile, blue-chip only, conservative LTV, rate-limited supply caps, is a structural risk differentiator, not just a positioning choice.
### Case Study: Rate Management Framework
Spark's planner dynamically manages spUSDT supply rates against the liquidity position. When liquidity falls below a set threshold of MLR, the planner withdraws from Morpho. When it falls below the critical threshold of MLR, rates rise automatically to incentivize borrower repayment and new deposits. Meanwhile, the strategy can also set a benchmark rate target for both SparkLend and Morpho to maintain SparkLend's borrower depth as the primary cross-collateral venue, while using Morpho as an overflow deployment sink.
### Current Deployment Snapshot (May 5, 2026)
| Venue | Allocation | Rate / Yield | Liquidity Profile |
| :--------------------- | :---------------------- | :--------------------- | :----------------------------------- |
| SparkLend USDT | \~$488M active borrows | 2.75% benchmark | Instant - on-demand |
| SparkLend Idle | \~$156M idle in market | 0% (buffer) | Instant - MLR buffer |
| Morpho Blue Chip Vault | \~$36M | 2.5-2.75% | Junior; withdrawn first under stress |
| Maple syrupUSDT | $76M | 4.5% (capped) | 2-7 day redemption lag |
| Idle | \~$734M (transitioning) | 3.65% via sUSDS (USDC) | Basis risk; managed manually |
### What Changed and Why
* **Spark Savings USDT was the only major lending venue that remained fully liquid.** Spark held $400M+ in idle USDT throughout the crisis, never breaking below liquidity requirements. SparkLend TVL grew +50% in the days following the incident as the capital fled Aave to Spark. This validated maintaining a conservative idle buffer and not over-deploying into duration.
* **On-chain borrow demand dropped sharply post-incident.** Post-incident borrower demand on SparkLend/Morpho collapsed. The on-chain USDT borrow market went from $642M peak borrow (April 26) to \~$488M by early May. Morpho asset spreads were cut post-incident to maximize Morpho deployment of otherwise-idle USDT.
* **SLL USDT inventory wound down entirely.** The $150-250M USDT SLL inventory buffer (held ready for rapid cross-chain deployment) was wound down to zero. With borrower demand soft, holding large SLL inventory generated pure drag. The team will shift to more capital-efficient allocation strategies as indicated above.
* **syrupUSDT capped; duration risk managed carefully.** Maple initially wanted $100-175M at 2-week duration and return compression at scale. Spark capped at $76M.
## Spark Savings Guides
Spark Savings guides cover user workflows. For the product overview, vault listing, risk architecture, and verification sources, start with [Spark Savings](/products/spark-savings).
### Workflows
* [Deposit & Withdraw](/products/spark-savings/guides/tutorial)
* [Savings Liquidity Intents](/products/spark-savings/guides/liquidity-intents)
For larger withdrawals from **Spark Savings USDC** and **Spark Savings USDT** on **Ethereum Mainnet**, see the [Savings Liquidity Intents guide](/products/spark-savings/guides/liquidity-intents).
## Savings Liquidity Intents
Savings Liquidity Intents let users request larger withdrawals from Spark Savings when the amount exceeds the idle liquidity currently available in the vault. Initially, this flow is available only on **Ethereum Mainnet** for **Spark Savings USDC** and **Spark Savings USDT**.
Spark Savings vaults keep a portion of assets as instantly withdrawable liquidity. In the app, this is shown as **Idle** in the **Liquidity** tab. This idle liquidity acts as the minimum withdrawal buffer kept in the vault. When users withdraw from that buffer, the Spark Liquidity Layer refills it again. For larger withdrawals that exceed the currently available idle liquidity, the app can use Savings Liquidity Intents and submit an asynchronous withdrawal request that is usually fulfilled within a few minutes.
### Check available idle liquidity
1. Navigate to the **Savings** page in the [Spark App](https://app.spark.fi/) and select the **USDC** or **USDT** vault.
*Savings page*
2. Open the **Liquidity** tab to see how vault liquidity is allocated. The amount labeled **Idle** is the liquidity currently available for instant withdrawals.
*Idle liquidity*
### Request a larger withdrawal
1. Click the **Withdraw** button in the main vault panel.
2. In the withdraw window, the withdrawal asset is preselected for supported vaults. Enter the amount you want to withdraw.
3. If the withdrawal will use Savings Liquidity Intents, the dialog will show that the request uses the asynchronous withdrawal process powered by the Spark Liquidity Layer.
*Withdraw with Savings Liquidity Intents*
4. Complete the actions shown in the **Actions** section and confirm the request in your wallet.
5. After submission, the app will show a confirmation screen. This confirms that the withdrawal request was created. The Spark Liquidity Layer still needs to fulfill it before the funds arrive in your wallet.
*Withdrawal request submitted*
6. After you close the dialog, the request will appear in the **Requested withdrawal** table on the Savings page with a **Pending** status and an estimated completion time.
*Pending withdrawal request*
7. Once the request is fulfilled, the withdrawn funds are transferred to your wallet automatically.
### Cancel a withdrawal request
1. Withdrawal requests cannot be cancelled during the first hour after submission. During that period, the **Cancel** button is disabled in the **Requested withdrawal** table.
*Cancellation unavailable during the first hour*
2. If the Spark Liquidity Layer has not fulfilled the request within one hour, the **Cancel** button becomes available.
*Cancellation available after one hour*
3. Click **Cancel** and confirm the cancellation request in the dialog.
*Cancel withdrawal request*
4. After the transaction is confirmed, the app will show a success screen confirming that the withdrawal request has been cancelled.
*Withdrawal request cancelled*
## Deposit & Withdraw From Spark Savings
In this tutorial, you will learn how to deposit and withdraw assets from Spark Savings.
### Deposit Savings
1. To earn yield on your assets navigate to the **Savings** page at [app.spark.fi](https://app.spark.fi).
Make sure you are connected to the network you wish to use.
*Savings Page*
2. To the left, you can see which Savings Vaults are available. Each vault displays its current Annual Percentage Yield (APY). Click on any vault to see more details, such as the collateral composition and supported assets, or to deposit. You can also see the TVL, users, deposit cap and available liquidity in the top bar.
3. When you select a vault, you'll see:
* Current and historical rates
* Savings rate, collateral composition, risk assessment and more
* Supported deposit assets
*Savings Rate*
*Collateral Composition*
*Liquidity*
*Risk Rating*
4. To deposit, click the **Deposit** button for your selected vault.
*Deposit Window*
5. In the deposit window, specify:
* The asset you want to deposit (if the vaults support multiple assets for deposits)
* The amount you wish to deposit
To finalize the deposit, execute the transactions in the **Actions** section.
6. Once you complete the transactions, your assets will be deposited and you'll receive vault tokens (e.g., spUSDC, spUSDT, spETH, sUSDS, etc.) representing your share of the vault.
*Confirmation: Savings Deposit*
7. Your vault tokens represent your share of deposits in the vault. You need these tokens to withdraw your deposits and accrued yield in the future, so keep them safe in your wallet.
8. After your deposit, you'll see your balance grow in real time as yield accrues. You can also see your projected earnings in the **1-year Projection** section.
*Accruing Yield*
### Withdraw Savings
1. When you wish to withdraw from a vault, click the **Withdraw** button for your selected vault. In the withdraw window, the withdrawal asset is preselected for supported vaults. Enter the amount you wish to withdraw.
*Withdraw from Savings*
2. The UI will show you:
* The amount you'll receive
* Transaction steps in the **Actions** section
**Note:** Spark Savings Vaults V2 keep an idle liquidity buffer for instant withdrawals. For larger withdrawals from **Spark Savings USDC** and **Spark Savings USDT** on **Ethereum Mainnet** that exceed the currently available idle liquidity, the app may use **Savings Liquidity Intents**, which submit an asynchronous withdrawal request to the Spark Liquidity Layer. These requests are usually fulfilled within a few minutes. [Learn more about Savings Liquidity Intents](/products/spark-savings/guides/liquidity-intents).
3. Execute the transactions in the **Actions** section. Once complete, your vault tokens will be burned and you'll receive your specified asset along with all accrued yield.
*Confirmation: Withdrawal from Savings*
## Spark Points
The Spark Points program enables users to earn Spark Points by participating in campaigns that reward certain user actions that contribute to the growth of the Spark ecosystem.
### How do I earn Spark Points?
You earn Spark Points by participating in points campaigns. Navigate to the Spark Points page at [app.spark.fi/points](http://app.spark.fi/points) to find an overview of active campaigns and how you can participate. As soon as you participate in a points campaign you will start accruing points.
1. Navigate to the [Points page](http://app.spark.fi/points).
*Navigate to the points page*
2. Put in a referral code if you have one. You can read more about [referral codes below](#referral-boost). If you do not have a code, simply click “I don’t have an invite code” to skip this.
*Insert referral code or skip*
3. Start participating by following the campaign actions.
*Choose a campaign to participate in*
4. Invite others, by using your referral code or link to earn even more points!
*Invite others using your referral code*
5. Check your ranking in the leaderboard at [https://points.spark.fi/](https://points.spark.fi/) or simply watch your points accrue over time.
*Spark Points Leaderboard*
### Seasons
The Spark Points program is divided into seasons. Each season have a different set of campaigns and rewards.
* Season 1: May 14, 2025 to August 12, 2025,
* Season 2: August 12, 2025 to December 12, 2025,
* Season 3: December 12, 2025 to April 13, 2026,
* Season 4: April 13, 2026 to August 12, 2026.
### Campaigns
You can find the active campaigns and how to participate at [app.spark.fi/points](http://app.spark.fi/points).
### Points Accrual
Points accrue per second based on your participation in the rewarded actions. You can track your points at [app.spark.fi/points](http://app.spark.fi/points).
### Referral Boost
The Spark Points program includes a referral program. If a user signs up using your referral code, you will earn 10 % extra points for all the points your referrals earn. To get your referral code, simply click on the “Invite” button on the Referral boost action, and share the link with your friends.
*Invite others using your referral code*
### Loyalty Boost
Users who participated in Season 1 and continue into Season 2 can receive a one-time **10% loyalty bonus** of all their Season 1 points when they transition to Season 2.
To qualify for the loyalty bonus, the user must:
* Claim and stake all the SPK tokens they earned from Season 1
* The stake must remain active until the end of Season 2
### Leaderboard
At [https://points.spark.fi/](https://points.spark.fi/) you will find a leaderboard of the highest Spark points earners. Use your referral code to earn more points, and climb the leaderboards!
## Earn Spark Points on Pendle
The Pendle Campaign enables users to earn Spark Points by holding YT-USDS tokens or by providing liquidity into the PT-USDS/USDS pool on Pendle.
### Points Distribution
#### YT-USDS
Users will earn 25 Spark Points per day per YT-USDS they are holding in their wallet.
#### Providing PT-USDS/SY-USDS liquidity
Users will earn 25 Spark Points per day for each USDS (SY-USDS) that they are providing as liquidity in the Pendle pool.
**Note:** This means LPs are only earning Spark points on the USDS part of the liquidity position. However, this is in addition to any yield LPs may earn from Pendle.
### Campaign Duration
The Pendle Campaign will run from May 14 to August 12, 2025.
### How to Participate
1. Navigate to [app.spark.fi/points](http://app.spark.fi/points) and connect your wallet.
*Navigate to the points page, and connect wallet*
2. Optional: Use a referral code if you have one. Otherwise, skip this step by clicking “I don’t have an invite code”.
*Insert referral code or skip*
3. Navigate to the [Pendle pool](https://app.pendle.finance/trade/pools/0x1d7d382ea7ceabb8d7c14ef066124d2e575698f8/zap/in) by clicking “Buy” and acquire either YT-USDS tokens, or provide liquidity into the PT-USDS/USDS pool.
*Navigate to the Pendle pool, and purchase YT-USDS or provide liquidity*
4. You will start accruing points immediately which you will be able to track at [app.spark.fi/points](http://app.spark.fi/points). Note: It might take a few minutes for your points score to be displayed.
*Overview of accrued points*
5. Invite your friends using your referral code to earn even more points. For each user who signs up using your referral code, you will earn 10% of the points that user earns. To get your referral code, simply click on the “Invite” button on the Referral boost action, and share the link with your friends. You can track your position in the leaderboards at [points.spark.fi](http://points.spark.fi)
*Generate Referral Code*
## Earn Spark Points by Staking SPK
The SPK Staking Campaign enables users to earn Spark Points by staking SPK tokens on the Spark app.
### Points Distribution
#### SPK Staking
Users will earn 3 Spark Points per day per SPK token they are staking on the Spark app.
### How to Participate
1. Navigate to [app.spark.fi/points](http://app.spark.fi/points) and connect your wallet.
*Navigate to the points page, and connect wallet*
2. Optional: Use a referral code if you have one. Otherwise, skip this step by clicking "I don't have an invite code".
*Insert referral code or skip*
3. Navigate to the SPK staking section on the Spark app and stake your SPK tokens.
*Navigate to the staking section and stake your SPK tokens*
4. You will start accruing points immediately which you will be able to track at [app.spark.fi/points](http://app.spark.fi/points). Note: It might take a few minutes for your points score to be displayed.
*Overview of accrued points*
5. Invite your friends using your referral code to earn even more points. For each user who signs up using your referral code, you will earn 10% of the points that user earns. To get your referral code, simply click on the "Invite" button on the Referral boost action, and share the link with your friends. You can track your position in the leaderboards at [points.spark.fi](http://points.spark.fi)
*Generate Referral Code*
| 0 | Table of content |
Date of notification
Statement in accordance with Article 6(3) of Regulation (EU) 2023/1114
Compliance statement in accordance with Article 6(6) of Regulation (EU) 2023/1114
Statement in accordance with Article 6(5), points (a), (b), (c) of Regulation (EU) 2023/1114
Statement in accordance with Article 6(5), point (d) of Regulation (EU) 2023/1114
Statement in accordance with Article 6(5), points (e) and (f) of Regulation (EU) 2023/1114
SUMMARY
Warning in accordance with Article 6(7), second subparagraph of Regulation (EU) 2023/1114
Characteristics of the crypto-asset
Key information about the offer to the public or admission to trading
Part I – Information on risks
Offer-Related Risks
Issuer-Related Risks
Crypto-Assets-related Risks
Project Implementation-Related Risks
Technology-Related Risks
Mitigation measures
Part A - Information about the offeror or the person seeking admission to trading
Name
Legal form
Registered address
Head office
Registration Date
Legal entity identifier
Another identifier required pursuant to applicable national law
Contact telephone number
E-mail address
Response Time (Days)
Parent Company
Members of the Management body
Business Activity
Parent Company Business Activity
Newly Established
Financial condition for the past three years
Financial condition since registration
Part B - Information about the issuer, if different from the offeror or person seeking admission to trading
Issuer different from offeror or person seeking admission to trading
Name
Legal form
Registered address
Head office
Registration Date
Legal entity identifier
Another identifier required pursuant to applicable national law
Parent Company
Members of the Management body
Business Activity
Parent Company Business Activity
Part C - Information about the operator of the trading platform in cases where it draws up the crypto-asset white paper and information about other persons drawing the crypto-asset white paper pursuant to Article 6(1), second subparagraph, of Regulation (EU) 2023/1114
Name
Legal form
Registered address
Head office
Registration Date
Legal entity identifier of the operator of the trading platform
Another identifier required pursuant to applicable national law
Parent Company
Reason for Crypto-Asset White Paper Preparation
Members of the Management body
Operator Business Activity
Parent Company Business Activity
Other persons drawing up the crypto-asset white paper according to Article 6(1), second subparagraph, of Regulation (EU) 2023/1114
Reason for drawing the white paper by persons referred to in Article 6(1), second subparagraph, of Regulation (EU) 2023/1114
Part D - Information about the crypto-asset project
Crypto-asset project name
Crypto-assets name
Abbreviation
Crypto-asset project description
Details of all natural or legal persons involved in the implementation of the crypto-asset project
Utility Token Classification
Key Features of Goods/Services for Utility Token Projects
Plans for the token
Resource Allocation
Planned Use of Collected Funds or Crypto-Assets
Part E - Information about the offer to the public of crypto-assets or their admission to trading
Public Offering or Admission to trading
Reasons for Public Offer or Admission to trading
Fundraising Target
Minimum Subscription Goals
Maximum Subscription Goal
Oversubscription Acceptance
Oversubscription Allocation
Issue Price
Official currency or any other crypto-assets determining the issue price
Subscription fee
Offer Price Determination Method
Total Number of Offered/Traded Crypto-Assets
Targeted Holders
Holder restrictions
Reimbursement Notice
Refund Mechanism
Refund Timeline
Offer Phases
Early Purchase Discount
Time-limited offer
Subscription period beginning
Subscription period end
Safeguarding Arrangements for Offered Funds/Crypto-Assets
Payment Methods for Crypto-Asset Purchase
Value Transfer Methods for Reimbursement
Right of Withdrawal
Transfer of Purchased Crypto-Assets
Transfer Time Schedule
Purchaser's Technical Requirements
Crypto-asset service provider (CASP) name
CASP identifier
Placement form
Trading Platforms name
Trading Platforms Market Identifier Code (MIC)
Trading Platforms Access
Involved costs
Offer Expenses
Conflicts of Interest
Applicable law
Competent court
Part F - Information about the crypto-assets
Crypto-Asset Type
Crypto-Asset Functionality
Planned Application of Functionalities
A description of the characteristics of the crypto-asset, including the data necessary for classification of the crypto-asset white paper in the register referred to in Article 109 of Regulation (EU) 2023/1114, as specified in accordance with paragraph 8 of that Article
Type of white paper
The type of submission
Crypto-Asset Characteristics
Commercial name or trading name
Website of the issuer
Starting date of offer to the public or admission to trading
Publication date
Any other services provided by the issuer
Identifier of operator of the trading platform
Language or languages of the white paper
Digital Token Identifier Code used to uniquely identify the crypto-asset or each of the several crypto assets to which the white paper relates, where available
Functionally Fungible Group Digital Token Identifier, where available
Voluntary data flag
Personal data flag
LEI eligibility
Home Member State
Host Member States
Part G - Information on the rights and obligations attached to the crypto-assets
Purchaser Rights and Obligations
Exercise of Rights and obligations
Conditions for modifications of rights and obligations
Future Public Offers
Issuer Retained Crypto-Assets
Utility Token Classification
Key Features of Goods/Services of Utility Tokens
Utility Tokens Redemption
Non-Trading request
Crypto-Assets purchase or sale modalities
Crypto-Assets Transfer Restrictions
Supply Adjustment Protocols
Supply Adjustment Mechanisms
Token Value Protection Schemes
Token Value Protection Schemes Description
Compensation Schemes
Compensation Schemes Description
Applicable law
Competent court
Part H – Information on the underlying technology
Distributed ledger technology
Protocols and technical standards
Technology Used
Consensus Mechanism
Incentive Mechanisms and Applicable Fees
Use of Distributed Ledger Technology
DLT Functionality Description
Audit
Audit outcome
Part J – Information on the sustainability indicators in relation to adverse impact on the climate and other environment-related adverse impacts
Name
Relevant legal entity identifier
Name of the crypto-asset
Consensus Mechanism
Incentive Mechanisms and Applicable Fees
Beginning of the Period to which the Disclosed Information Relates
End of the Period to which the Disclosed Information Relates
Mandatory key indicator on energy consumption
Energy Consumption
Sources and methodologies
Energy Consumption Sources and Methodologies
|
| :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------ | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **1** | **Date of notification** | 16/04/2025 |
| **2** | **Statement in accordance with Article 6(3) of Regulation (EU) 2023/1114** | This crypto-asset white paper has not been approved by any competent authority in any Member State of the European Union. The offeror of the crypto-asset is solely responsible for the content of this crypto-asset white paper. |
| **3** | **Compliance statement in accordance with Article 6(6) of Regulation (EU) 2023/1114** | This crypto-asset white paper complies with Title II of Regulation (EU) 2023/1114 and, to the best of the knowledge of the management body, the information presented in the crypto-asset white paper is fair, clear and not misleading and the crypto-asset white paper makes no omission likely to affect its import. |
| **4** | **Statement in accordance with Article 6(5), points (a), (b), (c) of Regulation (EU) 2023/1114** | The crypto-asset referred to in this white paper may lose its value in part or in full, may not always be transferable and may not be liquid. |
| **5** | **Statement in accordance with Article 6(5), point (d) of Regulation (EU) 2023/1114** | FALSE |
| **6** | **Statement in accordance with Article 6(5), points (e) and (f) of Regulation (EU) 2023/1114** | The crypto-asset referred to in this white paper is not covered by the investor compensation schemes under Directive 97/9/EC of the European Parliament and of the Council. The crypto-asset referred to in this white paper is not covered by the deposit guarantee schemes under Directive 2014/49/EU of the European Parliament and of the Council. |
| **SUMMARY** | | |
| **7** | **Warning in accordance with Article 6(7), second subparagraph of Regulation (EU) 2023/1114** | Warning
This summary should be read as an introduction to the crypto-asset white paper. The prospective holder should base any decision to purchase this crypto-asset on the content of the crypto-asset white paper as a whole and not on the summary alone.
The offer to the public of this crypto-asset does not constitute an offer or solicitation to purchase financial instruments and any such offer or solicitation can be made only by means of a prospectus or other offer documents pursuant to the applicable national law.
This crypto-asset white paper does not constitute a prospectus as referred to in Regulation (EU) 2017/1129 of the European Parliament and of the Council (36) or any other offer document pursuant to Union or national law. |
| **8** | **Characteristics of the crypto-asset** | SPK (the "***Token***") will be launched as an ERC-20 token on the Ethereum blockchain. The Token will provide its holders with a set of rights within Spark (the "***Project***"), a decentralised finance application. Token holders will be able to stake their Tokens and earn protocol rewards. It is anticipated that staked Tokens will be used to secure one or more components of the Project, such as, for example, the SkyLink Bridge.
It is also anticipated that the Token will serve as a governance token, allowing holders to help shape the future of the Project. Any governance rights granted to Token holders will be subject to the disclaimers and qualifications made in Section F.3 and Section G.3. |
| **09** | | Not applicable |
| **10** | **Key information about the offer to the public or admission to trading** | Spark Foundation (the "***Foundation***") seeks admission of the Token to trading on multiple trading platforms (the "***Exchanges***") in order to increase the liquidity and exchangeability of the Token, facilitate more participation in governance, and increase the number of tokens staked that may secure one or more components of the Project. |
| **Part I – Information on risks** | | |
| **I.1** | **Offer-Related Risks** | The Foundation neither operates, controls, oversees, nor manages the functioning of the Exchanges where the Token will be admitted. Additionally, the Token's underlying protocol and governance structure may evolve due to ongoing technical, regulatory, and industry developments. Unforeseen risks may arise, and new challenges or opportunities may necessitate changes in the Project's strategies, goals, and structure. The risks outlined below highlight regulatory uncertainty, liquidity limitations, governance risks, network centralisation concerns, security vulnerabilities, and potential adjustments to fees or token supply that could impact the offer and trading of the Token.
**Regulatory Compliance Risks**: Evolving regulatory landscapes could impact the Token's classification, trading status, or market acceptance. Changes in regulatory requirements may necessitate modifications to the Project's operation, structure, or governance.
**Market Volatility**: The Token may be subject to extreme price fluctuations, influenced by speculation, market sentiment, and broader industry trends. External factors, such as regulatory announcements or technological developments, may further contribute to volatility, potentially leading to financial losses for holders.
**Liquidity Risks**: The ability to buy and sell Tokens depends on trading activity on decentralised exchanges ("***DEXs***") and, if applicable, centralised exchanges ("***CEXs***"). Limited liquidity may result in difficulties executing large trades without significant price impact, increasing the risk of loss.
**Risk of Trading Platforms**: When Token holders trade on Exchanges, neither the Issuer nor the Foundation acts as a contractual party to these transactions. All legal relationships regarding these trading platforms are subject to their respective terms and conditions, with no responsibility assumed by the Foundation for their operations, services, or outcomes.
**Risk of Delisting**: There is no guarantee that the Token will remain listed on any exchange. Delisting could significantly hinder the ability to trade Tokens, reducing liquidity and market value.
**Risk of Bankruptcy**: The Exchanges or trading platforms where the Token is listed may become insolvent or cease operations, potentially resulting in a loss of access to funds or Tokens.
**Blockchain and Smart Contract Dependency**: The Token relies entirely on its blockchain infrastructure. Any network downtime, congestion, security vulnerabilities, or smart contract failures could negatively impact its functionality, accessibility, or security.
**Governance and Economic Model Risks**: While no inflationary events are currently anticipated, Sky governance will retain the power to mint new Tokens in the future. **Legal Risks**: Uncertainties in legal frameworks, regulatory changes, potential lawsuits, or adverse legal rulings could pose significant risks, affecting the value of the Token.
**Reputational Risks**: Negative publicity – whether due to operational failures, security breaches, or associations with illicit activities—could damage the Project's reputation and, by extension, impact the value and acceptance of the Token.
**Technology Management Risks**: Inadequate management of technological updates or failure to keep pace with advancements may result in security vulnerabilities, inefficiencies, or obsolescence of the Token and its supporting infrastructure.
**Concentration and Conflicts of Interest**: Concentration of Token holdings may lead to governance decisions that favour the interests of one or more specific holders rather than the interests of the community, potentially affecting the value of the Token.
**Decentralised Governance Risk**: The majority of the Token supply will be managed by decentralised governance, including Sky governance and Spark governance. Risks associated with decentralised governance, including without limitation the risk of capture, may negatively impact the value of the Token.
**Industry Competition Risks**: The Project faces competition from other projects, including larger and well-funded ventures that may attract more users and liquidity, potentially diminishing the viability of the Token.
**Unanticipated Risks**: There may be additional risks that cannot be foreseen. Some risks may materialise as unexpected variations or combinations of the factors discussed in this section.
|
| **I.2** | **Issuer-Related Risks** | Not applicable, as the only purpose of the Issuer is to issue and distribute the Token. |
| **I.3** | **Crypto-Assets-related Risks** |
**Market Volatility Risks**: It is anticipated that the Token's value will be highly volatile and may fluctuate due to market speculation, investor sentiment, regulatory developments, and technological advancements. External factors, such as shifting trends in the crypto industry, changes in demand for blockchain services, or macroeconomic conditions, could contribute to extreme price fluctuations, potentially leading to total depreciation.
**Liquidity Risks**: The ability to trade the Token depends on the level of activity on DEXs and, where applicable, CEXs. Low trading volume may result in difficulties executing large transactions without significant price impact. Limited demand for the Token or the underlying protocol may further reduce liquidity, making it difficult to acquire or sell the Token.
**Slashing Risk**: If staked Tokens are used to secure one or more components of the Project, they may be subject to a slashing mechanism. As such, there is a risk that a holder of staked Tokens could lose their Tokens in a slashing event.
**Adoption and Project Demand Risks**: The long-term success of the Token is dependent on widespread adoption of the Project. Adoption is influenced by various external factors, including user demand, competitive market conditions, and organic community-driven expansion. The Foundation has no control over the pace of adoption, and there is no guarantee that the Project will gain sufficient traction to sustain its economic model.
**Blockchain Dependency Risks**: The Token operates exclusively on its underlying blockchain network. Any disruptions, such as network congestion, downtime, or security vulnerabilities, could impact the ability to transfer, store, or trade the Token. Changes to blockchain infrastructure, governance, or transaction fees may also influence the Token's usability and cost-effectiveness.
**Transaction Costs:** While blockchain fees are generally low, network congestion, high demand, or changes in blockchain fee structures may increase transaction costs, potentially reducing the economic viability of using the Token.
**Security Risks**:
***Smart Contract Vulnerabilities***: Despite security audits and best practices, unforeseen vulnerabilities in smart contracts could lead to security breaches, impacting Token security or functionality.
***Private Key Management***: Token holders are solely responsible for safeguarding their private keys and recovery phrases. Loss of wallet credentials will result in the permanent loss of Tokens, as blockchain transactions are irreversible.
**Scam and Fraud Risks**: Token holders are exposed to risks associated with scams, phishing attacks, fake giveaways, impersonation of the Foundation or its team, counterfeit Tokens, and fraudulent airdrops. Engaging with unverified third-party platforms or unofficial communications increases the risk of fraud.
**Community and Narrative Risks**: The Token's success is closely tied to community interest and the broader crypto narrative. Market trends, emerging competitors, or declining community engagement may negatively impact the Token's perceived value and adoption.
**Regulatory and Compliance Risks**:
***Evolving Legal Frameworks***: Regulations governing crypto-assets differ across jurisdictions and are subject to change. New legal requirements may impact the Token's classification, availability, or functionality. ***Jurisdictional Restrictions***: Some jurisdictions may impose restrictions or prohibitions on the trading or use of the Token, limiting its accessibility for certain users.
**Technological Obsolescence Risks**: The blockchain and crypto industries evolve rapidly. The emergence of new technologies, changes in market demand, or advancements in competing protocols could render the Token or its underlying blockchain infrastructure less competitive, reducing adoption and utility.
**Software Weakness Risks**: The Token's infrastructure relies on relatively new blockchain technologies, which may contain undiscovered bugs, vulnerabilities, or inefficiencies. There is no guarantee that the process of transacting, storing, or interacting with the Token will be uninterrupted or error-free.
**Unanticipated Risks**: Beyond the risks outlined above, additional unforeseen risks may emerge due to changes in regulatory, technological, or market conditions, potentially affecting the Token's security, functionality, or value.
The Foundation neither operates, controls, oversees, nor manages the technology underlying the Project. While efforts are made to ensure security and stability, blockchain-based technologies are still evolving, and various risks exist. Additionally, the success and sustainability of the Project rely on various external factors, including market conditions, regulatory developments, and technological advancements.
**Technical Development Risks**:
***Smart Contract Issues***: Despite robust security measures, unforeseen vulnerabilities or bugs in the smart contracts could disrupt Token distribution, refunds, or vesting mechanisms.
***Blockchain Dependency***: The Token operates exclusively on its underlying blockchain. Any network congestion, downtime, or security breaches could impact the Project's implementation and functionality.
***Risk of Security Weaknesses in Core Infrastructure***: The Project relies on open-source software, which may be modified by third parties. Weaknesses or bugs introduced into the core infrastructure could compromise security and lead to the loss of digital assets. Furthermore, malfunctions or inadequate maintenance of the Project may negatively impact the Token's usability.
***Bugs in Core Blockchain Code***: Even with rigorous testing, unknown bugs may exist in the blockchain protocol, potentially leading to disruptions, incorrect transaction processing, or security vulnerabilities.
**Regulatory and Compliance Risks:**
***Regulatory Actions in One or More Jurisdictions***: The Token and the underlying Project could be impacted by regulatory inquiries or actions, which may restrict further development, implementation, or usage.
***Evolving Laws and Regulations***: New and changing laws related to financial securities, consumer protection, data privacy, cybersecurity, and intellectual property could impact the Project and the Token.
***Governance Risk***: Decision-making mechanisms in blockchain governance may be inefficient, slow, or disproportionately influenced by specific stakeholders, leading to potential centralisation or unfavourable governance outcomes.
**Operational Risks**:
***Resource Allocation***: The Project's success depends on the team allocating sufficient resources (both financial and non-financial) to ensure timely development and deployment. Poor resource management could lead to delays or failure to achieve key milestones.
**Market Adoption Risks**: ***Competitive Environment***: The crypto market is highly competitive and trend-driven. There is a risk that the Token may fail to capture sufficient interest, limiting its adoption.
***Community Engagement Risks***: The success of the Token depends heavily on community-driven marketing and engagement. Failure to build or sustain an active community could hinder growth and long-term tradability.
**Timeline and Milestone Risks**:
***Delayed Milestones***: Key milestones may face delays due to technical, operational, or funding challenges.
***CEX Listing Risks***: Listings on centralised exchanges depend on securing the necessary funding for listing fees and meeting platform-specific requirements. Delays or insufficient resources could postpone broader market access.
**Ecosystem Risks**:
***Dependence on External Parties***: The Project relies on infrastructure providers and other third-party service providers. Any failure or delay from third parties could disrupt implementation plans.
**Technology and Software Risks**:
***Risk of Software Weakness***: Blockchain and smart contract technologies are still evolving. There is no guarantee that Token usage will be uninterrupted or error-free. Vulnerabilities in the underlying blockchain, smart contracts, or supporting technologies could lead to the complete loss of Tokens or their functionality.
***Dependency on Underlying Technology***: The Project relies on blockchain infrastructure, hardware, and network connectivity, all of which may be subject to failures, outages, or vulnerabilities.
***Risk of Technological Disruption***: The emergence of new technology, such as quantum computing, could undermine the security of blockchain encryption and compromise the integrity of digital assets.
**Network Security Risks**: ***Network Attacks and Cybersecurity Threats***: Blockchain networks can be vulnerable to cyberattacks such as 51% attacks, Sybil attacks, or distributed denial-of-service ("***DDoS***") attacks. These threats could disrupt network operations and compromise security.
***Blockchain Network Attacks***: The Network may be subject to mining attacks, including double-spend attacks, reorganisations, majority mining power attacks, "selfish-mining" attacks, and work race condition attacks. Successful attacks could compromise the proper execution of transactions and smart contracts.
**Privacy and Anonymity Risks**:
***Public Ledger Transparency***: Blockchain transactions are recorded on a public ledger, which may expose transaction history and financial activity. Certain transactions could be linked to specific wallet addresses, making users vulnerable to fraud, phishing attacks, or targeted scams.
**Economic and Governance Risks**:
***Incentive Model Risks***: Governance decisions could result in modifications that impact Token holders, including inflationary adjustments, transaction fees, or redistribution of rewards.
**Software Weakness Risks**:
***Unforeseen Bugs and Security Vulnerabilities***: The Token and its supporting infrastructure rely on blockchain technologies that may still be evolving. There is no guarantee that Token transactions will be uninterrupted or error-free. Software vulnerabilities, weaknesses in smart contracts, or infrastructure issues may result in loss of assets, security breaches, or unexpected network failures.
**Unanticipated Risks**:
***Unforeseen Regulatory, Technological, or Market Challenges***: In addition to the risks identified, new threats may emerge due to changes in legal, technological, or economic conditions. Developments such as regulatory actions, unforeseen Project vulnerabilities, or disruptive innovations could impact the usability, security, or value of the Token in ways not currently foreseeable.
|
| **I.5** | **Technology-Related Risks** |
The Foundation neither operates, controls, oversees, nor manages the technology underlying the Project. While efforts are made to ensure security and stability, blockchain-based technologies are still evolving, and various risks exist.
**Blockchain Dependency Risks**:
***Network Downtime and Congestion***: The Token relies entirely on its underlying blockchain network, which may experience outages, congestion, or downtime. Such events could disrupt Token transfers, trading, or other functionalities.
***Scalability Challenges***: As transaction volume grows, the blockchain network may face scaling limitations. Increased congestion could lead to slower transaction processing times and higher fees, reducing efficiency and usability.
***Settlement and Transaction Finality Risks***: Blockchain transactions are designed to be irreversible; however, under exceptional circumstances such as network forks or consensus failures, there remains a theoretical risk that transactions could be reversed or multiple competing ledger versions could persist. Transactions sent to an incorrect address are not recoverable, leading to permanent loss of assets.
**Smart Contract Risks**:
***Immutability Risks***: Once deployed, some smart contracts cannot be altered. Errors or security flaws in the code could result in operational failures without the possibility of corrections.
***Security Exploits***: Bugs or vulnerabilities in smart contracts may expose the Token ecosystem to potential hacks, allowing attackers to manipulate transactions, drain liquidity, or disrupt contract execution.
**Wallet and Storage Risks**:
***Private Key Management***: Token holders are solely responsible for securing their private keys and recovery phrases. The loss of private keys results in irreversible loss of Tokens, as blockchain transactions are final and cannot be undone.
***Compatibility Issues***: The Token is supported only by blockchain-compatible wallets. Incompatibility with specific wallet software, network malfunctions, or wallet provider shutdowns may affect access to and usability of the Token.
**Ecosystem Dependency Risks**:
***DEX and CEX Integration Issues***: The Token's availability depends on integration with DEXs and CEXs. Technical failures, security breaches, or de-listings from these platforms could limit liquidity, disrupt trading, and reduce market accessibility.
***Reliance on Third-Party Services***: Many blockchain services, including wallets, bridges, and oracles, depend on third-party providers. Failures, security breaches, or regulatory actions against these services could negatively affect the functionality of the Token.
**Software and Project Risks**:
***Risk of Attacks and Forks***: The underlying blockchain may be susceptible to consensus-related attacks, such as double-spend attacks, majority validation power takeovers, censorship attacks, or forks. These risks could affect Token transactions, balance integrity, and overall network security.
***Risk of Technological Disruption***: Emerging technologies, such as quantum computing, could potentially compromise blockchain encryption, making networks vulnerable to attacks that could compromise data integrity or enable unauthorised asset transfers.
***Dependency on Underlying Technology***: The stability of the Token ecosystem relies on underlying technical infrastructures, including internet connectivity, computing hardware, and cryptographic algorithms. Disruptions in these foundational technologies may impact network security and operational efficiency.
***Unforeseen Vulnerabilities in Blockchain***: The Token and its supporting infrastructure rely on blockchain technologies that may still be evolving. There is no guarantee that Token transactions will be uninterrupted or error-free. Software vulnerabilities, weaknesses in smart contracts, or infrastructure issues may result in loss of assets, security breaches, or unexpected network failures.
**Privacy and Anonymity Risks**:
***Public Ledger Transparency***: Blockchain transactions are recorded on a publicly accessible ledger, which may expose sensitive transaction data. While addresses do not directly reveal identities, sophisticated data analysis could potentially link certain transactions to specific individuals or entities.
***Exposure to Fraud and Targeted Attacks***: Increased transparency may lead to risks such as phishing, fraud, or unauthorised tracking of user activity by malicious actors. Individuals with significant Token holdings may be targeted for scams or social engineering attacks.
**Economic and Project Viability Risks**:
***Incentive Model Risks***: Governance proposals may introduce modifications that impact Token holders, including inflation adjustments, transaction fees, or changes to rewards.
**Unanticipated Risks**:
***Unforeseen Regulatory, Technological, or Market Challenges***: In addition to the risks identified, new threats may emerge due to changes in legal, technological, or economic conditions. Developments such as regulatory actions, unforeseen Project vulnerabilities, or disruptive innovations could impact the usability, security, or value of the Token in ways not currently foreseeable.
|
| **I.6** | **Mitigation measures** | Not applicable |
| **Part A - Information about the offeror or the person seeking admission to trading** | | |
| **A.1** | **Name** | Spark Foundation |
| **A.2** | **Legal form** | Foundation company limited by guarantee without share capital |
| **A.3** | **Registered address** | Leeward Management Limited, Suite 3119, 9 Forum Lane, Camana Bay, PO Box 144, George Town, Grand Cayman KY1-9006, Cayman Islands |
| **A.4** | **Head office** | Leeward Management Limited, Suite 3119, 9 Forum Lane, Camana Bay, PO Box 144, George Town, Grand Cayman KY1-9006, Cayman Islands |
| **A.5** | **Registration Date** | 05/02/2025 |
| **A.6** | **Legal entity identifier** | Not available |
| **A.7** | **Another identifier required pursuant to applicable national law** | 418210 |
| **A.8** | **Contact telephone number** | 001 345-749-9601 |
| **A.9** | **E-mail address** | Glenn Kennedy: [gkennedy@leewardmanagement.ky](mailto\:gkennedy@leewardmanagement.ky) Marc Piano: [piano@horizonsglobal.io](mailto\:piano@horizonsglobal.io) |
| **A.10** | **Response Time (Days)** | Fourteen (14) days |
| **A.11** | **Parent Company** | Not applicable |
| **A.12** | **Members of the Management body** | **Glenn Kennedy** Director Leeward Management Limited, Suite 3119, 9 Forum Lane, Camana Bay, PO Box 144, George Town, Grand Cayman KY1-9006, Cayman Islands **Marc Piano** Director Leeward Management Limited, Suite 3119, 9 Forum Lane, Camana Bay, PO Box 144, George Town, Grand Cayman KY1-9006, Cayman Islands |
| **A.13** | **Business Activity** | To support, promote, and advance the development, adoption, security, and growth of Spark. |
| **A.14** | **Parent Company Business Activity** | Not applicable |
| **A.15** | **Newly Established** | TRUE |
| **A.16** | **Financial condition for the past three years** | Not applicable |
| **A.17** | **Financial condition since registration** | The Foundation will be capitalised as needed to fulfil its mandate of supporting the Spark ecosystem. It has no debt and being a brand new company, should have no material liabilities as of the date of this whitepaper. |
| **Part B - Information about the issuer, if different from the offeror or person seeking admission to trading** | | |
| **B.1** | **Issuer different from offeror or person seeking admission to trading** | TRUE |
| **B.2** | **Name** | SPK Company Ltd. |
| **B.3** | **Legal form** | Company limited by shares |
| **B.4** | **Registered address** | Trinity Chambers, PO Box 4301, Road Town, Tortola, British Virgin Islands |
| **B.5** | **Head office** | Trinity Chambers, PO Box 4301, Road Town, Tortola, British Virgin Islands |
| **B.6** | **Registration Date** | 19/02/2025 |
| **B.7** | **Legal entity identifier** | Not available |
| **B.8** | **Another identifier required pursuant to applicable national law** | 2170013 |
| **B.9** | **Parent Company** | Spark Foundation |
| **B.10** | **Members of the Management body** | The sole director of the Issuer is **Spark Foundation** The directors of Spark Foundation are Glenn Kennedy and Marc Piano Business address of Spark Foundation is Leeward Management Limited, Suite 3119, 9 Forum Lane, Camana Bay, PO Box 144, George Town, Grand Cayman KY1-9006, Cayman Islands |
| **B.11** | **Business Activity** | The only purpose is to issue and distribute the Token. |
| **B.12** | **Parent Company Business Activity** | See Section A.13. |
| **Part C - Information about the operator of the trading platform in cases where it draws up the crypto-asset white paper and information about other persons drawing the crypto-asset white paper pursuant to Article 6(1), second subparagraph, of Regulation (EU) 2023/1114** | | |
| **C.1** | **Name** | Not applicable |
| **C.2** | **Legal form** | Not applicable |
| **C.3** | **Registered address** | Not applicable |
| **C.4** | **Head office** | Not applicable |
| **C.5** | **Registration Date** | Not applicable |
| **C.6** | **Legal entity identifier of the operator of the trading platform** | Not applicable |
| **C.7** | **Another identifier required pursuant to applicable national law** | Not applicable |
| **C.8** | **Parent Company** | Not applicable |
| **C.9** | **Reason for Crypto-Asset White Paper Preparation** | Not applicable |
| **C.10** | **Members of the Management body** | Not applicable |
| **C.11** | **Operator Business Activity** | Not applicable |
| **C.12** | **Parent Company Business Activity** | Not applicable |
| **C.13** | **Other persons drawing up the crypto-asset white paper according to Article 6(1), second subparagraph, of Regulation (EU) 2023/1114** | Not applicable |
| **C.14** | **Reason for drawing the white paper by persons referred to in Article 6(1), second subparagraph, of Regulation (EU) 2023/1114** | Not applicable |
| **Part D - Information about the crypto-asset project** | | |
| **D.1** | **Crypto-asset project name** | Spark |
| **D.2** | **Crypto-assets name** | Spark |
| **D.3** | **Abbreviation** | SPK |
| **D.4** | **Crypto-asset project description** | The Project is a DeFi protocol which emerged from Sky, previously known as MakerDAO, and serves as a 'Sky Star', a subDAO within the Sky ecosystem. It consists of three main components: SparkLend, a stablecoin lending market; Spark Savings, for earning yield on certain stablecoins; and Spark Liquidity Layer, a backend capital allocator that routes liquidity across select DeFi protocols. |
| **D.5** | **Details of all natural or legal persons involved in the implementation of the crypto-asset project** | **SPK Company, Ltd.** c/o SHRM Trustee (BVI) Ltd. Trinity Chambers PO Box 4301 Road Town, Tortola, British Virgin Islands **Spark Foundation** c/o Leeward Management Limited Suite 3119, 9 Forum Lane Camana Bay, George Town, Grand Cayman KY1-9006, Cayman Islands |
| **D.6** | **Utility Token Classification** | FALSE |
| **D.7** | **Key Features of Goods/Services for Utility Token Projects** | Not applicable |
| **D.8** | **Plans for the token** | **Rewards:** Soon after the token generation event, a portion of the Token allocation will be used for airdrops to reward early supporters of the Project as well as its early users. Tokens may also be used in the future to reward users who use the Project. **Staking in exchange for Rewards:** Token holders who stake the Token will receive protocol rewards. It is anticipated that staked Tokens will be used to secure one or more components of the Project, such as, for example, the SkyLink Bridge. Unstaking may be subject to a cooldown period. **Governance:** It is anticipated that the Token will serve as a governance token, allowing holders to help shape the future of the Project. Any governance rights granted to Token holders will be subject to the disclaimers and qualifications made in Section F.3 and Section G.3. |
| **D.9** | **Resource Allocation** | Allocated resources include technical resources from developers, legal and compliance resources from counsel, and financial resources by means of grants from Sky's DAO. |
| **D.10** | **Planned Use of Collected Funds or Crypto-Assets** | Not applicable |
| **Part E - Information about the offer to the public of crypto-assets or their admission to trading** | | |
| **E.1** | **Public Offering or Admission to trading** | ATTR |
| **E.2** | **Reasons for Public Offer or Admission to trading** | The Foundation seeks admission of the Token to trading on multiple Exchanges in order to increase the liquidity and exchangeability of the Token, facilitate more participation in governance, and increase the number of tokens staked that may secure one or more components of the Project. |
| **E.3** | **Fundraising Target** | Not applicable |
| **E.4** | **Minimum Subscription Goals** | Not applicable |
| **E.5** | **Maximum Subscription Goal** | Not applicable |
| **E.6** | **Oversubscription Acceptance** | Not applicable |
| **E.7** | **Oversubscription Allocation** | Not applicable |
| **E.8** | **Issue Price** | Not applicable |
| **E.9** | **Official currency or any other crypto-assets determining the issue price** | Not applicable |
| **E.10** | **Subscription fee** | Not applicable |
| **E.11** | **Offer Price Determination Method** | Not applicable |
| **E.12** | **Total Number of Offered/Traded Crypto-Assets** | Not applicable |
| **E.13** | **Targeted Holders** | ALL |
| **E.14** | **Holder restrictions** | The purchase of the Token from EU-regulated Exchanges will be available to all users of such Exchanges. Most trading and exchange services offered by Exchanges are open to retail holders and may be subject to the compliance requirements of the respective Exchange. The Exchanges may impose restrictions on holders of Tokens on their respective Exchanges, in accordance with applicable laws and internal policies. |
| **E.15** | **Reimbursement Notice** | Not applicable |
| **E.16** | **Refund Mechanism** | Not applicable |
| **E.17** | **Refund Timeline** | Not applicable |
| **E.18** | **Offer Phases** | Not applicable |
| **E.19** | **Early Purchase Discount** | Not applicable |
| **E.20** | **Time-limited offer** | Not applicable |
| **E.21** | **Subscription period beginning** | Not applicable |
| **E.22** | **Subscription period end** | Not applicable |
| **E.23** | **Safeguarding Arrangements for Offered Funds/Crypto-Assets** | Not applicable |
| **E.24** | **Payment Methods for Crypto-Asset Purchase** | Not applicable |
| **E.25** | **Value Transfer Methods for Reimbursement** | Not applicable |
| **E.26** | **Right of Withdrawal** | Not applicable |
| **E.27** | **Transfer of Purchased Crypto-Assets** | Not applicable |
| **E.28** | **Transfer Time Schedule** | Not applicable |
| **E.29** | **Purchaser's Technical Requirements** | Technical requirements will be specified by the Exchanges and may include the following: A compatible digital wallet or account on supported Exchange; Internet access; A device (computer or mobile) to manage digital wallet/private key and/or account on exchange to carry out transactions |
| **E.30** | **Crypto-asset service provider (CASP) name** | Not applicable |
| **E.31** | **CASP identifier** | Not applicable |
| **E.32** | **Placement form** | NTAV |
| **E.33** | **Trading Platforms name** | **OKX**: [https://www.okx.com/](https://www.okx.com/) **Binance**: [https://www.binance.com/](https://www.binance.com/) **Upbit**: [https://upbit.com/](https://upbit.com/) **Coinbase**: [https://www.coinbase.com/](https://www.coinbase.com/) **Bybit**: [https://www.bybit.com/](https://www.bybit.com/) **Gate.io**: [https://www.gate.io/](https://www.gate.io/) **Bithumb**: [https://www.bithumb.com/](https://www.bithumb.com/) **KuCoin**: [https://www.kucoin.com/](https://www.kucoin.com/) **Kraken**: [https://www.kraken.com/](https://www.kraken.com/) **Bitget**: [https://www.bitget.com/](https://www.bitget.com/) **HTX**: [https://www.htx.com/](https://www.htx.com/) **Crypto.com**: [https://crypto.com/](https://crypto.com/) **Bitvavo**: [https://bitvavo.com/](https://bitvavo.com/) **Bitkub**: [https://www.bitkub.com/](https://www.bitkub.com/) **MEXC**: [https://www.mexc.com/](https://www.mexc.com/) **Coinone**: [https://coinone.co.kr/](https://coinone.co.kr/) **Bitstamp**: [https://www.bitstamp.net/](https://www.bitstamp.net/) **Revolut**: [https://www.revolut.com/](https://www.revolut.com/) **Paribu**: [https://www.paribu.com/](https://www.paribu.com/) **Pintu**: [https://pintu.co.id/](https://pintu.co.id/) **LBank**: [https://www.lbank.info/](https://www.lbank.info/) **Bitpanda**: [https://www.bitpanda.com/](https://www.bitpanda.com/) **Ourbit**: [https://www.ourbit.com/](https://www.ourbit.com/) **Hashkey**: [https://www.hashkey.com/](https://www.hashkey.com/) **Bitfinex**: [https://www.bitfinex.com/](https://www.bitfinex.com/) **CoinDCX**: [https://coindcx.com/](https://coindcx.com/) **BTSE**: [https://www.btse.com/](https://www.btse.com/) **BitMEX**: [https://www.bitmex.com/](https://www.bitmex.com/) **XT.COM**: [https://www.xt.com/](https://www.xt.com/) **Bilaxy**: [https://www.bilaxy.com/](https://www.bilaxy.com/) **AscendEX**: [https://ascendex.com/](https://ascendex.com/) **CoinList**: [https://coinlist.co/](https://coinlist.co/) **BingX**: [https://www.bingx.com/](https://www.bingx.com/) **BitMart**: [https://www.bitmart.com/](https://www.bitmart.com/) **CoinW**: [https://www.coinw.com/](https://www.coinw.com/) **WhiteBIT**: [https://whitebit.com/](https://whitebit.com/) **Bitrue**: [https://www.bitrue.com/](https://www.bitrue.com/) **Phemex**: [https://phemex.com/](https://phemex.com/) **WazirX**: [https://wazirx.com/](https://wazirx.com/) **WOO X**: [https://woo.org/](https://woo.org/) **Poloniex**: [https://poloniex.com/](https://poloniex.com/) |
| **E.34** | **Trading Platforms Market Identifier Code (MIC)** | Not applicable |
| **E.35** | **Trading Platforms Access** | The Exchanges are accessible via their respective websites. |
| **E.36** | **Involved costs** | Not applicable |
| **E.37** | **Offer Expenses** | Not applicable |
| **E.38** | **Conflicts of Interest** | Not applicable |
| **E.39** | **Applicable law** | This white paper is being published solely for purposes of admission to trading, not an offer to the public of the Token. However, subject to mandatory applicable law, to the extent legal disputes arise in relation to the Token, such matters would likely fall under the laws of the British Virgin Islands, the jurisdiction of incorporation of the Issuer, and be subject to the courts of that jurisdiction. |
| **E.40** | **Competent court** | See Section E.39. |
| **Part F - Information about the crypto-assets** | | |
| **F.1** | **Crypto-Asset Type** | Crypto-asset other than an asset-referenced token or e-money token |
| **F.2** | **Crypto-Asset Functionality** | According to the article 3(1)(5) of MiCA, a crypto-asset is a digital representation of a value or of a right that is able to be transferred and stored electronically using distributed ledger technology or similar technology. As reminded by the European Banking Authority ("EBA"), the term 'right' should be interpreted broadly in accordance with recital (2) of MiCA. The Token qualifies as a crypto-asset within the meaning of MiCA, as it is a digital representation of the right to access the Ecosystem and participate in the Ecosystem's governance. The Token can be transferred and stored using the distributed ledger technology ("DLT"). The Token displays the following functionalities: **Staking in exchange for Rewards:** Token holders who stake the Token will receive protocol rewards. It is anticipated that staked Tokens will be used to secure one or more components of the Project. Unstaking may be subject to a cooldown period. **Governance:** It is anticipated that the Token will serve as a governance token, allowing holders to help shape the future of the Project. Any governance rights granted to Token holders will be subject to the disclaimers and qualifications made in Section F.3 and Section G.3. |
| **F.3** | **Planned Application of Functionalities** | At the time of publication of this whitepaper, the Foundation anticipates the following: the staking feature described in Section F.2 and in other parts of this whitepaper will be available for the Token holders following the Token Generation Event (***'TGE'***); and the governance feature described in Section F.2 and in other parts of this whitepaper will evolve over time by the governance community and development team. Any governance rights granted to Token holders will be subject to any rules applicable to the Project's governance, including but not limited to the Sky Atlas. |
| **A description of the characteristics of the crypto-asset, including the data necessary for classification of the crypto-asset white paper in the register referred to in Article 109 of Regulation (EU) 2023/1114, as specified in accordance with paragraph 8 of that Article** | | |
| **F.4** | **Type of white paper** | OTHR |
| **F.5** | **The type of submission** | NEWT |
| **F.6** | **Crypto-Asset Characteristics** | See Section 8. |
| **F.7** | **Commercial name or trading name** | Spark |
| **F.8** | **Website of the issuer** | Neither the Foundation nor the Issuer have a website. The website of the Project is [https://spark.fi/](https://spark.fi/) |
| **F.9** | **Starting date of offer to the public or admission to trading** | 28/05/2025 |
| **F.10** | **Publication date** | 19/05/2025 |
| **F.11** | **Any other services provided by the issuer** | Neither the Foundation nor the Issuer provide any other services not covered by Regulation (EU) 2023/1114. |
| **F.12** | **Identifier of operator of the trading platform** | Not applicable |
| **F.13** | **Language or languages of the white paper** | English |
| **F.14** | **Digital Token Identifier Code used to uniquely identify the crypto-asset or each of the several crypto assets to which the white paper relates, where available** | SPK |
| **F.15** | **Functionally Fungible Group Digital Token Identifier, where available** | Not applicable |
| **F.16** | **Voluntary data flag** | FALSE |
| **F.17** | **Personal data flag** | TRUE |
| **F.18** | **LEI eligibility** | Not available |
| **F.19** | **Home Member State** | Malta |
| **F.20** | **Host Member States** | The admission to trading of the Token is passported in the following countries: Austria Belgium Bulgaria Croatia Cyprus Czech Germany Denmark Estonia Spain Finland France Greece Hungary Iceland Ireland Italy Latvia Liechtenstein Lithuania Luxembourg Netherlands Norway Poland Portugal Romania Slovakia Slovenia Sweden |
| **Part G - Information on the rights and obligations attached to the crypto-assets** | | |
| **G.1** | **Purchaser Rights and Obligations** | The Token enables its holders to interact with the Project that operates autonomously and without the Foundation having an operative role. As a result, the Foundation, to the fullest extent permitted by applicable laws, disclaims all warranties, whether express or implied. This includes but is not limited to, implied warranties of merchantability and fitness for a particular purpose. Moreover, to the fullest extent permissible by applicable laws, the Foundation is not liable for any damages arising from the holding, use, transfer, or interactions involving Tokens and the Project. This limitation applies to all forms of damages, including direct, indirect, incidental, punitive, and consequential damages. |
| **G.2** | **Exercise of Rights and obligations** | **Governance Rights:** To exercise any governance rights which become available to Token holders, Token holders must hold the Token and timely delegate or vote with their Tokens in accordance with any rules applicable to the Project's governance at that time, including but not limited to the Sky Atlas. **Staking in exchange for Rewards:** To earn 'protocol rewards, Token holders must stake their Tokens. |
| **G.3** | **Conditions for modifications of rights and obligations** | Neither the Foundation nor the Issuer has the ability to unilaterally modify the rights or obligations attached to the Token. However, the functionalities or rights attaching to the Token may be affected by changes made to the Project by the governance community and development team. These protocol-level changes may impact on the ways in which the Token can be used. Holders are encouraged to monitor official protocol channels for updates, including but not limited to the Project's website ([https://spark.fi/](https://spark.fi/)). |
| **G.4** | **Future Public Offers** | The Issuer does not intend to offer the Token to the public in the future. |
| **G.5** | **Issuer Retained Crypto-Assets** | 0 |
| **G.6** | **Utility Token Classification** | FALSE |
| **G.7** | **Key Features of Goods/Services of Utility Tokens** | Not applicable |
| **G.8** | **Utility Tokens Redemption** | No redemption |
| **G.9** | **Non-Trading request** | TRUE |
| **G.10** | **Crypto-Assets purchase or sale modalities** | Not applicable |
| **G.11** | **Crypto-Assets Transfer Restrictions** | The Exchanges may impose restrictions on holders of Tokens on their respective Exchanges, in accordance with applicable laws and internal policies. Token holders who acquire the Token through "private sales" are subject to restrictions as per the terms of sale. |
| **G.12** | **Supply Adjustment Protocols** | Sky governance will control the Token's mint and burn functionality. Therefore, modifications to the Token's supply can only occur via a vote of Sky governance. |
| **G.13** | **Supply Adjustment Mechanisms** | See Section G.12. |
| **G.14** | **Token Value Protection Schemes** | Not applicable |
| **G.15** | **Token Value Protection Schemes Description** | FALSE |
| **G.16** | **Compensation Schemes** | FALSE |
| **G.17** | **Compensation Schemes Description** | Not applicable |
| **G.18** | **Applicable law** | Subject to mandatory applicable law, to the extent legal disputes arise in relation to the Token, such matters would likely fall under the laws of the British Virgin Islands, the jurisdiction of incorporation of the Issuer, and be subject to the courts of that jurisdiction. |
| **G.19** | **Competent court** | See Section G.18. |
| **Part H – Information on the underlying technology** | | |
| **H.1** | **Distributed ledger technology** | The Token will be launched on the Ethereum blockchain. |
| **H.2** | **Protocols and technical standards** | The Token will be launched on the Ethereum blockchain under the ERC-20 standard to guarantee industry-standard compatibility. |
| **H.3** | **Technology Used** | As an ERC-20 token, the Token will be deployed as a smart contract on the Ethereum blockchain. Users can manage the Token through their own non-custodial wallet software provided by third parties or by directly interacting with the Token's smart contract through a third-party API. |
| **H.4** | **Consensus Mechanism** | The Token will be launched on the Ethereum blockchain, which relies on a Proof of Stake ("PoS") consensus mechanism. In Ethereum's PoS consensus mechanism, validators are randomly selected to propose and attest to blocks. To participate as an Ethereum validator, they must stake at least 32 ETH and run the software established for that end. |
| **H.5** | **Incentive Mechanisms and Applicable Fees** | Validators are compensated with ETH in exchange for proposing and attesting to proposed blocks. Their compensation is sourced from a portion of transaction fees and a block reward. If validators misbehave, they will be penalised with slashing, involving losing part of their staked ETH. Every Ethereum transaction requires the payment of gas fees. Since the implementation of EIP-1559, the fee is split into two components: **Base fee:** Automatically calculated based on network demand and is burned (removed from circulation), and **Priority fee (or tip):** Paid to the validator for including the transaction in a proposed block. The priority fee is earned by the validator that proposed the block in which the transaction is included. |
| **H.6** | **Use of Distributed Ledger Technology** | FALSE |
| **H.7** | **DLT Functionality Description** | Not applicable |
| **H.8** | **Audit** | FALSE |
| **H.9** | **Audit outcome** | Not applicable |
| **Part J – Information on the sustainability indicators in relation to adverse impact on the climate and other environment-related adverse impacts** | | |
| **J.01** | **Name** | Spark Foundation |
| **J.02** | **Relevant legal entity identifier** | Not available |
| **J.03** | **Name of the crypto-asset** | SPK |
| **J.04** | **Consensus Mechanism** | The Token will be launched on the Ethereum blockchain, which relies on a PoS consensus mechanism. In Ethereum's PoS consensus mechanism, validators are randomly selected to propose and attest to blocks. To participate as an Ethereum validator, they must stake at least 32 ETH and run the software established for that end. |
| **J.05** | **Incentive Mechanisms and Applicable Fees** | Validators are compensated with ETH in exchange for proposing and attesting to proposed blocks. Their compensation is sourced from a portion of transaction fees and a block reward. If validators misbehave, they will be penalised with slashing, involving losing part of their staked ETH. Every Ethereum transaction requires the payment of gas fees. Since the implementation of EIP-1559, the fee is split into two components: **Base fee:** Automatically calculated based on network demand and is burned (removed from circulation), and **Priority fee (or tip):** Paid to the validator for including the transaction in a proposed block. The priority fee is earned by the validator that proposed the block in which the transaction is included. |
| **J.06** | **Beginning of the Period to which the Disclosed Information Relates** | 03/03/2024 |
| **J.07** | **End of the Period to which the Disclosed Information Relates** | 03/03/2025 |
| **Mandatory key indicator on energy consumption** | | |
| **J.08** | **Energy Consumption** | 6,049,441.70 kWh |
| **Sources and methodologies** | | |
| **J.09** | **Energy Consumption Sources and Methodologies** | The estimated energy consumption provided in Section J.08 has been calculated using the CCRI Crypto Sustainability Metrics provided by the Crypto Carbon Ratings Institute (source: [https://indices.carbon-ratings.com/](https://indices.carbon-ratings.com/)). Since the Token has not yet been created, the energy consumption pertains to the previous calendar year, as an estimate of what can be consumed during the Token's first year by the Ethereum blockchain. |
| 0 | Table of content | Date of notification Statement in accordance with Article 6(3) of Regulation (EU) 2023/1114 Compliance statement in accordance with Article 6(6) of Regulation (EU) 2023/1114 Statement in accordance with Article 6(5), points (a), (b), (c) of Regulation (EU) 2023/1114 Statement in accordance with Article 6(5), point (d) of Regulation (EU) 2023/1114 Statement in accordance with Article 6(5), points (e) and (f) of Regulation (EU) 2023/1114 SUMMARY Warning in accordance with Article 6(7), second subparagraph of Regulation (EU) 2023/1114 Characteristics of the crypto-asset Key information about the offer to the public or admission to trading Part I – Information on risks Offer-Related Risks Issuer-Related Risks Crypto-Assets-related Risks Project Implementation-Related Risks Technology-Related Risks Mitigation measures Part A - Information about the offeror or the person seeking admission to trading Name Legal form Registered address Head office Registration Date Legal entity identifier Another identifier required pursuant to applicable national law Contact telephone number E-mail address Response Time (Days) Parent Company Members of the Management body Business Activity Parent Company Business Activity Newly Established Financial condition for the past three years Financial condition since registration Part B - Information about the issuer, if different from the offeror or person seeking admission to trading Issuer different from offeror or person seeking admission to trading Name Legal form Registered address Head office Registration Date Legal entity identifier Another identifier required pursuant to applicable national law Parent Company Members of the Management body Business Activity Parent Company Business Activity Part C - Information about the operator of the trading platform in cases where it draws up the crypto-asset white paper and information about other persons drawing the crypto-asset white paper pursuant to Article 6(1), second subparagraph, of Regulation (EU) 2023/1114 Name Legal form Registered address Head office Registration Date Legal entity identifier of the operator of the trading platform Another identifier required pursuant to applicable national law Parent Company Reason for Crypto-Asset White Paper Preparation Members of the Management body Operator Business Activity Parent Company Business Activity Other persons drawing up the crypto-asset white paper according to Article 6(1), second subparagraph, of Regulation (EU) 2023/1114 Reason for drawing the white paper by persons referred to in Article 6(1), second subparagraph, of Regulation (EU) 2023/1114 Part D - Information about the crypto-asset project Crypto-asset project name Crypto-assets name Abbreviation Crypto-asset project description Details of all natural or legal persons involved in the implementation of the crypto-asset project Utility Token Classification Key Features of Goods/Services for Utility Token Projects Plans for the token Resource Allocation Planned Use of Collected Funds or Crypto-Assets Part E - Information about the offer to the public of crypto-assets or their admission to trading Public Offering or Admission to trading Reasons for Public Offer or Admission to trading Fundraising Target Minimum Subscription Goals Maximum Subscription Goal Oversubscription Acceptance Oversubscription Allocation Issue Price Official currency or any other crypto-assets determining the issue price Subscription fee Offer Price Determination Method Total Number of Offered/Traded Crypto-Assets Targeted Holders Holder restrictions Reimbursement Notice Refund Mechanism Refund Timeline Offer Phases Early Purchase Discount Time-limited offer Subscription period beginning Subscription period end Safeguarding Arrangements for Offered Funds/Crypto-Assets Payment Methods for Crypto-Asset Purchase Value Transfer Methods for Reimbursement Right of Withdrawal Transfer of Purchased Crypto-Assets Transfer Time Schedule Purchaser's Technical Requirements Crypto-asset service provider (CASP) name CASP identifier Placement form Trading Platforms name Trading Platforms Market Identifier Code (MIC) Trading Platforms Access Involved costs Offer Expenses Conflicts of Interest Applicable law Competent court Part F - Information about the crypto-assets Crypto-Asset Type Crypto-Asset Functionality Planned Application of Functionalities A description of the characteristics of the crypto-asset, including the data necessary for classification of the crypto-asset white paper in the register referred to in Article 109 of Regulation (EU) 2023/1114, as specified in accordance with paragraph 8 of that Article Type of white paper The type of submission Crypto-Asset Characteristics Commercial name or trading name Website of the issuer Starting date of offer to the public or admission to trading Publication date Any other services provided by the issuer Identifier of operator of the trading platform Language or languages of the white paper Digital Token Identifier Code used to uniquely identify the crypto-asset or each of the several crypto assets to which the white paper relates, where available Functionally Fungible Group Digital Token Identifier, where available Voluntary data flag Personal data flag LEI eligibility Home Member State Host Member States Part G - Information on the rights and obligations attached to the crypto-assets Purchaser Rights and Obligations Exercise of Rights and obligations Conditions for modifications of rights and obligations Future Public Offers Issuer Retained Crypto-Assets Utility Token Classification Key Features of Goods/Services of Utility Tokens Utility Tokens Redemption Non-Trading request Crypto-Assets purchase or sale modalities Crypto-Assets Transfer Restrictions Supply Adjustment Protocols Supply Adjustment Mechanisms Token Value Protection Schemes Token Value Protection Schemes Description Compensation Schemes Compensation Schemes Description Applicable law Competent court Part H – Information on the underlying technology Distributed ledger technology Protocols and technical standards Technology Used Consensus Mechanism Incentive Mechanisms and Applicable Fees Use of Distributed Ledger Technology DLT Functionality Description Audit Audit outcome Part J – Information on the sustainability indicators in relation to adverse impact on the climate and other environment-related adverse impacts Name Relevant legal entity identifier Name of the crypto-asset Consensus Mechanism Incentive Mechanisms and Applicable Fees Beginning of the Period to which the Disclosed Information Relates End of the Period to which the Disclosed Information Relates Mandatory key indicator on energy consumption Energy Consumption Sources and methodologies Energy Consumption Sources and Methodologies |
| :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------ | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **1** | **Date of notification** | 2025-05-23 |
| **2** | **Statement in accordance with Article 6(3) of Regulation (EU) 2023/1114** | This crypto-asset white paper has not been approved by any competent authority in any Member State of the European Union. The person seeking admission of trading of the crypto-asset is solely responsible for the content of this crypto-asset white paper. |
| **3** | **Compliance statement in accordance with Article 6(6) of Regulation (EU) 2023/1114** | This crypto-asset white paper complies with Title II of Regulation (EU) 2023/1114 and, to the best of the knowledge of the management body, the information presented in the crypto-asset white paper is fair, clear and not misleading and the crypto-asset white paper makes no omission likely to affect its import. |
| **4** | **Statement in accordance with Article 6(5), points (a), (b), (c) of Regulation (EU) 2023/1114** | The crypto-asset referred to in this white paper may lose its value in part or in full, may not always be transferable and may not be liquid. |
| **5** | **Statement in accordance with Article 6(5), point (d) of Regulation (EU) 2023/1114** | FALSE |
| **6** | **Statement in accordance with Article 6(5), points (e) and (f) of Regulation (EU) 2023/1114** | The crypto-asset referred to in this white paper is not covered by the investor compensation schemes under Directive 97/9/EC of the European Parliament and of the Council.The crypto-asset referred to in this white paper is not covered by the deposit guarantee schemes under Directive 2014/49/EU of the European Parliament and of the Council. |
| **SUMMARY** | | |
| **7** | **Warning in accordance with Article 6(7), second subparagraph of Regulation (EU) 2023/1114** | Warning
This summary should be read as an introduction to the crypto-asset white paper. The prospective holder should base any decision to purchase this crypto-asset on the content of the crypto-asset white paper as a whole and not on the summary alone.
The admission to trading of this crypto-asset does not constitute an offer or solicitation to purchase financial instruments and any such offer or solicitation can be made only by means of a prospectus or other offer documents pursuant to the applicable national law.
This crypto-asset white paper does not constitute a prospectus as referred to in Regulation (EU) 2017/1129 of the European Parliament and of the Council (36) or any other offer document pursuant to Union or national law. |
| **8** | **Characteristics of the crypto-asset** | SPK (the "***Token***") will be launched as an ERC-20 token on the Ethereum blockchain. The Token will provide its holders with a set of rights within Spark (the "***Project***"), a decentralised finance application. Holders of SPK may be entitled to participate in decentralised governance, access staking mechanisms, or engage in incentive-based activities, subject to eligibility criteria and the availability of such functionalities. All such rights are exercised through the Project or associated interfaces, or direct interaction with the blockchain, using a self-custodied blockchain wallet.
It is anticipated that the Token will serve as a governance token, allowing holders to help shape the future of the Project. Any governance rights granted to Token holders will be subject to the disclaimers and qualifications made in Section F.3 and Section G.3. The exercise of rights requires active engagement by the holder and may involve network transaction fees (gas fees) payable to the Ethereum blockchain. SPK token holders are responsible for maintaining access to their wallet and acting in accordance with the Spark protocol. |
| **09** | | Not applicable |
| **10** | **Key information about the offer to the public or admission to trading** | Spark Foundation (the "***Foundation***") seeks admission of the Token to trading on multiple trading platforms (the "***Exchanges***") in order to increase the liquidity and exchangeability of the Token, facilitate more participation in governance, and increase the number of tokens staked that may secure one or more components of the Project. |
| **Part I – Information on risks** | | |
| **I.1** | **Offer-Related Risks** | The Foundation neither operates, controls, oversees, nor manages the functioning of the Exchanges where the Token will be admitted. Additionally, the Token's underlying protocol and governance structure may evolve due to ongoing technical, regulatory, and industry developments. Unforeseen risks may arise, and new challenges or opportunities may necessitate changes in the Project's strategies, goals, and structure. The risks outlined below highlight regulatory uncertainty, liquidity limitations, governance risks, network centralisation concerns, security vulnerabilities, and potential adjustments to fees or token supply that could impact the offer and trading of the Token.
**Regulatory Compliance Risks**: Evolving regulatory landscapes could impact the Token's classification, trading status, or market acceptance. Changes in regulatory requirements may necessitate modifications to the Project's operation, structure, or governance. **Market Volatility**: The Token may be subject to extreme price fluctuations, influenced by speculation, market sentiment, and broader industry trends. External factors, such as regulatory announcements or technological developments, may further contribute to volatility, potentially leading to financial losses for holders. **Liquidity Risks**: The ability to buy and sell Tokens depends on trading activity on decentralised exchanges ("***DEXs***") and, if applicable, centralised exchanges ("***CEXs***"). Limited liquidity may result in difficulties executing large trades without significant price impact, increasing the risk of loss. **Risk of Trading Platforms**: When Token holders trade on Exchanges, neither the Issuer nor the Foundation acts as a contractual party to these transactions. All legal relationships regarding these trading platforms are subject to their respective terms and conditions, with no responsibility assumed by the Foundation for their operations, services, or outcomes. **Risk of Delisting**: There is no guarantee that the Token will remain listed on any exchange. Delisting could significantly hinder the ability to trade Tokens, reducing liquidity and market value. **Risk of Bankruptcy**: The Exchanges or trading platforms where the Token is listed may become insolvent or cease operations, potentially resulting in a loss of access to funds or Tokens. **Blockchain and Smart Contract Dependency**: The Token relies entirely on its blockchain infrastructure. Any network downtime, congestion, security vulnerabilities, or smart contract failures could negatively impact its functionality, accessibility, or security. **Governance and Economic Model Risks**: While no inflationary events are currently anticipated, Sky governance will retain the power to mint new Tokens in the future. **Legal Risks**: Uncertainties in legal frameworks, regulatory changes, potential lawsuits, or adverse legal rulings could pose significant risks, affecting the value of the Token. **Reputational Risks**: Negative publicity – whether due to operational failures, security breaches, or associations with illicit activities—could damage the Project's reputation and, by extension, impact the value and acceptance of the Token. **Technology Management Risks**: Inadequate management of technological updates or failure to keep pace with advancements may result in security vulnerabilities, inefficiencies, or obsolescence of the Token and its supporting infrastructure. **Concentration and Conflicts of Interest**: Concentration of Token holdings may lead to governance decisions that favour the interests of one or more specific holders rather than the interests of the community, potentially affecting the value of the Token. **Decentralised Governance Risk**: The majority of the Token supply will be managed by decentralised governance, including Sky governance and Spark governance. Risks associated with decentralised governance, including without limitation the risk of capture, may negatively impact the value of the Token. **Industry Competition Risks**: The Project faces competition from other projects, including larger and well-funded ventures that may attract more users and liquidity, potentially diminishing the viability of the Token. **Unanticipated Risks**: There may be additional risks that cannot be foreseen. Some risks may materialise as unexpected variations or combinations of the factors discussed in this section. |
| **I.2** | **Issuer-Related Risks** | The Issuer's sole function is to issue and distribute the Tokens. It does not manage or operate any technical infrastructure, oversee governance processes, or maintain control over the protocol or community.
**Operational Risk**: This limited operational role means the Issuer cannot respond to technical failures, governance disputes, or security incidents within the broader ecosystem. If issues arise post-distribution such as bugs in smart contracts or shifts in network governance, the Issuer has no authority or capacity to intervene or implement corrective measures. **Decentralized Governance Risk**: Furthermore, all post-distribution developments depend on decentralised community governance or third-party contributors, over whom the Issuer has no influence. Participants should therefore understand that their reliance on the Issuer is limited strictly to the issuance of the Tokens. Any expectations beyond that, whether technical, economic, or governance-related, must be assessed based on the broader ecosystem's operations and risks. |
| **I.3** | **Crypto-Assets-related Risks** | **Market Volatility Risks**: It is anticipated that the Token's value will be highly volatile and may fluctuate due to market speculation, investor sentiment, regulatory developments, and technological advancements. External factors, such as shifting trends in the crypto industry, changes in demand for blockchain services, or macroeconomic conditions, could contribute to extreme price fluctuations, potentially leading to total depreciation. **Liquidity Risks**: The ability to trade the Token depends on the level of activity on DEXs and, where applicable, CEXs. Low trading volume may result in difficulties executing large transactions without significant price impact. Limited demand for the Token or the underlying protocol may further reduce liquidity, making it difficult to acquire or sell the Token. **Adoption and Project Demand Risks**: The long-term success of the Token is dependent on widespread adoption of the Project. Adoption is influenced by various external factors, including user demand, competitive market conditions, and organic community-driven expansion. The Foundation has no control over the pace of adoption, and there is no guarantee that the Project will gain sufficient traction to sustain its economic model. **Blockchain Dependency Risks**: The Token operates exclusively on its underlying blockchain network. Any disruptions, such as network congestion, downtime, or security vulnerabilities, could impact the ability to transfer, store, or trade the Token. Changes to blockchain infrastructure, governance, or transaction fees may also influence the Token's usability and cost-effectiveness. **Transaction Costs:** While blockchain fees are generally low, network congestion, high demand, or changes in blockchain fee structures may increase transaction costs, potentially reducing the economic viability of using the Token. **Security Risks**: ***Smart Contract Vulnerabilities***: Despite security audits and best practices, unforeseen vulnerabilities in smart contracts could lead to security breaches, impacting Token security or functionality. ***Private Key Management***: Token holders are solely responsible for safeguarding their private keys and recovery phrases. Loss of wallet credentials will result in the permanent loss of Tokens, as blockchain transactions are irreversible. **Scam and Fraud Risks**: Token holders are exposed to risks associated with scams, phishing attacks, fake giveaways, impersonation of the Foundation or its team, counterfeit Tokens, and fraudulent airdrops. Engaging with unverified third-party platforms or unofficial communications increases the risk of fraud. **Community and Narrative Risks**: The Token's success is closely tied to community interest and the broader crypto narrative. Market trends, emerging competitors, or declining community engagement may negatively impact the Token's perceived value and adoption. **Regulatory and Compliance Risks**: ***Evolving Legal Frameworks***: Regulations governing crypto-assets differ across jurisdictions and are subject to change. New legal requirements may impact the Token's classification, availability, or functionality. ***Jurisdictional Restrictions***: Some jurisdictions may impose restrictions or prohibitions on the trading or use of the Token, limiting its accessibility for certain users. **Technological Obsolescence Risks**: The blockchain and crypto industries evolve rapidly. The emergence of new technologies, changes in market demand, or advancements in competing protocols could render the Token or its underlying blockchain infrastructure less competitive, reducing adoption and utility. **Software Weakness Risks**: The Token's infrastructure relies on relatively new blockchain technologies, which may contain undiscovered bugs, vulnerabilities, or inefficiencies. There is no guarantee that the process of transacting, storing, or interacting with the Token will be uninterrupted or error-free. **Unanticipated Risks**: Beyond the risks outlined above, additional unforeseen risks may emerge due to changes in regulatory, technological, or market conditions, potentially affecting the Token's security, functionality, or value. |
| **I.4** | **Project Implementation-Related Risks** | The Foundation neither operates, controls, oversees, nor manages the technology underlying the Project. While efforts are made to ensure security and stability, blockchain-based technologies are still evolving, and various risks exist. Additionally, the success and sustainability of the Project rely on various external factors, including market conditions, regulatory developments, and technological advancements.
**Technical Development Risks**: ***Smart Contract Issues***: Despite robust security measures, unforeseen vulnerabilities or bugs in the smart contracts could disrupt Token distribution, refunds, or vesting mechanisms.
***Blockchain Dependency***: The Token operates exclusively on its underlying blockchain. Any network congestion, downtime, or security breaches could impact the Project's implementation and functionality. ***Risk of Security Weaknesses in Core Infrastructure***: The Project relies on open-source software, which may be modified by third parties. Weaknesses or bugs introduced into the core infrastructure could compromise security and lead to the loss of digital assets. Furthermore, malfunctions or inadequate maintenance of the Project may negatively impact the Token's usability. ***Bugs in Core Blockchain Code***: Even with rigorous testing, unknown bugs may exist in the blockchain protocol, potentially leading to disruptions, incorrect transaction processing, or security vulnerabilities. **Regulatory and Compliance Risks:** ***Regulatory Actions in One or More Jurisdictions***: The Token and the underlying Project could be impacted by regulatory inquiries or actions, which may restrict further development, implementation, or usage. ***Evolving Laws and Regulations***: New and changing laws related to financial securities, consumer protection, data privacy, cybersecurity, and intellectual property could impact the Project and the Token. ***Governance Risk***: Decision-making mechanisms in blockchain governance may be inefficient, slow, or disproportionately influenced by specific stakeholders, leading to potential centralisation or unfavourable governance outcomes. **Operational Risks**: ***Resource Allocation***: The Project's success depends on the team allocating sufficient resources (both financial and non-financial) to ensure timely development and deployment. Poor resource management could lead to delays or failure to achieve key milestones. **Market Adoption Risks**: ***Competitive Environment***: The crypto-asset market is highly competitive and trend-driven. There is a risk that the Token may fail to capture sufficient interest, limiting its adoption. ***Community Engagement Risks***: The success of the Token depends heavily on community-driven marketing and engagement. Failure to build or sustain an active community could hinder growth and long-term tradability. **Timeline and Milestone Risks**: ***Delayed Milestones***: Key milestones may face delays due to technical, operational, or funding challenges. ***CEX Listing Risks***: Listings on centralised exchanges depend on securing the necessary funding for listing fees and meeting platform-specific requirements. Delays or insufficient resources could postpone broader market access. **Ecosystem Risks**: ***Dependence on External Parties***: The Project relies on infrastructure providers and other third-party service providers. Any failure or delay from third-parties could disrupt implementation plans. **Technology and Software Risks**: ***Risk of Software Weakness***: Blockchain and smart contract technologies are still evolving. There is no guarantee that Token usage will be uninterrupted or error-free. Vulnerabilities in the underlying blockchain, smart contracts, or supporting technologies could lead to the complete loss of Tokens or their functionality. ***Dependency on Underlying Technology***: The Project relies on blockchain infrastructure, hardware, and network connectivity, all of which may be subject to failures, outages, or vulnerabilities. ***Risk of Technological Disruption***: The emergence of new technology, such as quantum computing, could undermine the security of blockchain encryption and compromise the integrity of digital assets. **Network Security Risks**: ***Network Attacks and Cybersecurity Threats***: Blockchain networks can be vulnerable to cyberattacks such as 51% attacks, Sybil attacks, or distributed denial-of-service ("***DDoS***") attacks. These threats could disrupt network operations and compromise security. ***Blockchain Network Attacks***: The Network may be subject to mining attacks, including double-spend attacks, reorganisations, majority mining power attacks, "selfish-mining" attacks, and work race condition attacks. Successful attacks could compromise the proper execution of transactions and smart contracts. **Privacy and Anonymity Risks**: ***Public Ledger Transparency***: Blockchain transactions are recorded on a public ledger, which may expose transaction history and financial activity. Certain transactions could be linked to specific wallet addresses, making users vulnerable to fraud, phishing attacks, or targeted scams. **Economic and Governance Risks**: ***Incentive Model Risks***: Governance decisions could result in modifications that impact Token holders, including inflationary adjustments, transaction fees, or redistribution of rewards. **Software Weakness Risks**: ***Unforeseen Bugs and Security Vulnerabilities***: The Token and its supporting infrastructure rely on blockchain technologies that may still be evolving. There is no guarantee that Token transactions will be uninterrupted or error-free. Software vulnerabilities, weaknesses in smart contracts, or infrastructure issues may result in loss of assets, security breaches, or unexpected network failures. **Unanticipated Risks**: ***Unforeseen Regulatory, Technological, or Market Challenges***: In addition to the risks identified, new threats may emerge due to changes in legal, technological, or economic conditions. Developments such as regulatory actions, unforeseen Project vulnerabilities, or disruptive innovations could impact the usability, security, or value of the Token in ways not currently foreseeable. |
| **I.5** | **Technology-Related Risks** | The Foundation neither operates, controls, oversees, nor manages the technology underlying the Project. While efforts are made to ensure security and stability, blockchain-based technologies are still evolving, and various risks exist. **Blockchain Dependency Risks**: ***Network Downtime and Congestion***: The Token relies entirely on its underlying blockchain network, which may experience outages, congestion, or downtime. Such events could disrupt Token transfers, trading, or other functionalities. ***Scalability Challenges***: As transaction volume grows, the blockchain network may face scaling limitations. Increased congestion could lead to slower transaction processing times and higher fees, reducing efficiency and usability. ***Settlement and Transaction Finality Risks***: Blockchain transactions are designed to be irreversible; however, under exceptional circumstances such as network forks or consensus failures, there remains a theoretical risk that transactions could be reversed or multiple competing ledger versions could persist. Transactions sent to an incorrect address are not recoverable, leading to permanent loss of assets. **Smart Contract Risks**: ***Immutability Risks***: Once deployed, some smart contracts cannot be altered. Errors or security flaws in the code could result in operational failures without the possibility of corrections. ***Security Exploits***: Bugs or vulnerabilities in smart contracts may expose the Token ecosystem to potential hacks, allowing attackers to manipulate transactions, drain liquidity, or disrupt contract execution. **Wallet and Storage Risks**: ***Private Key Management***: Token holders are solely responsible for securing their private keys and recovery phrases. The loss of private keys results in irreversible loss of Tokens, as blockchain transactions are final and cannot be undone. ***Compatibility Issues***: The Token is supported only by blockchain-compatible wallets. Incompatibility with specific wallet software, network malfunctions, or wallet provider shutdowns may affect access to and usability of the Token. **Ecosystem Dependency Risks**: ***DEX and CEX Integration Issues***: The Token's availability depends on integration with DEXs and CEXs. Technical failures, security breaches, or de-listings from these platforms could limit liquidity, disrupt trading, and reduce market accessibility. ***Reliance on Third-Party Services***: Many blockchain services, including wallets, bridges, and oracles, depend on third-party providers. Failures, security breaches, or regulatory actions against these services could negatively affect the functionality of the Token. **Software and Project Risks**: ***Risk of Attacks and Forks***: The underlying blockchain may be susceptible to consensus-related attacks, such as double-spend attacks, majority validation power takeovers, censorship attacks, or forks. These risks could affect Token transactions, balance integrity, and overall network security. ***Risk of Technological Disruption***: Emerging technologies, such as quantum computing, could potentially compromise blockchain encryption, making networks vulnerable to attacks that could compromise data integrity or enable unauthorised asset transfers. ***Dependency on Underlying Technology***: The stability of the Token ecosystem relies on underlying technical infrastructures, including internet connectivity, computing hardware, and cryptographic algorithms. Disruptions in these foundational technologies may impact network security and operational efficiency. ***Unforeseen Vulnerabilities in Blockchain***: The Token and its supporting infrastructure rely on blockchain technologies that may still be evolving. There is no guarantee that Token transactions will be uninterrupted or error-free. Software vulnerabilities, weaknesses in smart contracts, or infrastructure issues may result in loss of assets, security breaches, or unexpected network failures. **Privacy and Anonymity Risks**: ***Public Ledger Transparency***: Blockchain transactions are recorded on a publicly accessible ledger, which may expose sensitive transaction data. While addresses do not directly reveal identities, sophisticated data analysis could potentially link certain transactions to specific individuals or entities. ***Exposure to Fraud and Targeted Attacks***: Increased transparency may lead to risks such as phishing, fraud, or unauthorised tracking of user activity by malicious actors. Individuals with significant Token holdings may be targeted for scams or social engineering attacks. **Economic and Project Viability Risks**: ***Incentive Model Risks***: Governance proposals may introduce modifications that impact Token holders, including inflation adjustments, transaction fees, or changes to rewards. **Unanticipated Risks**: ***Unforeseen Regulatory, Technological, or Market Challenges***: In addition to the risks identified, new threats may emerge due to changes in legal, technological, or economic conditions. Developments such as regulatory actions, unforeseen Project vulnerabilities, or disruptive innovations could impact the usability, security, or value of the Token in ways not currently foreseeable. |
| **I.6** | **Mitigation measures** | To address the range of risks associated with the Token, the Project has implemented multiple mitigation strategies across technical, operational, and governance layers.
Smart Contract Audits: All critical smart contracts are subject to external audits by reputable security firms. Audits help identify vulnerabilities before deployment and reduce the likelihood of exploitation. Previous audits are accessible at [http://docs.spark.fi/dev/security/security-and-audits](http://docs.spark.fi/dev/security/security-and-audits). Progressive rollout: The Token distribution and product features are introduced gradually to allow for testing and feedback, minimising systemic risk and improving resilience. Decentralised Governance: The Token's governance is structured through community mechanisms, including SparkDAO and SkyDAO governance. This provides checks and balances, limits centralised control, and enables dynamic adaptation to new risks. Transparent communication: Ongoing disclosures via public documentation, white paper updates, forums, and governance proposals foster community awareness and help participants make informed decisions. Liquidity support and listings: While no guarantee is provided, the Issuer and the Foundation may collaborate with market participants to encourage liquidity provision and exchange listings where feasible. Regulatory Alignment: The Project tracks legal developments in key jurisdictions to align with regulatory frameworks, particularly those under MiCA.
These measures do not eliminate risk, but they significantly reduce the likelihood or severity of adverse events. Participants should still exercise caution and adopt personal risk management strategies when engaging with the Tokens or the broader Spark ecosystem. |
| **Part A - Information about the offeror or the person seeking admission to trading** | | |
| **A.1** | **Name** | Spark Foundation |
| **A.2** | **Legal form** | Foundation company limited by guarantee without share capital |
| **A.3** | **Registered address** | Leeward Management Limited, Suite 3119, 9 Forum Lane, Camana Bay, PO Box 144, George Town, Grand Cayman KY1-9006, Cayman Islands |
| **A.4** | **Head office** | Leeward Management Limited, Suite 3119, 9 Forum Lane, Camana Bay, PO Box 144, George Town, Grand Cayman KY1-9006, Cayman Islands |
| **A.5** | **Registration Date** | 2025-02-05 |
| **A.6** | **Legal entity identifier** | Not available |
| **A.7** | **Another identifier required pursuant to applicable national law** | 418210 |
| **A.8** | **Contact telephone number** | 001 345-749-9601 |
| **A.9** | **E-mail address** | Glenn Kennedy: [gkennedy@leewardmanagement.ky](mailto\:gkennedy@leewardmanagement.ky) Marc Piano: [piano@horizonsglobal.io](mailto\:piano@horizonsglobal.io) |
| **A.10** | **Response Time (Days)** | Fourteen (14) days |
| **A.11** | **Parent Company** | Not applicable |
| **A.12** | **Members of the Management body** | **Glenn Kennedy** Director Leeward Management Limited, Suite 3119, 9 Forum Lane, Camana Bay, PO Box 144, George Town, Grand Cayman KY1-9006, Cayman Islands
**Marc Piano** Director Leeward Management Limited, Suite 3119, 9 Forum Lane, Camana Bay, PO Box 144, George Town, Grand Cayman KY1-9006, Cayman Islands |
| **A.13** | **Business Activity** | To support, promote, and advance the development, adoption, security, and growth of Spark. |
| **A.14** | **Parent Company Business Activity** | Not applicable |
| **A.15** | **Newly Established** | TRUE |
| **A.16** | **Financial condition for the past three years** | Not applicable |
| **A.17** | **Financial condition since registration** | The Foundation will be capitalised as needed to fulfil its mandate of supporting the Spark ecosystem. It has no debt and being a brand new company, should have no material liabilities as of the date of this whitepaper. |
| **Part B - Information about the issuer, if different from the offeror or person seeking admission to trading** | | |
| **B.1** | **Issuer different from offeror or person seeking admission to trading** | TRUE |
| **B.2** | **Name** | SPK Company Ltd. |
| **B.3** | **Legal form** | Company limited by shares |
| **B.4** | **Registered address** | SHRM Trustees (BVI) Limited of Trinity Chambers, PO Box 4301, Road Town, Tortola, British Virgin Islands |
| **B.5** | **Head office** | SHRM Trustees (BVI) Limited of Trinity Chambers, PO Box 4301, Road Town, Tortola, British Virgin Islands |
| **B.6** | **Registration Date** | 2025-02-19 |
| **B.7** | **Legal entity identifier** | Not available |
| **B.8** | **Another identifier required pursuant to applicable national law** | 2170013 |
| **B.9** | **Parent Company** | Spark Foundation |
| **B.10** | **Members of the Management body** | The sole director of the Issuer is **Spark Foundation**
The directors of Spark Foundation are Glenn Kennedy and Marc Piano
Business address of Spark Foundation is Leeward Management Limited, Suite 3119, 9 Forum Lane, Camana Bay, PO Box 144, George Town, Grand Cayman KY1-9006, Cayman Islands |
| **B.11** | **Business Activity** | The only purpose is to issue and distribute the Token. |
| **B.12** | **Parent Company Business Activity** | See Section A.13. |
| **Part C - Information about the operator of the trading platform in cases where it draws up the crypto-asset white paper and information about other persons drawing the crypto-asset white paper pursuant to Article 6(1), second subparagraph, of Regulation (EU) 2023/1114** | | |
| **C.1** | **Name** | Not applicable |
| **C.2** | **Legal form** | Not applicable |
| **C.3** | **Registered address** | Not applicable |
| **C.4** | **Head office** | Not applicable |
| **C.5** | **Registration Date** | Not applicable |
| **C.6** | **Legal entity identifier of the operator of the trading platform** | Not applicable |
| **C.7** | **Another identifier required pursuant to applicable national law** | Not applicable |
| **C.8** | **Parent Company** | Not applicable |
| **C.9** | **Reason for Crypto-Asset White Paper Preparation** | Not applicable |
| **C.10** | **Members of the Management body** | Not applicable |
| **C.11** | **Operator Business Activity** | Not applicable |
| **C.12** | **Parent Company Business Activity** | Not applicable |
| **C.13** | **Other persons drawing up the crypto-asset white paper according to Article 6(1), second subparagraph, of Regulation (EU) 2023/1114** | Not applicable |
| **C.14** | **Reason for drawing the white paper by persons referred to in Article 6(1), second subparagraph, of Regulation (EU) 2023/1114** | Not applicable |
| **Part D - Information about the crypto-asset project** | | |
| **D.1** | **Crypto-asset project name** | Spark |
| **D.2** | **Crypto-assets name** | Spark |
| **D.3** | **Abbreviation** | SPK |
| **D.4** | **Crypto-asset project description** | The Project is a DeFi protocol which emerged from Sky, previously known as MakerDAO, and serves as a 'Sky Star', a subDAO within the Sky ecosystem. It consists of three main components: SparkLend, a stablecoin lending market; Spark Savings, for earning yield on certain stablecoins; and Spark Liquidity Layer, a backend capital allocator that routes liquidity across select DeFi protocols. |
| **D.5** | **Details of all natural or legal persons involved in the implementation of the crypto-asset project** | **SPK Company, Ltd.** c/o SHRM Trustee (BVI) Ltd. Trinity Chambers PO Box 4301 Road Town, Tortola, British Virgin Islands
**Spark Foundation** c/o Leeward Management Limited Suite 3119, 9 Forum Lane Camana Bay, George Town, Grand Cayman KY1-9006, Cayman Islands |
| **D.6** | **Utility Token Classification** | FALSE |
| **D.7** | **Key Features of Goods/Services for Utility Token Projects** | Not applicable |
| **D.8** | **Plans for the token** | **Rewards:** Soon after the token generation event, a portion of the Token allocation will be used for airdrops to reward early supporters of the Project as well as its early users. Tokens may also be used in the future to reward users who use the Project. **Staking in exchange for Rewards:** Token holders may be given the option to stake their Tokens to contribute to the network's resilience or participate in reward systems. Staking mechanisms could be linked to protocol components such as cross-chain infrastructure or security features, although specifics may evolve based on governance decisions and technical development. Staking may involve time-bound commitments, and the Foundation anticipates that rewards, if any, will reflect the level of engagement and the function being supported. **Governance:** It is anticipated that the Token will serve as a governance token, allowing holders to help shape the future of the Project. Any governance rights granted to Token holders will be subject to the disclaimers and qualifications made in Section F.3 and Section G.3. **Future Outlook:** As the the Project grows, the Tokens may become relevant in additional modules or integrations, including those related to cross-chain operations, coordination layers, or service modules. These developments will be introduced incrementally and in alignment with broader ecosystem goals. **Vision:** The vision for the Tokens is to support a sustainable, community-driven network. Its role is not fixed but is intended to reflect the evolving needs of a decentralised ecosystem prioritising fairness, resilience, and meaningful engagement. |
| **D.9** | **Resource Allocation** | Allocated resources include technical resources from developers, legal and compliance resources from counsel, and financial resources by means of grants from Sky's DAO. |
| **D.10** | **Planned Use of Collected Funds or Crypto-Assets** | Not applicable |
| **Part E - Information about the offer to the public of crypto-assets or their admission to trading** | | |
| **E.1** | **Public Offering or Admission to trading** | ATTR |
| **E.2** | **Reasons for Public Offer or Admission to trading** | The Foundation seeks admission of the Token to trading on multiple Exchanges in order to increase the liquidity and exchangeability of the Token, facilitate more participation in governance, and increase the number of tokens staked that may secure one or more components of the Project. |
| **E.3** | **Fundraising Target** | Not applicable |
| **E.4** | **Minimum Subscription Goals** | Not applicable |
| **E.5** | **Maximum Subscription Goal** | Not applicable |
| **E.6** | **Oversubscription Acceptance** | Not applicable |
| **E.7** | **Oversubscription Allocation** | Not applicable |
| **E.8** | **Issue Price** | Not applicable |
| **E.9** | **Official currency or any other crypto-assets determining the issue price** | Not applicable |
| **E.10** | **Subscription fee** | Not applicable |
| **E.11** | **Offer Price Determination Method** | Not applicable |
| **E.12** | **Total Number of Offered/Traded Crypto-Assets** | Not applicable |
| **E.13** | **Targeted Holders** | ALL |
| **E.14** | **Holder restrictions** | The purchase of the Token from EU-regulated Exchanges will be available to all users of such Exchanges. Most trading and exchange services offered by Exchanges are open to retail holders and may be subject to the compliance requirements of the respective Exchange.
The Exchanges may impose restrictions on holders of Tokens on their respective Exchanges, in accordance with applicable laws and internal policies. |
| **E.15** | **Reimbursement Notice** | Not applicable |
| **E.16** | **Refund Mechanism** | Not applicable |
| **E.17** | **Refund Timeline** | Not applicable |
| **E.18** | **Offer Phases** | Not applicable |
| **E.19** | **Early Purchase Discount** | Not applicable |
| **E.20** | **Time-limited offer** | Not applicable |
| **E.21** | **Subscription period beginning** | Not applicable |
| **E.22** | **Subscription period end** | Not applicable |
| **E.23** | **Safeguarding Arrangements for Offered Funds/Crypto-Assets** | Not applicable |
| **E.24** | **Payment Methods for Crypto-Asset Purchase** | The methods available for purchasing the Token depend on the functionality and policies of the Exchanges or other third-party platforms through which the Token is admitted to trading. Accepted payment methods may include fiat currencies, other crypto-assets, or stablecoins, subject to the configuration and offerings of each respective platform. |
| **E.25** | **Value Transfer Methods for Reimbursement** | Not applicable |
| **E.26** | **Right of Withdrawal** | Not applicable |
| **E.27** | **Transfer of Purchased Crypto-Assets** | Not applicable |
| **E.28** | **Transfer Time Schedule** | Not applicable |
| **E.29** | **Purchaser's Technical Requirements** | To access and trade the Tokens following their admission to trading, purchasers must meet certain technical requirements. These requirements are primarily determined by the centralized Exchanges where the Tokens are listed, and may include the following:
A device (computer or mobile) capable of securely accessing and operating an account on an Exchange; A stable internet connection to interact with the Exchange interface and execute transactions; The ability to receive and store Tokens within the exchange account infrastructure, as provided by the Exchange;
Where trading takes place on decentralized exchanges (DEXs), or where tokens are withdrawn to self-custodied wallets, additional technical requirements apply:
Access to a compatible digital wallet capable of interacting with the Token's blockchain (e.g., Ethereum for ERC-20 Tokens); Secure management of private keys and recovery phrases; The ability to sign transactions and pay applicable network (gas) fees on the Ethereum blockchain.
The Foundation does not provide technical infrastructure such as exchange access, custody services, or wallets. It is the responsibility of the purchaser to ensure that all relevant technical requirements are met in order to receive and transact with the Tokens. |
| **E.30** | **Crypto-asset service provider (CASP) name** | Not applicable |
| **E.31** | **CASP identifier** | Not applicable |
| **E.32** | **Placement form** | NTAV |
| **E.33** | **Trading Platforms name** | **OKX**: [https://www.okx.com/](https://www.okx.com/) **Binance**: [https://www.binance.com/](https://www.binance.com/) **Upbit**: [https://upbit.com/](https://upbit.com/) **Coinbase**: [https://www.coinbase.com/](https://www.coinbase.com/) **Bybit**: [https://www.bybit.com/](https://www.bybit.com/) **Gate.io**: [https://www.gate.io/](https://www.gate.io/) **Bithumb**: [https://www.bithumb.com/](https://www.bithumb.com/) **KuCoin**: [https://www.kucoin.com/](https://www.kucoin.com/) **Kraken**: [https://www.kraken.com/](https://www.kraken.com/) **Bitget**: [https://www.bitget.com/](https://www.bitget.com/) **HTX**: [https://www.htx.com/](https://www.htx.com/) **Crypto.com**: [https://crypto.com/](https://crypto.com/) **Bitvavo**: [https://bitvavo.com/](https://bitvavo.com/) **Bitkub**: [https://www.bitkub.com/](https://www.bitkub.com/) **MEXC**: [https://www.mexc.com/](https://www.mexc.com/) **Coinone**: [https://coinone.co.kr/](https://coinone.co.kr/) **Bitstamp**: [https://www.bitstamp.net/](https://www.bitstamp.net/) **Revolut**: [https://www.revolut.com/](https://www.revolut.com/) **Paribu**: [https://www.paribu.com/](https://www.paribu.com/) **Pintu**: [https://pintu.co.id/](https://pintu.co.id/) **LBank**: [https://www.lbank.info/](https://www.lbank.info/) **Bitpanda**: [https://www.bitpanda.com/](https://www.bitpanda.com/) **Ourbit**: [https://www.ourbit.com/](https://www.ourbit.com/) **Hashkey**: [https://www.hashkey.com/](https://www.hashkey.com/) **Bitfinex**: [https://www.bitfinex.com/](https://www.bitfinex.com/) **CoinDCX**: [https://coindcx.com/](https://coindcx.com/) **BTSE**: [https://www.btse.com/](https://www.btse.com/) **BitMEX**: [https://www.bitmex.com/](https://www.bitmex.com/) **XT.COM**: [https://www.xt.com/](https://www.xt.com/) **Bilaxy**: [https://www.bilaxy.com/](https://www.bilaxy.com/) **AscendEX**: [https://ascendex.com/](https://ascendex.com/) **CoinList**: [https://coinlist.co/](https://coinlist.co/) **BingX**: [https://www.bingx.com/](https://www.bingx.com/) **BitMart**: [https://www.bitmart.com/](https://www.bitmart.com/) **CoinW**: [https://www.coinw.com/](https://www.coinw.com/) **WhiteBIT**: [https://whitebit.com/](https://whitebit.com/) **Bitrue**: [https://www.bitrue.com/](https://www.bitrue.com/) **Phemex**: [https://phemex.com/](https://phemex.com/) **WazirX**: [https://wazirx.com/](https://wazirx.com/) **WOO X**: [https://woo.org/](https://woo.org/) **Poloniex**: [https://poloniex.com/](https://poloniex.com/) |
| **E.34** | **Trading Platforms Market Identifier Code (MIC)** | Not applicable |
| **E.35** | **Trading Platforms Access** | The Exchanges are accessible via their respective websites. |
| **E.36** | **Involved costs** | Not applicable |
| **E.37** | **Offer Expenses** | Not applicable |
| **E.38** | **Conflicts of Interest** | Not applicable |
| **E.39** | **Applicable law** | This white paper is being published solely for purposes of admission to trading, not an offer to the public of the Token. However, subject to mandatory applicable law, to the extent legal disputes arise in relation to the Token, such matters would likely fall under the laws of the British Virgin Islands, the jurisdiction of incorporation of the Issuer, and be subject to the courts of that jurisdiction. |
| **E.40** | **Competent court** | See Section E.39. |
| **Part F - Information about the crypto-assets** | | |
| **F.1** | **Crypto-Asset Type** | Crypto-asset other than an asset-referenced token or e-money token |
| **F.2** | **Crypto-Asset Functionality** | According to the article 3(1)(5) of MiCA, a crypto-asset is a digital representation of a value or of a right that is able to be transferred and stored electronically using distributed ledger technology or similar technology. As reminded by the European Banking Authority ("EBA"), the term 'right' should be interpreted broadly in accordance with recital (2) of MiCA.
The Token qualifies as a crypto-asset within the meaning of MiCA, as it is a digital representation of the right to access the Ecosystem and participate in the Ecosystem's governance. The Token can be transferred and stored using the distributed ledger technology ("DLT").
The Token displays the following functionalities:
**Rewards and Incentive Structures:** The Token is intended to support the long-term functionality, security, and decentralization of the Spark ecosystem through various incentive mechanisms. Token holders may have the opportunity to engage in network activities such as staking, which is designed to enhance protocol resilience and performance. Staking may be associated with specific components of the protocol, for example, cross-chain infrastructure or network security mechanisms, and may require time-bound commitments or minimum engagement thresholds. The Foundation anticipates that rewards, where applicable, will be designed to reflect the level and nature of participation, as determined by the parameters of the relevant mechanism. All such mechanisms, including staking terms and reward structures, remain subject to further refinement through governance processes and technical development. **Governance:** It is anticipated that the Token will serve as a governance token, allowing holders to help shape the future of the Project. Any governance rights granted to Token holders will be subject to the disclaimers and qualifications made in Section F.3 and Section G.3. Overall: The Token is designed primarily as a token for use within the Spark ecosystem, enabling holders to participate in governance, access reward and incentive programs, and interact with protocol features as they evolve over time. |
| **F.3** | **Planned Application of Functionalities** | At the time of publication of this whitepaper, the Foundation anticipates the following: the rewards and incentive structures described in Section F.2 and in other parts of this whitepaper will be made available for the Token holders progressively following the Token Generation Event ('TGE'); and the governance feature described in Section F.2 and in other parts of this whitepaper will also evolve over time by the governance community and development team. Any governance rights granted to Token holders will be subject to any rules applicable to the Project's governance, including but not limited to the Sky Atlas. |
| **A description of the characteristics of the crypto-asset, including the data necessary for classification of the crypto-asset white paper in the register referred to in Article 109 of Regulation (EU) 2023/1114, as specified in accordance with paragraph 8 of that Article** | | |
| **F.4** | **Type of white paper** | OTHR |
| **F.5** | **The type of submission** | MODI |
| **F.6** | **Crypto-Asset Characteristics** | See Section 8. |
| **F.7** | **Commercial name or trading name** | Spark |
| **F.8** | **Website of the issuer** | Neither the Foundation nor the Issuer have a website. The website of the Project is [https://spark.fi/](https://spark.fi/) |
| **F.9** | **Starting date of offer to the public or admission to trading** | 2025-05-28 |
| **F.10** | **Publication date** | 2025-06-03 |
| **F.11** | **Any other services provided by the issuer** | Neither the Foundation nor the Issuer provide any other services not covered by Regulation (EU) 2023/1114. |
| **F.12** | **Identifier of operator of the trading platform** | Not applicable |
| **F.13** | **Language or languages of the white paper** | English |
| **F.14** | **Digital Token Identifier Code used to uniquely identify the crypto-asset or each of the several crypto assets to which the white paper relates, where available** | SPK |
| **F.15** | **Functionally Fungible Group Digital Token Identifier, where available** | Not applicable |
| **F.16** | **Voluntary data flag** | FALSE |
| **F.17** | **Personal data flag** | TRUE |
| **F.18** | **LEI eligibility** | FALSE |
| **F.19** | **Home Member State** | Malta |
| **F.20** | **Host Member States** | The admission to trading of the Token is passported in the following countries: Austria Belgium Bulgaria Croatia Cyprus Czech Republic Germany Denmark Estonia Spain Finland France Greece Hungary Iceland Ireland Italy Latvia Liechtenstein Lithuania Luxembourg Netherlands Norway Poland Portugal Romania Slovakia Slovenia Sweden |
| **Part G - Information on the rights and obligations attached to the crypto-assets** | | |
| **G.1** | **Purchaser Rights and Obligations** | The Token enables its holders to interact with the Project that operates autonomously and without the Foundation having an operative role. As a result, the Foundation, to the fullest extent permitted by applicable laws, disclaims all warranties, whether express or implied. This includes but is not limited to, implied warranties of merchantability and fitness for a particular purpose. Moreover, to the fullest extent permissible by applicable laws, the Foundation is not liable for any damages arising from the holding, use, transfer, or interactions involving Tokens and the Project. This limitation applies to all forms of damages, including direct, indirect, incidental, punitive, and consequential damages. |
| **G.2** | **Exercise of Rights and obligations** | Any rights associated with the Tokens may be exercised exclusively through the designated blockchain interfaces, smart contracts, or governance mechanisms made available. Access to these rights requires that the Token holder maintains control over a compatible self-custodied wallet and engages directly with the supported interfaces. Participation in any functionality associated with the Token shall be subject to the technical implementation of such features and any applicable eligibility conditions, timelines, or procedural requirements as further communicated via official channels of the Spark ecosystem.
The obligations of the Token holders, including the payment of any network fees and compliance with applicable legal requirements, are to be fulfilled independently and at the sole responsibility of the holder. |
| **G.3** | **Conditions for modifications of rights and obligations** | Neither the Foundation nor the Issuer has the ability to unilaterally modify the rights or obligations attached to the Token. However, the functionalities or rights attaching to the Token may be affected by changes made to the Project by the governance community and development team. These protocol-level changes may impact on the ways in which the Token can be used. Holders are encouraged to monitor official protocol channels for updates, including but not limited to the Project's website ([https://spark.fi/](https://spark.fi/)mica). |
| **G.4** | **Future Public Offers** | The Issuer has submitted a white paper for the offering of the Tokens to the public. The white paper will be accessible at [https://spark.fi/mica](https://spark.fi/mica) upon the end of the notification period. |
| **G.5** | **Issuer Retained Crypto-Assets** | 0 |
| **G.6** | **Utility Token Classification** | FALSE |
| **G.7** | **Key Features of Goods/Services of Utility Tokens** | Not applicable |
| **G.8** | **Utility Tokens Redemption** | No redemption |
| **G.9** | **Non-Trading request** | TRUE |
| **G.10** | **Crypto-Assets purchase or sale modalities** | Not applicable |
| **G.11** | **Crypto-Assets Transfer Restrictions** | The Exchanges may impose restrictions on holders of Tokens on their respective Exchanges, in accordance with applicable laws and internal policies. Token holders who acquire the Token through "private sales" are subject to restrictions as per the terms of sale. |
| **G.12** | **Supply Adjustment Protocols** | FALSE |
| **G.13** | **Supply Adjustment Mechanisms** | Sky governance will control the Token's mint and burn functionality. Therefore, modifications to the Token's supply can only occur via a vote of Sky governance. |
| **G.14** | **Token Value Protection Schemes** | FALSE |
| **G.15** | **Token Value Protection Schemes Description** | Not applicable |
| **G.16** | **Compensation Schemes** | FALSE |
| **G.17** | **Compensation Schemes Description** | Not applicable |
| **G.18** | **Applicable law** | Subject to mandatory applicable law, to the extent legal disputes arise in relation to the Token, such matters would likely fall under the laws of the British Virgin Islands, the jurisdiction of incorporation of the Issuer, and be subject to the courts of that jurisdiction. |
| **G.19** | **Competent court** | See Section G.18. |
| **Part H – Information on the underlying technology** | | |
| **H.1** | **Distributed ledger technology** | The Token is deployed on the Ethereum mainnet, a public and permissionless distributed ledger based on blockchain technology. The Token is implemented via a set of smart contracts deployed to Ethereum and is accessible to any compatible wallet. |
| **H.2** | **Protocols and technical standards** | The Token conforms to the ERC-20 token standard and interacts with Ethereum-compatible smart contracts to facilitate distribution, claiming, staking, and governance. Token transfers, approvals, and other on-chain operations follow the established ERC-20 interface. |
| **H.3** | **Technology Used** | As an ERC-20 token, the Token will be deployed as a smart contract on the Ethereum blockchain. Users can manage the Token through their own non-custodial wallet software provided by third parties or by directly interacting with the Token's smart contract through a third-party API. |
| **H.4** | **Consensus Mechanism** | The Token will be launched on the Ethereum blockchain, which relies on a Proof of Stake ("PoS") consensus mechanism. In Ethereum's PoS consensus mechanism, validators are randomly selected to propose and attest to blocks. To participate as an Ethereum validator, they must stake at least 32 ETH and run the software established for that end. |
| **H.5** | **Incentive Mechanisms and Applicable Fees** | Validators are compensated with ETH in exchange for proposing and attesting to proposed blocks. Their compensation is sourced from a portion of transaction fees and a block reward. If validators misbehave, they will be penalised with slashing, involving losing part of their staked ETH.
Every Ethereum transaction requires the payment of gas fees. Since the implementation of EIP-1559, the fee is split into two components:
**Base fee:** Automatically calculated based on network demand and is burned (removed from circulation), and **Priority fee (or tip):** Paid to the validator for including the transaction in a proposed block. The priority fee is earned by the validator that proposed the block in which the transaction is included.
Ethereum validators are incentivised through a combination of block rewards and priority fees paid in ETH. Validators who misbehave, or act maliciously are subject to slashing penalties, resulting in the loss of a portion of their staked ETH. The person seeking admission to trading has no control over Ethereum blockchain fees, validator behaviour, or the consensus process. |
| **H.6** | **Use of Distributed Ledger Technology** | FALSE |
| **H.7** | **DLT Functionality Description** | Not applicable |
| **H.8** | **Audit** | FALSE |
| **H.9** | **Audit outcome** | Not applicable |
| **Part J – Information on the sustainability indicators in relation to adverse impact on the climate and other environment-related adverse impacts** | | |
| **J.01** | **Name** | Spark Foundation |
| **J.02** | **Relevant legal entity identifier** | Not available |
| **J.03** | **Name of the crypto-asset** | SPK |
| **J.04** | **Consensus Mechanism** | The Token will be launched on the Ethereum blockchain, which relies on a PoS consensus mechanism. In Ethereum's PoS consensus mechanism, validators are randomly selected to propose and attest to blocks. To participate as an Ethereum validator, they must stake at least 32 ETH and run the software established for that end. |
| **J.05** | **Incentive Mechanisms and Applicable Fees** | Validators are compensated with ETH in exchange for proposing and attesting to proposed blocks. Their compensation is sourced from a portion of transaction fees and a block reward. If validators misbehave, they will be penalised with slashing, involving losing part of their staked ETH.
Every Ethereum transaction requires the payment of gas fees. Since the implementation of EIP-1559, the fee is split into two components:
**Base fee:** Automatically calculated based on network demand and is burned (removed from circulation), and **Priority fee (or tip):** Paid to the validator for including the transaction in a proposed block. The priority fee is earned by the validator that proposed the block in which the transaction is included.
Ethereum validators are incentivised through a combination of block rewards and priority fees paid in ETH. Validators who misbehave, or act maliciously are subject to slashing penalties, resulting in the loss of a portion of their staked ETH. The person seeking admission to trading has no control over Ethereum blockchain fees, validator behaviour, or the consensus process. |
| **J.06** | **Beginning of the Period to which the Disclosed Information Relates** | 03/03/2024 |
| **J.07** | **End of the Period to which the Disclosed Information Relates** | 03/03/2025 |
| **Mandatory key indicator on energy consumption** | | |
| **J.08** | **Energy Consumption** | 6,049,441.70 kWh |
| **Sources and methodologies** | | |
| **J.09** | **Energy Consumption Sources and Methodologies** | The estimated energy consumption provided in Section J.08 has been calculated using the CCRI Crypto Sustainability Metrics provided by the Crypto Carbon Ratings Institute (source: [https://indices.carbon-ratings.com/](https://indices.carbon-ratings.com/)).
Since the Token has not yet been created, the energy consumption pertains to the previous calendar year, as an estimate of what can be consumed during the Token's first year by the Ethereum blockchain. |
## SPK Company Ltd. - SPK Token White paper
Version 1.0 - May 2025
Edition: Markets in Crypto-Assets Regulation White Paper for European Union & European Economic Area.
Date of notification: 2025-05-09
Purpose: Offer to the public of a crypto-asset other than an asset-referenced token or e-money token.
Note: This crypto-asset white paper has not been approved by any competent authority in any Member State of the European Union. The offeror of the crypto-asset is solely responsible for the content of this crypto-asset white paper.
### Table of Contents
* [**Important Notice**](#important-notice)
* [**Warning**](#warning)
* [Characteristics of the crypto-asset](#characteristics-of-the-crypto-asset)
* [Key information about the offer to the public](#key-information-about-the-offer-to-the-public)
* [**Part I – Information on Risks**](#part-i--information-on-risks)
* [I.1 Offer-Related Risks](#i1-offer-related-risks)
* [I.2 Issuer-Related Risks](#i2-issuer-related-risks)
* [I.3 Crypto-Assets-related Risks](#i3-crypto-assets-related-risks)
* [I.4 Project Implementation-Related Risks](#i4-project-implementation-related-risks)
* [I.5 Technology-Related Risks](#i5-technology-related-risks)
* [I.6 Mitigation measures](#i6-mitigation-measures)
* [**Part A – Information About the Offeror of the Crypto-Asset**](#part-a--information-about-the-offeror-of-the-crypto-asset)
* [**Part B – Information About the Issuer, If Different from the Offeror or Person Seeking Admission to Trading**](#part-b--information-about-the-issuer-if-different-from-the-offeror-or-person-seeking-admission-to-trading)
* [**Part C – Information About the Operator of the Trading Platform**](#part-c--information-about-the-operator-of-the-trading-platform)
* [**Part D – Information About Crypto-Asset Project**](#part-d--information-about-crypto-asset-project)
* [D.8 Plans for the token](#d8-plans-for-the-token)
* [D.9 Resource Allocation](#d9-resource-allocation)
* [D.10 Planned Use of Collected Funds or Crypto-Assets](#d10-planned-use-of-collected-funds-or-crypto-assets)
* [**Part E – Information About the Offer to the Public**](#part-e--information-about-the-offer-to-the-public)
* [E.2 Reasons for Public Offer](#e2-reasons-for-public-offer)
* [Refund Mechanism](#refund-mechanism)
* [**Part F – Information About the Crypto-Assets**](#part-f--information-about-the-crypto-assets)
* [**Part G – Information on the Rights and Obligations Attached to the Crypto-Assets**](#part-g--information-on-the-rights-and-obligations-attached-to-the-crypto-assets)
* [**Part H – Information on the Underlying Technology**](#part-h--information-on-the-underlying-technology)
* [**Part J – Information on the Sustainability Indicators in Relation to Adverse Impact on the Climate and Other Environment-Related Adverse Impacts**](#part-j--information-on-the-sustainability-indicators-in-relation-to-adverse-impact-on-the-climate-and-other-environment-related-adverse-impacts)
### IMPORTANT NOTICE
Please carefully review the following notice before proceeding. This notice applies to the entire white paper, regardless of how you received it, whether by email, website access, or any other form of electronic communication. By accessing, reviewing, or otherwise using this white paper, you expressly acknowledge and agree to comply with all terms, conditions, and restrictions outlined herein, including any updates or supplements provided from time to time.
This crypto-asset white paper complies with Title II of Regulation (EU) 2023/1114 (“MiCA”) and, to the best of the knowledge of the management body, the information presented in the crypto-asset white paper is fair, clear and not misleading and the crypto-asset white paper makes no omission likely to affect its import.
The crypto-asset referred to in the White Paper may lose its value partially or in full, may not always be transferable and may not be liquid.
The crypto-asset referred to in this white paper is not covered by the investor compensation schemes under Directive 97/9/EC of the European Parliament and of the Council.
The crypto-asset referred to in this white paper is not covered by the deposit guarantee schemes under Directive 2014/49/EU of the European Parliament and of the Council.
### WARNING
This summary should be read as an introduction to the crypto-asset white paper (the “White Paper”). The offer to the public of this crypto-asset does not constitute an offer or solicitation to purchase financial instruments, and any such offer or solicitation can be made only by means of a prospectus or other offer documents pursuant to the applicable national law.
This crypto-asset white paper does not constitute a prospectus as referred to in Regulation (EU) 2017/1129 of the European Parliament and of the Council (36) or any other offer document pursuant to Union or national law.
### Characteristics of the crypto-asset
SPK is a fungible crypto-asset issued on the Ethereum blockchain, designed for use within the Spark ecosystem. It does not represent ownership, profit rights, or a claim against the Offeror. SPK tokens can be freely held, transferred, and used in accordance with the functionalities described in this White Paper.
Holders of SPK may be entitled to participate in decentralised governance, access staking mechanisms, or engage in incentive-based activities, subject to eligibility criteria and the availability of such functionalities. All such rights are exercised through the Spark application or associated interfaces, or direct interaction with the blockchain, using a self-custodied blockchain wallet.
The exercise of rights requires active engagement by the holder and may involve network transaction fees (gas fees) payable to the Ethereum blockchain. SPK token holders are responsible for maintaining access to their wallet and acting in accordance with the Spark protocol.
The rights and obligations associated with SPK tokens may be modified in the future only through valid governance decisions adopted in accordance with the decentralised governance framework of the Spark protocol. That framework will reflect certain requirements, guidelines and practices derived from Sky governance and the Sky Atlas. Any material change to SPK token functionalities or holder rights will be communicated in accordance with Article 12 of MiCA and reflected in an updated version of this White Paper.
### Key information about the offer to the public
This White Paper relates to the public offering of SPK tokens. The offer consists of multiple distribution phases during which eligible users may claim SPK tokens, subject to conditions described in this document. No payment is required from eligible holders to participate in the offering, and no subscription or placement fees are charged by the Offeror.
The total number of SPK tokens available through this offer is capped at 680,000,000, representing the full allocation set aside for public distribution. There is no minimum or maximum subscription target, and no discounted purchase prices or bonuses for early participants apply, as SPK tokens are distributed without monetary consideration.
The offer is structured in distinct phases based on past activity and also participation in ecosystem-related campaigns. Each phase has a defined eligibility window and a claim period during which users may collect their allocated tokens via the official claiming interface. Claims are processed on-chain and subject to standard Ethereum gas fees.
This offer does not involve an issue price, as SPK tokens are not sold but offered for free to eligible participants. Additional distribution phases may be introduced in the future under this framework, and the White Paper will be updated if material changes occur.
The Offeror seeks to offer the SPK tokens to the public to increase the liquidity and distribution of the Token, facilitate more participation in governance, and increase the number of tokens in circulation.
### PART I – INFORMATION ON RISKS
#### I.1 Offer-Related Risks
Although SPK tokens are distributed without monetary payment, recipients incur potential risks relating to time, effort, and opportunity costs associated with qualifying actions. These include engaging with DeFi protocols, staking tokens, or performing specific on-chain activities.
The primary offer-related risks involve post-receipt use and trading of SPK tokens. Once listed, token value may fluctuate significantly due to market speculation, macroeconomic factors, or project developments, which can affect the perceived benefit of having received the tokens.
Low liquidity on trading venues may impair a recipient's ability to sell or use SPK tokens efficiently. Listings are not guaranteed, and the Offeror cannot ensure continued support from exchanges. A delisting or lack of market depth may result in SPK tokens being practically unusable.
Trading venues, whether decentralised or centralised, pose operational and counterparty risks.
Users may face delays, hacks, or insolvency events, which could hinder access to tokens. Neither the Spark Foundation nor the Offeror is liable for such outcomes.
Smart contract risks also exist during the claim or staking processes. Errors, vulnerabilities, or incorrect wallet use may lead to permanent loss of SPK tokens, despite the token having been free.
Finally, recipients may still incur tax liabilities on receipt, even without monetary investment. Participants must assess these risks individually and ensure compliance with local regulations.
#### I.2 Issuer-Related Risks
The Issuer's sole function is to issue and distribute SPK tokens. It does not manage or operate any technical infrastructure, oversee governance processes, or maintain control over the protocol or community.
This limited operational role means the Issuer cannot respond to technical failures, governance disputes, or security incidents within the broader ecosystem. If issues arise post-distribution such as bugs in smart contracts or shifts in network governance, the Issuer has no authority or capacity to intervene or implement corrective measures.
Furthermore, the Offeror provides no guarantees regarding the future value, usability, or development of the SPK token or the Spark ecosystem. All post-distribution developments depend on decentralised community governance or third-party contributors, over whom the Offeror has no influence.
Participants should therefore understand that their reliance on the Issuer is limited strictly to the issuance of SPK tokens. Any expectations beyond that, whether technical, economic, or governance-related, must be assessed based on the broader ecosystem's operations and risks.
#### I.3 Crypto-Assets-related Risks
As a Crypto-asset, SPK tokens carry risks inherent to digital tokens built on public blockchains. These risks are present regardless of whether a token is purchased or received for free.
SPK operates on the Ethereum network and is subject to blockchain-related vulnerabilities. Network congestion, outages, or high transaction fees could impact users’ ability to claim, transfer, or use SPK tokens in a timely or cost-effective manner.
The token's value is also highly volatile. While there is no direct financial cost to acquiring SPK tokens through airdrops or qualifying actions, token holders may still face opportunity costs if the value declines sharply or if the token becomes unusable due to low adoption or regulatory constraints.
Smart contract vulnerabilities pose another key risk. Even audited contracts can contain bugs or be exploited. Losses stemming from contract-level attacks could affect staking, transfers, or functionality tied to SPK tokens.
Custody of SPK tokens requires secure private key management. Loss or theft of private keys will result in irreversible loss of tokens. Participants are solely responsible for securing their wallet access and recovery information.
SPK token holders may also be targeted by fraud, phishing attacks, or scams that impersonate the Offeror or promote counterfeit tokens. Engaging with unverified links, dApps, or communications could result in loss of assets.
Finally, evolving regulations in different jurisdictions may restrict use or access to SPK, especially if the token is later deemed to fall within specific legal classifications. This could limit its utility or expose holders to compliance obligations.
#### I.4 Project Implementation-Related Risks
The long-term success of SPK is closely tied to the ongoing implementation of the broader Spark project. This process faces a number of technical, operational, and strategic risks.
Technical risks include the potential for bugs or vulnerabilities in smart contracts, governance modules, or infrastructure upgrades. Even with careful development and auditing, errors could affect token functionality or user funds.
Operational risks arise from the allocation of resources, including developer attention, treasury funding, and community engagement. If these are insufficient or misaligned, project timelines may slip or core features may never be completed.
The project’s governance and roadmap are shaped by a decentralised community. This structure can result in slow decision-making, conflicting interests, or even governance capture, where a small group steers development against the broader community's interests.
Adoption risk is also significant. SPK tokens’ utility depends on community participation and real-world integrations. Without active use and credible demand for the Spark ecosystem’s services, the token’s role and relevance may diminish.
In addition, external dependencies such as integration with third-party protocols, platforms, and infrastructure providers can introduce delays or disruptions. Any instability or failure in these components could stall project delivery or impair functionality.
Finally, the broader regulatory and technological environment can shift rapidly. Changes in crypto-asset regulation, competition from new technologies, or loss of ecosystem partners may materially alter the implementation trajectory of the project.
#### I.5 Technology-Related Risks
SPK relies on blockchain infrastructure and smart contract technology that is still evolving. These underlying technologies present several risks that could affect the SPK token's security, performance, and usability.
Distributed ledger networks like the Ethereum blockchain may experience congestion, downtime, or forks, all of which can disrupt token transfers or contract interactions. In extreme cases, users may lose access to their tokens or experience unexpected delays or errors.
Smart contracts governing SPK token-related operations are immutable once deployed. Security flaws or exploits may be used to manipulate SPK token transfers, staking mechanisms, or governance processes.
Token holders are fully responsible for managing their private keys. Mistakes in wallet configuration or loss of access credentials result in permanent token loss, as transactions on the blockchain are irreversible.
Compatibility and access risks may arise if wallet software becomes outdated, unsupported, or incompatible with new SPK token upgrades or infrastructure. Users relying on specific platforms may lose access if those platforms shut down or fail to update their systems.
Moreover, SPK tokens depend on integrations with third-party services like decentralised exchanges, bridges, oracles, and custodians. Failures, security breaches, or regulatory actions affecting these services could degrade SPK tokens’ functionality or cause temporary inaccessibility.
The SPK token is also exposed to long-term risks from technological disruption. Innovations such as quantum computing could weaken cryptographic systems securing blockchain networks. While such risks remain largely theoretical, they could undermine user confidence or lead to structural changes in the network.
In summary, while the SPK ecosystem employs best practices in smart contract development and network integration, the rapidly changing technological landscape presents ongoing risks that may affect security, accessibility, and user experience.
#### I.6 Mitigation measures
To address the range of risks associated with SPK, the project has implemented multiple mitigation strategies across technical, operational, and governance layers.
* **Smart Contract Audits** **–** All critical contracts are subject to external audits by reputable security firms. Audits help identify vulnerabilities before deployment and reduce the likelihood of exploitation. Previous audits are accessible at [http://docs.spark.fi/dev/security/security-and-audits](http://docs.spark.fi/dev/security/security-and-audits).
* **Progressive rollout** **–** SPK token distribution and product features are introduced gradually to allow for testing and feedback, minimising systemic risk and improving resilience.
* **Decentralised Governance** **–** SPK token governance is structured through community mechanisms, including SparkDAO and SkyDAO governance. This provides checks and balances, limits centralised control, and enables dynamic adaptation to new risks.
* **Transparent communication** **–** Ongoing disclosures via public documentation, white paper updates, forums, and governance proposals foster community awareness and help participants make informed decisions.
* **Liquidity support and listings –** While no guarantee is provided, the Offeror may collaborate with market participants to encourage liquidity provision and exchange listings where feasible.
* **Regulatory Alignment** **–** The project tracks legal developments in key jurisdictions to align with regulatory frameworks, particularly those under MiCA.
These measures do not eliminate risk, but they significantly reduce the likelihood or severity of adverse events. Participants should still exercise caution and adopt personal risk management strategies when engaging with SPK tokens or the broader Spark ecosystem.
### PART A – INFORMATION ABOUT THE OFFEROR OF THE CRYPTO-ASSET
#### A.1 Name
SPK Company Ltd.
#### A.2 Legal Form
Company limited by shares
#### A.3 Registered address
SHRM Trustees (BVI) Limited of Trinity Chambers, PO Box 4301.
#### A.4 Head office
Road Town, Tortola, British Virgin Islands
#### A.5 Registration Date
2025-02-19
#### A.6 Legal entity identifier
Not available
#### A.7 Another identifier required pursuant to applicable national law
2170013
#### A.8/9/10 Contacting the Offeror
The Offeror can be contacted by telephone or email using the details provided below. The Offeror will respond within 14 business days.
Glenn Kennedy: [gkennedy@leewardmanagement.ky](mailto\:gkennedy@leewardmanagement.ky)
Marc Piano: [piano@horizonsglobal.io](mailto\:piano@horizonsglobal.io)
Telephone number: +1 345-749-9601 Email address:
The Offeror does not have a website. The website of the project is [https://spark.fi/](https://spark.fi/).
#### A.11 Parent Company
Spark Foundation
#### A.12 Identity of the management body
The sole director of the Offeror is Spark Foundation
The directors of Spark Foundation are Glenn Kennedy and Marc Piano
Business address of Spark Foundation is Leeward Management Limited, Suite 3119, 9 Forum Lane, Camana Bay, PO Box 144, George Town, Grand Cayman KY1-9006, Cayman Islands
#### A.13 Business activity
The only purpose is to issue and distribute the Token.
#### A.14 Parent Company Business Activity
To support, promote, and advance the development, adoption, security, and growth of Spark.
#### A.15 Newly Established
true
#### A.16 Financial condition for the past three years
The Offeror is a newly incorporated company with no material liabilities as of the date of this White Paper. The Offeror will be capitalised as needed to fulfil its mandate of issuing SPK tokens and distributing them.
#### A.17 Financial condition since registration
The Offeror is a newly incorporated company with no material liabilities as of the date of this White Paper. The Offeror will be capitalised as needed to fulfil its mandate of issuing SPK tokens and distributing them.
### PART B – INFORMATION ABOUT THE ISSUER, IF DIFFERENT FROM THE OFFEROR OR PERSON SEEKING ADMISSION TO TRADING
This section is not applicable. Part B does not apply as the issuer and the offeror are the same legal entity.
### PART C – INFORMATION ABOUT THE OPERATOR OF THE TRADING PLATFORM
This section is not applicable. No trading platform has drawn up or contributed to the preparation of this White Paper.
### PART D – INFORMATION ABOUT CRYPTO-ASSET PROJECT
#### D.1 Crypto-asset project name
Spark
#### D.2 Crypto-asset name
Spark
#### D.3 Abbreviation
SPK
#### D.4 Crypto-asset project description
The project is a DeFi protocol, which emerged from Sky, previously known as MakerDAO, and serves as a ‘Sky Star’, a subDAO within the Sky ecosystem. It consists of three main components: SparkLend, a stablecoin lending market; Spark Savings, for earning yield on certain stablecoins; and Spark Liquidity Layer, a backend capital allocator that routes liquidity across select DeFi protocols.
#### D.5 Details of all natural or legal persons involved in the implementation of the crypto-asset project
SPK Company, Ltd.
c/o SHRM Trustee (BVI) Ltd.
Trinity Chambers
PO Box 4301
Road Town, Tortola, British Virgin Islands
Spark Foundation
c/o Leeward Management Limited
Suite 3119, 9 Forum Lane Camana Bay, George Town,
Grand Cayman KY1-9006, Cayman Islands
#### D.6 Utility token classification
false
#### D.7 Key Features of Goods/Services for Utility Token Projects
Not applicable
#### D.8 Plans for the token
The SPK token is designed to function as a cornerstone of the Spark ecosystem, enabling long-term value creation through decentralised incentives, participation, and infrastructure support. SPK is distributed without monetary consideration and built with clear alignment between user effort and ecosystem growth.
##### **Community-Driven Distribution**
SPK token’s distribution model prioritises organic community involvement. Tokens are allocated via airdrops, on-chain activity, and reward mechanisms tied to meaningful user engagement.
These distribution channels are permissionless, performance-based and structured to encourage use among committed participants.
##### **Protocol Utility and Staking**
SPK tokens are expected to play a role in supporting the reliability and functionality of the Spark protocol over time. SPK token holders may be given the option to stake their SPK to contribute to the network's resilience or participate in reward systems. Staking mechanisms could be linked to protocol components such as cross-chain infrastructure or security features, although specifics may evolve based on governance decisions and technical development. Staking may involve time-bound commitments, and rewards, if any, will reflect the level of engagement and the function being supported.
##### **Incentive structures**
The token design incorporates the possibility of allocating SPK tokens to participants who contribute to the ecosystem’s growth and operational soundness. This may include users who interact with infrastructure components, provide liquidity, or contribute to early adoption efforts. These measures aim to foster long-term engagement.
##### **Governance Engagement**
SPK tokens may also function as a governance tool, enabling holders to take part in decentralised decision-making processes. These could include discussions and votes on treasury use, protocol evolution, or other strategic priorities. The governance model is intended to be adaptable, subject to community feedback and emerging needs.
##### **Future Outlook**
As the Spark project grows, SPK tokens may become relevant in additional modules or integrations, including those related to cross-chain operations, coordination layers, or service modules. These developments will be introduced incrementally and in alignment with broader ecosystem goals.
The vision for SPK tokens is to support a sustainable, community-driven network. Its role is not fixed but is intended to reflect the evolving needs of a decentralised ecosystem prioritising fairness, resilience, and meaningful engagement.
#### D.9 Resource Allocation
The Spark ecosystem incorporates a structured approach to resource allocation, aimed at ensuring long-term operational sustainability and adaptability. SPK tokens are reserved across specific categories to support development, governance, and ecosystem initiatives.
A dedicated share of the SPK token supply is earmarked for operational costs, reflecting the ongoing need to maintain infrastructure, support contributors, and cover administrative requirements. Additionally, Spark will receive initial grant funding from Sky to help bootstrap Spark’s growth. These resources enable the protocol to remain functional and responsive without immediate reliance on external funding.
In parallel, a treasury allocation is established to provide flexibility over time. This reserve is governed by community processes and may be used to support future proposals, ecosystem incentives, or strategic partnerships.
The resource model aligns token distribution with the needs of a dynamic and participatory ecosystem, allowing SPK tokens to function as a mechanism for funding public goods and sustaining the protocol over time.
#### D.10 Planned Use of Collected Funds or Crypto-Assets
The offer to the public will take place without raising funds or accepting any crypto-assets, as outlined in Section E.
### PART E – INFORMATION ABOUT THE OFFER TO THE PUBLIC
#### E.1 Public Offering
OTPC
#### E.2 Reasons for Public Offer
The public offer of SPK tokens is intended to initiate the launch of the Spark project and to incentivise early engagement with the Spark protocol. The offer is designed to encourage the use of its services and to establish a decentralised and active user base from the outset. The tokens will be distributed without collecting any funds or crypto-assets from participants. Instead, the offer is structured around non-monetary contribution mechanisms such as protocol usage, on-chain activity, staking engagement, and other qualifying actions.
Tokens are provided free of charge or in exchange for specific actions that demonstrate interest or involvement in the ecosystem. These distribution mechanisms include airdrops based on past engagement, performance-based eligibility, and participation in pre-defined incentive programs as specified in more detail in section E.18.
The public offer is not intended as a capital-raising measure and does not involve the collection of funds or crypto-assets. Accordingly, no proceeds will be received by the Offeror or any affiliated entity in connection with the distribution of SPK tokens. The offer is exclusively designed to support the initial development of a decentralised user base by allocating tokens to participants on the basis of non-financial contributions. The Offeror does not intend to derive any financial gain from the offer, and the distribution is structured to ensure compliance with applicable regulatory exemptions concerning public offerings without consideration.
#### E.3 Fundraising target
Not applicable
#### E.4 Minimum Subscription Goal
Not applicable
#### E.5 Maximum Subscription Goal
Not applicable
#### E.6 Oversubscription Acceptance
false
#### E.7 Oversubscription Allocation
Not applicable
#### E.8 Issue Price
€0
#### E.9 Official currency or any other crypto-assets determining the issue price
Not applicable
#### E.10 Subscription fee
€0
#### E.11 Offer Price Determination Method
The SPK tokens will be allocated without consideration and exclusively based on demonstrable user actions or prior holdings. No monetary payment or transfer of crypto-assets is required or accepted in exchange for the receipt of SPK tokens.
#### E.12 Total Number of Offered Crypto-Assets
680,000,000 SPK tokens
#### E.13 Targeted Holders
ALL
#### E.14 Holder restrictions
The offer of SPK tokens is not subject to any general restriction with respect to the type of recipient. However, the distribution is limited to individuals and entities that are not subject to applicable sanctions or other regulatory prohibitions. The Offeror reserves the right to exclude from eligibility any user or wallet address that is reasonably believed to be associated with a jurisdiction, entity, or individual subject to relevant restrictions under applicable law. Further, any user or wallet address reasonably suspected of being a Sybil wallet or involved in fraudulent, manipulative, or malicious activity may be excluded from participation in the offer. Users are responsible for ensuring that their receipt and holding of SPK tokens are lawful in their respective jurisdictions.
Participants must self-certify that they are not residents of, or otherwise located in, any jurisdiction where the receipt or holding of crypto-assets is restricted or prohibited.
#### E.15
Purchasers participating in the offer to the public of crypto-asset will be able to be reimbursed if the minimum target subscription goal is not reached at the end of the offer to the public, if they exercise the right to withdrawal foreseen in Article 13 of Regulation (EU) 2023/1114 or if the offer is cancelled.
#### E.16 Refund Mechanism
Pursuant to Article 13 of MiCA, retail holders who have agreed to receive SPK tokens from the Offeror shall have a right to withdraw from such agreement within a period of 14 calendar days from the date of such agreement, without giving any reason and without incurring any costs.
Retail holders may exercise their right of withdrawal by following the process available at [www.spark.fi/mica](http://www.spark.fi/mica). The notice must be submitted no later than 14 calendar days after the date on which the agreement to acquire SPK tokens was concluded.
Upon receiving the withdrawal notice, the Offeror will provide the retail holder with a blockchain address to which the tokens must be returned.
##### **Return of Tokens and Reimbursement**
The retail holder shall return the acquired SPK tokens to the Offeror without undue delay and no later than 14 calendar days after submitting the withdrawal notice. As no monetary payment was made by the holder, no reimbursement shall be due. Due to this, the tokens shall be returned and the agreement voided without further obligation from either party.
The Offeror will not impose any fee or penalty in connection with the exercise of the right of withdrawal. Gas fees incurred on-chain in connection with the return of tokens shall be borne by the retail holder unless otherwise agreed.
#### E.17 Refund Timeline
The designated refund wallet address shall be made available to the holder upon receipt of the withdrawal notice and shall remain available for the return of tokens for a minimum period of 14 calendar days thereafter.
#### E.18 Offer Phases
The public offering of SPK tokens will occur in separate phases, each designed to distribute tokens to distinct participant groups based on eligibility criteria and pre-defined allocation methodologies. Claims will be made available via on-chain claiming interfaces following the Token Generation Event (TGE), with each phase subject to its own claiming window.
##### **Phase 1**:
This phase includes distributions to early participants who interacted with designated DeFi protocols prior to the TGE. Allocation is based on historic on-chain activity, with protocol-specific criteria and anti-sybil measures applied. Eligible users may claim their tokens starting at TGE for a limited duration.
##### **Phase 2**:
This phase encompasses broader ecosystem distribution based on historical activity across multiple chains, platforms and applications. Allocations are determined using a point-based system reflecting user exposure to selected assets and protocols. Eligibility is non-transferable and fixed prior to the TGE. The claiming period for this phase begins at TGE and concludes following a pre-defined window.
##### **Phase 3**:
This phase involves distribution to participants in Spark’s post-TGE ecosystem campaigns, including social and engagement-based reward initiatives. Participants may earn eligibility by completing campaign tasks or interacting with designated applications. Each campaign includes an earning period and a subsequent claim window. Unclaimed tokens after the claim period expires will revert to the treasury.
All phases are subject to eligibility verification, including sanctions screening and wallet verification. Tokens may only be claimed via the official interface during the applicable claiming window.
Eligibility criteria and claiming instructions for each phase will be published on the official claiming interface on Spark’s website, [spark.fi](http://spark.fi/), prior to the commencement of the relevant claiming window.
This white paper covers a continuous offering of SPK tokens through multiple time-limited phases. Each phase has a defined claim period, but the Offeror may initiate additional distribution phases in the future under the same framework. The offer shall remain open for purposes of MiCA Article 10(2) until otherwise stated, and the number of tokens in circulation will be published at least monthly on the Offeror’s website.
In the event that future phases are materially different from those described herein, whether in terms of structure or claiming mechanisms, the Offeror will update and notify the white paper in accordance with MiCA Article 12 prior to the commencement of such phases.
#### E.19 Early Purchase Discount
Not applicable.
#### E.20 Time-limited offer
false
#### E.21 Subscription period beginning
Not applicable
#### E.22 Subscription period end
Not applicable
#### E.23 Safeguarding Arrangements for Offered Funds/Crypto-Assets
Not applicable
#### E.24 Payment Methods for Crypto-Asset Purchase
The SPK tokens are offered without payment of any monetary benefit, but based on pre-defined actions and on-chain activity.
#### E.25 Value Transfer Methods for Reimbursement
No reimbursement shall be due.
#### E.26 Right of Withdrawal
In accordance with Article 13 of MiCA, any retail holder who enters into an agreement to acquire SPK tokens as part of this public offering shall have the right to withdraw from the agreement within a period of 14 calendar days from the date of such agreement, without giving any reason and without incurring any cost.
Retail holders may exercise it by following the process outlined under Refund Mechanism.
#### E.27 Transfer of Purchased Crypto-Assets
Upon satisfying the eligibility criteria for a given phase of the offer, SPK tokens will become claimable by the eligible holder at or after the TGE. Tokens will be made available via an on-chain claiming mechanism, and holders must actively claim their allocation through the designated interface.
Upon successful claiming, the SPK tokens will be transferred to the holder’s self-custodied wallet address, at which point the holder obtains full control and ability to transfer, subject to applicable legal or contractual restrictions with wallet provider. There are no transfer restrictions imposed by the Offeror following delivery, unless otherwise stated in this White Paper.
#### E.28 Transfer Time Schedule
SPK tokens will become claimable by eligible holders in accordance with any claiming schedules announced on Spark's official website. Upon claiming, tokens will be transferred in full to the holder’s wallet with no further vesting, lock-up, or time-based release restrictions imposed by the Offeror.
#### E.29 Purchaser’s Technical Requirement
To receive and hold SPK tokens, eligible holders must have access to a compatible, self-custodied wallet capable of interacting with the Ethereum blockchain, where SPK is deployed as an ERC-20 standard token.
The wallet must support:
* Secure storage of private keys and recovery phrases;
* On-chain interaction with smart contracts
(e.g., for claiming SPK tokens)
* The ability to pay applicable network transaction fees (gas) in the native blockchain token, ETH.
The Offeror does not provide wallet infrastructure or custody services. It is the sole responsibility of the eligible holder to:
* Secure their private keys;
* Ensure uninterrupted access to their wallet;
* Ensure the wallet address used for claiming is correct and under their exclusive control.
Failure to meet the above requirements may result in the holder’s inability to claim or access the SPK tokens, for which the Offeror assumes no responsibility.
#### E.30 Crypto-asset service provider (CASP) name
Not applicable
#### E.31 CASP identifier
Not applicable
#### E.32 Placement form
NTAV
#### E.33 Trading Platforms name
Not applicable
#### E.34 Trading Platforms Market Identifier Code (MIC)
Not applicable
#### E.35 Trading Platforms Access
Not applicable
#### E.36 Involved costs
Not applicable
#### E.37 Offer Expenses
No placement fees, subscription fees, or transaction fees are charged to the eligible holder by the Offeror in connection with the receipt or claiming of SPK tokens.
Eligible holders may be required to pay standard network transaction fees (gas fees) to claim their tokens via the designated on-chain interface. These fees are paid directly to the blockchain network and not retained by the Offeror.
All costs associated with the development, structuring, and execution of the offering, including legal, technical, and marketing expenses, are borne by the Offeror.
#### E.38 Conflicts of Interest
Spark Foundation is expected to receive an allocation of approximately 1 billion SPK tokens following the TGE. These SPK tokens will be used by the Spark Foundation to support protocol development, governance, ecosystem incentives, and other community-aligned initiatives. It is the assessment of the Offeror that this allocation does not give rise to a conflict of interest within the meaning of Article 14(1)(c) of MiCA, as Spark Foundation operates with a mandate to promote the long-term success of the ecosystem and not for private gain. The Offeror will continue to monitor for potential conflicts of interest on an ongoing basis and will take appropriate steps to disclose and mitigate any such conflicts should they arise.
#### E.39 Applicable law
This offering and the contractual rights and obligations arising between the Offeror and eligible holders in connection with SPK tokens shall be governed by and construed in accordance with the laws of the British Virgin Islands. Notwithstanding the above, this White Paper and the offer of SPK tokens to the public within the European Union are made in accordance with MiCA.
#### E.40 Competent court
Any dispute arising out of or in connection with this offering or the SPK tokens shall be subject to the exclusive jurisdiction of the courts of the British Virgin Islands. This is without prejudice to the rights of retail holders residing in the European Union to bring claims before the courts of their place of residence, in accordance with applicable consumer protection and private international law rules.
### PART F – INFORMATION ABOUT THE CRYPTO-ASSETS
#### F.1 Crypto-Asset Type
Crypto-asset other than an asset-referenced token or e-money token.
#### F.2 Crypto-Asset Functionality
SPK token is a fungible crypto-asset within the meaning of Article 3(1)(5) of MiCA. It does not qualify as an asset-referenced token (ART) or e-money token (EMT) under MiCA and is offered to the public under the Title II framework.
SPK token is implemented as a standard ERC-20 token on the Ethereum blockchain and is freely transferable following its delivery to the holder, subject to any applicable legal or contractual restrictions described in this White Paper.
SPK token is designed primarily for the use within Spark ecosystem, including participation in governance, reward programs, and future protocol-based activities. It does not represent a financial claim or entitlement to any underlying asset, nor does it confer ownership or profit rights in the Offeror or any affiliated entity.
#### F.3 Planned Application of Functionalities
At the time of publishing this White Paper, the SPK token’s core functionalities are described below and will be made available progressively after Offering:
* **Governance**: SPK token holders will be able to participate in the governance of the Spark protocol. This may include the right to vote on proposals concerning matters like protocol parameters, treasury allocation, grant distributions, and technical upgrades. Governance mechanisms will evolve under a decentralised governance model managed via the SparkDAO.
* **Staking**: SPK tokens may be staked by holders. In return for staking, participants may earn rewards. The staking mechanism is governed by smart contracts and requires the transfer of SPK tokens to a dedicated staking contract.
* **Rewards and Incentives**: SPK tokens will be distributed as part of airdrop campaigns and incentive programmes as described in this White Paper. These may include rewards for early use of DeFi products within the Spark application. In addition, SPK tokens may be used in future farming mechanisms or liquidity incentives across various Spark-related services.
All functionalities are accessible through the Spark application or approved interfaces. Certain features, such as staking and voting, may be made available in phases, with implementation timelines subject to further governance decisions. Any material updates to the functionalities or use of SPK tokens will be reflected through updates to this white paper in accordance with MiCA Article 12.
**A description of the characteristics of the crypto-asset, including the data necessary for classification of the crypto-asset white paper in the register referred to in Article 109 of Regulation (EU) 2023/1114, as specified in accordance with paragraph 8 of that Article**
#### F.4 Type of white paper
OTHR
#### F.5 The type of submission
NEWT
#### F.6 Crypto-asset Characteristics
See Part D and Section F.2.
#### F.7 Commercial name or trading
Spark / SPK token name
#### F.8 Website of the issuer
The Issuer does not have a website.
The website of the project is [https://spark.fi/](https://spark.fi/).
#### F.9 Starting date of offer to the public or admission to trading
2025-06-10
#### F.10 Publication date
2025-06-09
#### F.11 Any other services provided by the issuer
The Offeror does not offer any other services covered by MiCA
#### F.12 Identifier of operator of the trading platform
Not applicable
#### F.13 Language or languages of the white paper
English
#### F.14 Digital Token Identifier Code used to uniquely identify the crypto-asset or each of the several crypto-assets to which the white paper relates, where available
SPK
#### F.15 Functionally Fungible Group Digital Token Identifier, where available
Not applicable
#### F.16 Voluntary data flag
false
#### F.17 Personal data flag
true
#### F.18 LEI eligibility
false
#### F.19 Home Member State
Denmark
#### F.20 Host Member States
The offer to the public of SPK tokens is passported to the following countries:
* Austria
* Belgium
* Bulgaria
* Croatia
* Cyprus
* Czech Republic
* Estonia
* Finland
* France
* Germany
* Greece
* Hungary
* Iceland
* Ireland
* Italy
* Latvia
* Liechtenstein
* Lithuania
* Luxembourg
* Malta
* Netherlands
* Norway
* Poland
* Portugal
* Romania
* Slovakia
* Slovenia
* Spain
* Sweden
### PART G – INFORMATION ON THE RIGHTS AND OBLIGATIONS ATTACHED TO THE CRYPTO-ASSETS
#### G.1 Purchaser Rights and Obligations
Upon receipt of SPK tokens, holders are granted the right to hold, transfer, and utilise the tokens in accordance with the functionalities set out in this White Paper. Where implemented, such functionalities may include the ability to participate in governance processes and protocol-level decision-making, as well as to access certain staking or reward mechanisms as described herein.
SPK tokens do not confer on holders any ownership interest, profit-sharing rights, equity claims, or creditor rights against the Offeror. The tokens do not represent financial instruments, electronic money, or asset-referenced tokens within the meaning of MiCA.
SPK token holders shall be solely responsible for maintaining secure custody of their private keys, ensuring accurate and timely use of the designated claiming interface, and bearing any applicable network transaction fees incurred during claiming, transferring, or using SPK tokens. Token holders must also ensure compliance with any applicable legal, regulatory, or tax obligations in their jurisdiction of residence. No additional rights or obligations are imposed on holders beyond those expressly described in this White Paper.
#### G.2 Exercise of Rights and obligations
The rights associated with SPK tokens may be exercised exclusively through the designated blockchain interfaces, smart contracts, or governance mechanisms made available. Access to these rights requires that the SPK token holder maintains control over a compatible self-custodied wallet and engages directly with the supported interfaces.
Participation in governance, staking, or any reward-based functionality shall be subject to the technical implementation of such features and any applicable eligibility conditions, timelines, or procedural requirements as further communicated via official channels of the Spark ecosystem.
The obligations of SPK token holders, including the payment of any network fees and compliance with applicable legal requirements, are to be fulfilled independently and at the sole responsibility of the holder.
#### G.3 Conditions for modifications of rights and obligations
The rights and obligations associated with SPK tokens may be modified in the future as a result of governance decisions adopted in accordance with the decentralised governance framework of the Spark protocol. Such modifications may include changes to token functionalities, staking parameters, voting mechanisms, or eligibility criteria for participation in network incentives.
The Offeror does not retain unilateral discretion to amend the rights or obligations of retail holders after the issuance of SPK tokens. Any material change to the governance structure or token utility will be subject to the governance procedures established within the Spark ecosystem, including proposal submission, voting thresholds, and quorum requirements, as applicable.
#### G.4 Future Public Offers
At the time of publication of this white paper, the Offeror does not have any confirmed plans for future public offers of SPK tokens. Should the Offeror initiate any such offering in the future, a separate or updated white paper will be prepared, notified to the competent authority, and published in accordance with Article 12 of MiCA.
#### G.5 Issuer Retained Crypto-Assets
0
#### G.6 Utility Token Classification
false
#### G.7 Key Features of Goods/Services of Utility Tokens
Not applicable
#### G.8 Utility Token Redemption
Not Applicable
#### G.9 Non-Trading request
true
#### G.10 Crypto-Assets purchase or sale modalities
Not applicable
#### G.11 Crypto-Assets Transfer Restrictions
The Offeror does not impose any transfer restrictions.
#### G.12 Supply Adjustment Protocols
false
#### G.13 Supply Adjustment Mechanisms
SPK does not currently have any automatic or algorithmic supply adjustment mechanisms linked to market demand. There is no pre-programmed rebasing, burning, or minting functionality designed to increase or decrease the token supply based on price or demand fluctuations.
However, the total supply of SPK may be increased in the future through governance proposals adopted by the SkyDAO, the decentralised governance structure associated with the Spark protocol. Any such supply adjustment would be subject to the applicable governance rules and would require approval through the established voting procedures.
#### G.14 Token Value Protection Scheme
false
#### G.15 Token Value Protection Schemes Description
Not applicable
#### G.16 Compensation Schemes
false
#### G.17 Compensation Schemes Description
Not applicable
#### G.18 Applicable law
This white paper, and any contractual rights and obligations arising in connection with the receipt and use of SPK tokens, shall be governed by and construed in accordance with the laws of the British Virgin Islands.
#### G.19 Competent court
Any dispute arising out of or in connection with this offering shall be subject to the exclusive jurisdiction of the courts of the British Virgin Islands.
This is without prejudice to the rights of retail holders who are natural persons and habitually resident in a Member State of the European Union to bring proceedings before the courts of their place of residence, in accordance with applicable EU consumer protection and private international law rules.
### Part H – INFORMATION ON THE UNDERLYING TECHNOLOGY
#### H.1 Distributed ledger technology
SPK token is deployed on the Ethereum mainnet, a public and permissionless distributed ledger based on blockchain technology. The token is implemented via a set of smart contracts deployed to Ethereum and is accessible to any compatible wallet.
#### H.2 Protocols and technical
SPK tokens conform to the ERC-20 token standard standards and interacts with Ethereum-compatible smart contracts to facilitate distribution, claiming, staking, and governance. Token transfers, approvals, and other on-chain operations follow the established ERC-20 interface.
#### H.3 Technology Used
As an ERC-20 token, the SPK token will be deployed as a smart contract on the Ethereum blockchain. Users can manage the SPK tokens through their own non-custodial wallet software provided by third parties or by interacting directly with the SPK token’s smart contract through a third-party API.
#### H.4 Consensus Mechanism
The SPK token is deployed on the Ethereum blockchain. Ethereum operates using a Proof of Stake (PoS) consensus mechanism, wherein network validators are selected based on staked ETH to confirm transactions and propose new blocks.
#### H.5 Incentive Mechanisms and Applicable Fees
SPK token holders may earn SPK tokens as rewards through staking or participation in Spark ecosystem activities, as described in this White Paper.
The Offeror does not charge any placement or transaction fees in connection with the receipt or use of SPK tokens. However, all on-chain transactions on Ethereum, including claiming and transferring SPK tokens, require the payment of network gas fees.
Gas fees are denominated in ETH and paid directly to the Ethereum network. Following the implementation of Ethereum Improvement Proposal 1559 (EIP-1559), gas fees consist of two components:
* **Base fee**:\
This is automatically calculated based on current network demand and is burned, meaning it is removed from circulation.
* **Priority fee (tip)**:\
This is paid to the validator that successfully proposes the block in which the transaction is included.
Ethereum validators are incentivised through a combination of block rewards and priority fees paid in ETH. Validators who misbehave or act maliciously are subject to slashing penalties, resulting in the loss of a portion of their staked ETH.
The Offeror has no control over Ethereum blockchain fees, validator behaviour, or the consensus process.
#### H.6 Use of Distributed Ledger Technology
false
#### H.7 DLT Functionality Description
Not applicable
#### H.8 Audit
false
#### H.9 Audit outcome
Not applicable
#### PART J – INFORMATION ON THE SUSTAINABILITY INDICATORS IN RELATION TO ADVERSE IMPACT ON THE CLIMATE AND OTHER ENVIRONMENT-RELATED ADVERSE IMPACTS
#### General information
#### S.1 Name
SPK Company Ltd
#### S.2 Relevant legal entity identifier
*Identifier stated to in section A*
Not available
#### S.3 Name of the crypto-asset
*Name of the crypto-asset as stated to in section A*
Spark / SPK
#### S.4 Consensus Mechanism
The SPK token is deployed on the Ethereum blockchain. *The consensus mechanism,* Ethereum operates using a Proof of Stake (PoS) *as stated in Section H* consensus mechanism, wherein network validators are selected based on staked ETH to confirm transactions and propose new blocks.
#### S.5 Incentive Mechanisms and Applicable Fees
*Incentive mechanisms to secure transactions and any fees applicable as stated in section H.*
SPK token holders may earn SPK tokens as rewards through staking or participation in Spark ecosystem activities, as described in this White Paper.
The Offeror does not charge any placement or transaction fees in connection with the receipt or use of SPK tokens. However, all on-chain transactions on Ethereum, including claiming and transferring SPK tokens, require the payment of network gas fees.
Gas fees are denominated in ETH and paid directly to the Ethereum network. Following the implementation of Ethereum Improvement Proposal 1559 (EIP-1559), gas fees consist of two components:
* **Base fee**:
This is automatically calculated based on current network demand and is burned, meaning it is removed from circulation.
* **Priority fee (tip)**:\
This is paid to the validator that successfully proposes the block in which the transaction is included.
Ethereum validators are incentivised through a combination of block rewards and priority fees paid in ETH. Validators who misbehave or act maliciously are subject to slashing penalties, resulting in the loss of a portion of their staked ETH.
The Offeror has no control over Ethereum blockchain fees, validator behaviour, or the consensus process.
#### S.6 Beginning of the period to which the disclosed information relates
2024-05-08
#### S.7 End of the period to which the disclosure relates
2025-05-08
#### **Mandatory key indicator on energy consumption**
#### S.8 Energy consumption
*Total amount of energy used for the validation of transactions and the maintenance of the integrity of the distributed ledger, expressed in kilowatt-hours per calendar year*
4,871,148.30 kWh
#### **Sources and methodologies**
#### S.9 Energy consumption
*Sources and methodologies used in relation to the information reported above*
The estimated energy consumption provided in Section sources and S.8 has been calculated using the CCRI Crypto methodologies Sustainability Metrics provided by the Crypto Carbon Ratings Institute (source: [https://indices.carbon-ratings.com/](https://indices.carbon-ratings.com/)).
Since the Token has not yet been created, the energy consumption pertains to the previous calendar year, as an estimate of what can be consumed during the Token’s first year by the Ethereum blockchain.
## SPK Company Ltd. - SPK Token White paper
Version 2.0 - June 2025
Edition: Markets in Crypto-Assets Regulation White Paper for European Union & European Economic Area.
Date of notification: 2025-06-11
Purpose: Offer to the public of a crypto-asset other than an asset-referenced token or e-money token.
Note: This crypto-asset white paper has not been approved by any competent authority in any Member State of the European Union. The offeror of the crypto-asset is solely responsible for the content of this crypto-asset white paper.
### Table of Contents
* [**Important Notice**](#important-notice)
* [**Warning**](#warning)
* [Characteristics of the crypto-asset](#characteristics-of-the-crypto-asset)
* [Key information about the offer to the public](#key-information-about-the-offer-to-the-public)
* [**Part I – Information on Risks**](#part-i--information-on-risks)
* [I.1 Offer-Related Risks](#i1-offer-related-risks)
* [I.2 Issuer-Related Risks](#i2-issuer-related-risks)
* [I.3 Crypto-Assets-related Risks](#i3-crypto-assets-related-risks)
* [I.4 Project Implementation-Related Risks](#i4-project-implementation-related-risks)
* [I.5 Technology-Related Risks](#i5-technology-related-risks)
* [I.6 Mitigation measures](#i6-mitigation-measures)
* [**Part A – Information About the Offeror of the Crypto-Asset**](#part-a--information-about-the-offeror-of-the-crypto-asset)
* [**Part B – Information About the Issuer, If Different from the Offeror or Person Seeking Admission to Trading**](#part-b--information-about-the-issuer-if-different-from-the-offeror-or-person-seeking-admission-to-trading)
* [**Part C – Information About the Operator of the Trading Platform**](#part-c--information-about-the-operator-of-the-trading-platform)
* [**Part D – Information About Crypto-Asset Project**](#part-d--information-about-crypto-asset-project)
* [D.8 Plans for the token](#d8-plans-for-the-token)
* [D.9 Resource Allocation](#d9-resource-allocation)
* [D.10 Planned Use of Collected Funds or Crypto-Assets](#d10-planned-use-of-collected-funds-or-crypto-assets)
* [**Part E – Information About the Offer to the Public**](#part-e--information-about-the-offer-to-the-public)
* [E.2 Reasons for Public Offer](#e2-reasons-for-public-offer)
* [Refund Mechanism](#refund-mechanism)
* [**Part F – Information About the Crypto-Assets**](#part-f--information-about-the-crypto-assets)
* [**Part G – Information on the Rights and Obligations Attached to the Crypto-Assets**](#part-g--information-on-the-rights-and-obligations-attached-to-the-crypto-assets)
* [**Part H – Information on the Underlying Technology**](#part-h--information-on-the-underlying-technology)
* [**Part J – Information on the Sustainability Indicators in Relation to Adverse Impact on the Climate and Other Environment-Related Adverse Impacts**](#part-j--information-on-the-sustainability-indicators-in-relation-to-adverse-impact-on-the-climate-and-other-environment-related-adverse-impacts)
### IMPORTANT NOTICE
Please carefully review the following notice before proceeding. This notice applies to the entire white paper, regardless of how you received it, whether by email, website access, or any other form of electronic communication. By accessing, reviewing, or otherwise using this white paper, you expressly acknowledge and agree to comply with all terms, conditions, and restrictions outlined herein, including any updates or supplements provided from time to time.
This crypto-asset white paper complies with Title II of Regulation (EU) 2023/1114 (“MiCA”) and, to the best of the knowledge of the management body, the information presented in the crypto-asset white paper is fair, clear and not misleading and the crypto-asset white paper makes no omission likely to affect its import.
The crypto-asset referred to in the White Paper may lose its value partially or in full, may not always be transferable and may not be liquid.
The crypto-asset referred to in this white paper is not covered by the investor compensation schemes under Directive 97/9/EC of the European Parliament and of the Council.
The crypto-asset referred to in this white paper is not covered by the deposit guarantee schemes under Directive 2014/49/EU of the European Parliament and of the Council.
### WARNING
This summary should be read as an introduction to the crypto-asset white paper (the “White Paper”). The offer to the public of this crypto-asset does not constitute an offer or solicitation to purchase financial instruments, and any such offer or solicitation can be made only by means of a prospectus or other offer documents pursuant to the applicable national law.
This crypto-asset white paper does not constitute a prospectus as referred to in Regulation (EU) 2017/1129 of the European Parliament and of the Council (36) or any other offer document pursuant to Union or national law.
### Characteristics of the crypto-asset
SPK is a fungible crypto-asset issued on the Ethereum blockchain, designed for use within the Spark ecosystem. It does not represent ownership, profit rights, or a claim against the Offeror. SPK tokens can be freely held, transferred, and used in accordance with the functionalities described in this White Paper.
Holders of SPK may be entitled to participate in decentralised governance, access staking mechanisms, or engage in incentive-based activities, subject to eligibility criteria and the availability of such functionalities. All such rights are exercised through the Spark application or associated interfaces, or direct interaction with the blockchain, using a self-custodied blockchain wallet.
The exercise of rights requires active engagement by the holder and may involve network transaction fees (gas fees) payable to the Ethereum blockchain. SPK token holders are responsible for maintaining access to their wallet and acting in accordance with the Spark protocol.
The rights and obligations associated with SPK tokens may be modified in the future only through valid governance decisions adopted in accordance with the decentralised governance framework of the Spark protocol. That framework will reflect certain requirements, guidelines and practices derived from Sky governance and the Sky Atlas. Any material change to SPK token functionalities or holder rights will be communicated in accordance with Article 12 of MiCA and reflected in an updated version of this White Paper.
### Key information about the offer to the public
This White Paper relates to the public offering of SPK tokens. The offer consists of multiple distribution phases during which eligible users may claim SPK tokens, subject to conditions described in this document. No payment is required from eligible holders to participate in the offering, and no subscription or placement fees are charged by the Offeror.
The total number of SPK tokens available through this offer is capped at 710,000,000, representing the full allocation set aside for public distribution. There is no minimum or maximum subscription target, and no discounted purchase prices or bonuses for early participants apply, as SPK tokens are distributed without monetary consideration.
The offer is structured in distinct phases based on past activity and also participation in ecosystem-related campaigns. Each phase has a defined eligibility window and a claim period during which users may collect their allocated tokens via the official claiming interface. Claims are processed on-chain and subject to standard Ethereum gas fees.
This offer does not involve an issue price, as SPK tokens are not sold but offered for free to eligible participants. Additional distribution phases may be introduced in the future under this framework, and the White Paper will be updated if material changes occur.
The Offeror seeks to offer the SPK tokens to the public to increase the liquidity and distribution of the Token, facilitate more participation in governance, and increase the number of tokens in circulation.
### PART I – INFORMATION ON RISKS
#### I.1 Offer-Related Risks
Although SPK tokens are distributed without monetary payment, recipients incur potential risks relating to time, effort, and opportunity costs associated with qualifying actions. These include engaging with DeFi protocols, staking tokens, or performing specific on-chain activities.
The primary offer-related risks involve post-receipt use and trading of SPK tokens. Once listed, token value may fluctuate significantly due to market speculation, macroeconomic factors, or project developments, which can affect the perceived benefit of having received the tokens.
Low liquidity on trading venues may impair a recipient's ability to sell or use SPK tokens efficiently. Listings are not guaranteed, and the Offeror cannot ensure continued support from exchanges. A delisting or lack of market depth may result in SPK tokens being practically unusable.
Trading venues, whether decentralised or centralised, pose operational and counterparty risks.
Users may face delays, hacks, or insolvency events, which could hinder access to tokens. Neither the Spark Foundation nor the Offeror is liable for such outcomes.
Smart contract risks also exist during the claim or staking processes. Errors, vulnerabilities, or incorrect wallet use may lead to permanent loss of SPK tokens, despite the token having been free.
Finally, recipients may still incur tax liabilities on receipt, even without monetary investment. Participants must assess these risks individually and ensure compliance with local regulations.
#### I.2 Issuer-Related Risks
The Issuer's sole function is to issue and distribute SPK tokens. It does not manage or operate any technical infrastructure, oversee governance processes, or maintain control over the protocol or community.
This limited operational role means the Issuer cannot respond to technical failures, governance disputes, or security incidents within the broader ecosystem. If issues arise post-distribution such as bugs in smart contracts or shifts in network governance, the Issuer has no authority or capacity to intervene or implement corrective measures.
Furthermore, the Offeror provides no guarantees regarding the future value, usability, or development of the SPK token or the Spark ecosystem. All post-distribution developments depend on decentralised community governance or third-party contributors, over whom the Offeror has no influence.
Participants should therefore understand that their reliance on the Issuer is limited strictly to the issuance of SPK tokens. Any expectations beyond that, whether technical, economic, or governance-related, must be assessed based on the broader ecosystem's operations and risks.
#### I.3 Crypto-Assets-related Risks
As a Crypto-asset, SPK tokens carry risks inherent to digital tokens built on public blockchains. These risks are present regardless of whether a token is purchased or received for free.
SPK operates on the Ethereum network and is subject to blockchain-related vulnerabilities. Network congestion, outages, or high transaction fees could impact users’ ability to claim, transfer, or use SPK tokens in a timely or cost-effective manner.
The token's value is also highly volatile. While there is no direct financial cost to acquiring SPK tokens through airdrops or qualifying actions, token holders may still face opportunity costs if the value declines sharply or if the token becomes unusable due to low adoption or regulatory constraints.
Smart contract vulnerabilities pose another key risk. Even audited contracts can contain bugs or be exploited. Losses stemming from contract-level attacks could affect staking, transfers, or functionality tied to SPK tokens.
Custody of SPK tokens requires secure private key management. Loss or theft of private keys will result in irreversible loss of tokens. Participants are solely responsible for securing their wallet access and recovery information.
SPK token holders may also be targeted by fraud, phishing attacks, or scams that impersonate the Offeror or promote counterfeit tokens. Engaging with unverified links, dApps, or communications could result in loss of assets.
Finally, evolving regulations in different jurisdictions may restrict use or access to SPK, especially if the token is later deemed to fall within specific legal classifications. This could limit its utility or expose holders to compliance obligations.
#### I.4 Project Implementation-Related Risks
The long-term success of SPK is closely tied to the ongoing implementation of the broader Spark project. This process faces a number of technical, operational, and strategic risks.
Technical risks include the potential for bugs or vulnerabilities in smart contracts, governance modules, or infrastructure upgrades. Even with careful development and auditing, errors could affect token functionality or user funds.
Operational risks arise from the allocation of resources, including developer attention, treasury funding, and community engagement. If these are insufficient or misaligned, project timelines may slip or core features may never be completed.
The project’s governance and roadmap are shaped by a decentralised community. This structure can result in slow decision-making, conflicting interests, or even governance capture, where a small group steers development against the broader community's interests.
Adoption risk is also significant. SPK tokens’ utility depends on community participation and real-world integrations. Without active use and credible demand for the Spark ecosystem’s services, the token’s role and relevance may diminish.
In addition, external dependencies such as integration with third-party protocols, platforms, and infrastructure providers can introduce delays or disruptions. Any instability or failure in these components could stall project delivery or impair functionality.
Finally, the broader regulatory and technological environment can shift rapidly. Changes in crypto-asset regulation, competition from new technologies, or loss of ecosystem partners may materially alter the implementation trajectory of the project.
#### I.5 Technology-Related Risks
SPK relies on blockchain infrastructure and smart contract technology that is still evolving. These underlying technologies present several risks that could affect the SPK token's security, performance, and usability.
Distributed ledger networks like the Ethereum blockchain may experience congestion, downtime, or forks, all of which can disrupt token transfers or contract interactions. In extreme cases, users may lose access to their tokens or experience unexpected delays or errors.
Smart contracts governing SPK token-related operations are immutable once deployed. Security flaws or exploits may be used to manipulate SPK token transfers, staking mechanisms, or governance processes.
Token holders are fully responsible for managing their private keys. Mistakes in wallet configuration or loss of access credentials result in permanent token loss, as transactions on the blockchain are irreversible.
Compatibility and access risks may arise if wallet software becomes outdated, unsupported, or incompatible with new SPK token upgrades or infrastructure. Users relying on specific platforms may lose access if those platforms shut down or fail to update their systems.
Moreover, SPK tokens depend on integrations with third-party services like decentralised exchanges, bridges, oracles, and custodians. Failures, security breaches, or regulatory actions affecting these services could degrade SPK tokens’ functionality or cause temporary inaccessibility.
The SPK token is also exposed to long-term risks from technological disruption. Innovations such as quantum computing could weaken cryptographic systems securing blockchain networks. While such risks remain largely theoretical, they could undermine user confidence or lead to structural changes in the network.
In summary, while the SPK ecosystem employs best practices in smart contract development and network integration, the rapidly changing technological landscape presents ongoing risks that may affect security, accessibility, and user experience.
#### I.6 Mitigation measures
To address the range of risks associated with SPK, the project has implemented multiple mitigation strategies across technical, operational, and governance layers.
* **Smart Contract Audits** **–** All critical contracts are subject to external audits by reputable security firms. Audits help identify vulnerabilities before deployment and reduce the likelihood of exploitation. Previous audits are accessible at [http://docs.spark.fi/dev/security/security-and-audits](http://docs.spark.fi/dev/security/security-and-audits).
* **Progressive rollout** **–** SPK token distribution and product features are introduced gradually to allow for testing and feedback, minimising systemic risk and improving resilience.
* **Decentralised Governance** **–** SPK token governance is structured through community mechanisms, including SparkDAO and SkyDAO governance. This provides checks and balances, limits centralised control, and enables dynamic adaptation to new risks.
* **Transparent communication** **–** Ongoing disclosures via public documentation, white paper updates, forums, and governance proposals foster community awareness and help participants make informed decisions.
* **Liquidity support and listings –** While no guarantee is provided, the Offeror may collaborate with market participants to encourage liquidity provision and exchange listings where feasible.
* **Regulatory Alignment** **–** The project tracks legal developments in key jurisdictions to align with regulatory frameworks, particularly those under MiCA.
These measures do not eliminate risk, but they significantly reduce the likelihood or severity of adverse events. Participants should still exercise caution and adopt personal risk management strategies when engaging with SPK tokens or the broader Spark ecosystem.
### PART A – INFORMATION ABOUT THE OFFEROR OF THE CRYPTO-ASSET
#### A.1 Name
SPK Company Ltd.
#### A.2 Legal Form
Company limited by shares
#### A.3 Registered address
SHRM Trustees (BVI) Limited of Trinity Chambers, PO Box 4301.
#### A.4 Head office
Road Town, Tortola, British Virgin Islands
#### A.5 Registration Date
2025-02-19
#### A.6 Legal entity identifier
Not available
#### A.7 Another identifier required pursuant to applicable national law
2170013
#### A.8/9/10 Contacting the Offeror
The Offeror can be contacted by telephone or email using the details provided below. The Offeror will respond within 14 business days.
Glenn Kennedy: [gkennedy@leewardmanagement.ky](mailto\:gkennedy@leewardmanagement.ky)
Marc Piano: [piano@horizonsglobal.io](mailto\:piano@horizonsglobal.io)
Telephone number: +1 345-749-9601 Email address:
The Offeror does not have a website. The website of the project is [https://spark.fi/](https://spark.fi/).
#### A.11 Parent Company
Spark Foundation
#### A.12 Identity of the management body
The sole director of the Offeror is Spark Foundation
The directors of Spark Foundation are Glenn Kennedy and Marc Piano
Business address of Spark Foundation is Leeward Management Limited, Suite 3119, 9 Forum Lane, Camana Bay, PO Box 144, George Town, Grand Cayman KY1-9006, Cayman Islands
#### A.13 Business activity
The only purpose is to issue and distribute the Token.
#### A.14 Parent Company Business Activity
To support, promote, and advance the development, adoption, security, and growth of Spark.
#### A.15 Newly Established
true
#### A.16 Financial condition for the past three years
The Offeror is a newly incorporated company with no material liabilities as of the date of this White Paper. The Offeror will be capitalised as needed to fulfil its mandate of issuing SPK tokens and distributing them.
#### A.17 Financial condition since registration
The Offeror is a newly incorporated company with no material liabilities as of the date of this White Paper. The Offeror will be capitalised as needed to fulfil its mandate of issuing SPK tokens and distributing them.
### PART B – INFORMATION ABOUT THE ISSUER, IF DIFFERENT FROM THE OFFEROR OR PERSON SEEKING ADMISSION TO TRADING
This section is not applicable. Part B does not apply as the issuer and the offeror are the same legal entity.
### PART C – INFORMATION ABOUT THE OPERATOR OF THE TRADING PLATFORM
This section is not applicable. No trading platform has drawn up or contributed to the preparation of this White Paper.
### PART D – INFORMATION ABOUT CRYPTO-ASSET PROJECT
#### D.1 Crypto-asset project name
Spark
#### D.2 Crypto-asset name
Spark
#### D.3 Abbreviation
SPK
#### D.4 Crypto-asset project description
The project is a DeFi protocol, which emerged from Sky, previously known as MakerDAO, and serves as a ‘Sky Star’, a subDAO within the Sky ecosystem. It consists of three main components: SparkLend, a stablecoin lending market; Spark Savings, for earning yield on certain stablecoins; and Spark Liquidity Layer, a backend capital allocator that routes liquidity across select DeFi protocols.
#### D.5 Details of all natural or legal persons involved in the implementation of the crypto-asset project
SPK Company, Ltd.
c/o SHRM Trustee (BVI) Ltd.
Trinity Chambers
PO Box 4301
Road Town, Tortola, British Virgin Islands
Spark Foundation
c/o Leeward Management Limited
Suite 3119, 9 Forum Lane Camana Bay, George Town,
Grand Cayman KY1-9006, Cayman Islands
#### D.6 Utility token classification
false
#### D.7 Key Features of Goods/Services for Utility Token Projects
Not applicable
#### D.8 Plans for the token
The SPK token is designed to function as a cornerstone of the Spark ecosystem, enabling long-term value creation through decentralised incentives, participation, and infrastructure support. SPK is distributed without monetary consideration and built with clear alignment between user effort and ecosystem growth.
##### **Community-Driven Distribution**
SPK token’s distribution model prioritises organic community involvement. Tokens are allocated via airdrops, on-chain activity, and reward mechanisms tied to meaningful user engagement.
These distribution channels are permissionless, performance-based and structured to encourage use among committed participants.
##### **Protocol Utility and Staking**
SPK tokens are expected to play a role in supporting the reliability and functionality of the Spark protocol over time. SPK token holders may be given the option to stake their SPK to contribute to the network's resilience or participate in reward systems. Staking mechanisms could be linked to protocol components such as cross-chain infrastructure or security features, although specifics may evolve based on governance decisions and technical development. Staking may involve time-bound commitments, and rewards, if any, will reflect the level of engagement and the function being supported.
##### **Incentive structures**
The token design incorporates the possibility of allocating SPK tokens to participants who contribute to the ecosystem’s growth and operational soundness. This may include users who interact with infrastructure components, provide liquidity, or contribute to early adoption efforts. These measures aim to foster long-term engagement.
##### **Governance Engagement**
SPK tokens may also function as a governance tool, enabling holders to take part in decentralised decision-making processes. These could include discussions and votes on treasury use, protocol evolution, or other strategic priorities. The governance model is intended to be adaptable, subject to community feedback and emerging needs.
##### **Future Outlook**
As the Spark project grows, SPK tokens may become relevant in additional modules or integrations, including those related to cross-chain operations, coordination layers, or service modules. These developments will be introduced incrementally and in alignment with broader ecosystem goals.
The vision for SPK tokens is to support a sustainable, community-driven network. Its role is not fixed but is intended to reflect the evolving needs of a decentralised ecosystem prioritising fairness, resilience, and meaningful engagement.
#### D.9 Resource Allocation
The Spark ecosystem incorporates a structured approach to resource allocation, aimed at ensuring long-term operational sustainability and adaptability. SPK tokens are reserved across specific categories to support development, governance, and ecosystem initiatives.
A dedicated share of the SPK token supply is earmarked for operational costs, reflecting the ongoing need to maintain infrastructure, support contributors, and cover administrative requirements. Additionally, Spark will receive initial grant funding from Sky to help bootstrap Spark’s growth. These resources enable the protocol to remain functional and responsive without immediate reliance on external funding.
In parallel, a treasury allocation is established to provide flexibility over time. This reserve is governed by community processes and may be used to support future proposals, ecosystem incentives, or strategic partnerships.
The resource model aligns token distribution with the needs of a dynamic and participatory ecosystem, allowing SPK tokens to function as a mechanism for funding public goods and sustaining the protocol over time.
#### D.10 Planned Use of Collected Funds or Crypto-Assets
The offer to the public will take place without raising funds or accepting any crypto-assets, as outlined in Section E.
### PART E – INFORMATION ABOUT THE OFFER TO THE PUBLIC
#### E.1 Public Offering
OTPC
#### E.2 Reasons for Public Offer
The public offer of SPK tokens is intended to initiate the launch of the Spark project and to incentivise early engagement with the Spark protocol. The offer is designed to encourage the use of its services and to establish a decentralised and active user base from the outset. The tokens will be distributed without collecting any funds or crypto-assets from participants. Instead, the offer is structured around non-monetary contribution mechanisms such as protocol usage, on-chain activity, staking engagement, and other qualifying actions.
Tokens are provided free of charge or in exchange for specific actions that demonstrate interest or involvement in the ecosystem. These distribution mechanisms include airdrops based on past engagement, performance-based eligibility, and participation in pre-defined incentive programs as specified in more detail in section E.18.
The public offer is not intended as a capital-raising measure and does not involve the collection of funds or crypto-assets. Accordingly, no proceeds will be received by the Offeror or any affiliated entity in connection with the distribution of SPK tokens. The offer is exclusively designed to support the initial development of a decentralised user base by allocating tokens to participants on the basis of non-financial contributions. The Offeror does not intend to derive any financial gain from the offer, and the distribution is structured to ensure compliance with applicable regulatory exemptions concerning public offerings without consideration.
#### E.3 Fundraising target
Not applicable
#### E.4 Minimum Subscription Goal
Not applicable
#### E.5 Maximum Subscription Goal
Not applicable
#### E.6 Oversubscription Acceptance
false
#### E.7 Oversubscription Allocation
Not applicable
#### E.8 Issue Price
€0
#### E.9 Official currency or any other crypto-assets determining the issue price
Not applicable
#### E.10 Subscription fee
€0
#### E.11 Offer Price Determination Method
The SPK tokens will be allocated without consideration and exclusively based on demonstrable user actions or prior holdings. No monetary payment or transfer of crypto-assets is required or accepted in exchange for the receipt of SPK tokens.
#### E.12 Total Number of Offered Crypto-Assets
710,000,000 SPK tokens
#### E.13 Targeted Holders
ALL
#### E.14 Holder restrictions
The offer of SPK tokens is not subject to any general restriction with respect to the type of recipient. However, the distribution is limited to individuals and entities that are not subject to applicable sanctions or other regulatory prohibitions. The Offeror reserves the right to exclude from eligibility any user or wallet address that is reasonably believed to be associated with a jurisdiction, entity, or individual subject to relevant restrictions under applicable law. Further, any user or wallet address reasonably suspected of being a Sybil wallet or involved in fraudulent, manipulative, or malicious activity may be excluded from participation in the offer. Users are responsible for ensuring that their receipt and holding of SPK tokens are lawful in their respective jurisdictions.
Participants must self-certify that they are not residents of, or otherwise located in, any jurisdiction where the receipt or holding of crypto-assets is restricted or prohibited.
#### E.15
Purchasers participating in the offer to the public of crypto-asset will be able to be reimbursed if the minimum target subscription goal is not reached at the end of the offer to the public, if they exercise the right to withdrawal foreseen in Article 13 of Regulation (EU) 2023/1114 or if the offer is cancelled.
#### E.16 Refund Mechanism
Pursuant to Article 13 of MiCA, retail holders who have agreed to receive SPK tokens from the Offeror shall have a right to withdraw from such agreement within a period of 14 calendar days from the date of such agreement, without giving any reason and without incurring any costs.
Retail holders may exercise their right of withdrawal by following the process available at [www.spark.fi/mica](http://www.spark.fi/mica). The notice must be submitted no later than 14 calendar days after the date on which the agreement to acquire SPK tokens was concluded.
Upon receiving the withdrawal notice, the Offeror will provide the retail holder with a blockchain address to which the tokens must be returned.
##### **Return of Tokens and Reimbursement**
The retail holder shall return the acquired SPK tokens to the Offeror without undue delay and no later than 14 calendar days after submitting the withdrawal notice. As no monetary payment was made by the holder, no reimbursement shall be due. Due to this, the tokens shall be returned and the agreement voided without further obligation from either party.
The Offeror will not impose any fee or penalty in connection with the exercise of the right of withdrawal. Gas fees incurred on-chain in connection with the return of tokens shall be borne by the retail holder unless otherwise agreed.
#### E.17 Refund Timeline
The designated refund wallet address shall be made available to the holder upon receipt of the withdrawal notice and shall remain available for the return of tokens for a minimum period of 14 calendar days thereafter.
#### E.18 Offer Phases
The public offering of SPK tokens will occur in separate phases, each designed to distribute tokens to distinct participant groups based on eligibility criteria and pre-defined allocation methodologies. Claims will be made available via on-chain claiming interfaces following the Token Generation Event (TGE), with each phase subject to its own claiming window.
##### **Phase 1**:
This phase includes distributions to early participants who interacted with designated DeFi protocols prior to the TGE. Allocation is based on historic on-chain activity, with protocol-specific criteria and anti-sybil measures applied. Eligible users may claim their tokens starting at TGE for a limited duration.
##### **Phase 2**:
This phase encompasses broader ecosystem distribution based on historical activity across multiple chains, platforms and applications. Allocations are determined using a point-based system reflecting user exposure to selected assets and protocols. Eligibility is non-transferable and fixed prior to the TGE. The claiming period for this phase begins at TGE and concludes following a pre-defined window.
##### **Phase 3**:
This phase involves distribution to participants in Spark’s post-TGE ecosystem campaigns, including social and engagement-based reward initiatives. Participants may earn eligibility by completing campaign tasks or interacting with designated applications. Each campaign includes an earning period and a subsequent claim window. Unclaimed tokens after the claim period expires will revert to the treasury.
All phases are subject to eligibility verification, including sanctions screening and wallet verification. Tokens may only be claimed via the official interface during the applicable claiming window.
Eligibility criteria and claiming instructions for each phase will be published on the official claiming interface on Spark’s website, [spark.fi](http://spark.fi/), prior to the commencement of the relevant claiming window.
This white paper covers a continuous offering of SPK tokens through multiple time-limited phases. Each phase has a defined claim period, but the Offeror may initiate additional distribution phases in the future under the same framework. The offer shall remain open for purposes of MiCA Article 10(2) until otherwise stated, and the number of tokens in circulation will be published at least monthly on the Offeror’s website.
In the event that future phases are materially different from those described herein, whether in terms of structure or claiming mechanisms, the Offeror will update and notify the white paper in accordance with MiCA Article 12 prior to the commencement of such phases.
#### E.19 Early Purchase Discount
Not applicable.
#### E.20 Time-limited offer
false
#### E.21 Subscription period beginning
Not applicable
#### E.22 Subscription period end
Not applicable
#### E.23 Safeguarding Arrangements for Offered Funds/Crypto-Assets
Not applicable
#### E.24 Payment Methods for Crypto-Asset Purchase
The SPK tokens are offered without payment of any monetary benefit, but based on pre-defined actions and on-chain activity.
#### E.25 Value Transfer Methods for Reimbursement
No reimbursement shall be due.
#### E.26 Right of Withdrawal
In accordance with Article 13 of MiCA, any retail holder who enters into an agreement to acquire SPK tokens as part of this public offering shall have the right to withdraw from the agreement within a period of 14 calendar days from the date of such agreement, without giving any reason and without incurring any cost.
Retail holders may exercise it by following the process outlined under Refund Mechanism.
#### E.27 Transfer of Purchased Crypto-Assets
Upon satisfying the eligibility criteria for a given phase of the offer, SPK tokens will become claimable by the eligible holder at or after the TGE. Tokens will be made available via an on-chain claiming mechanism, and holders must actively claim their allocation through the designated interface.
Upon successful claiming, the SPK tokens will be transferred to the holder’s self-custodied wallet address, at which point the holder obtains full control and ability to transfer, subject to applicable legal or contractual restrictions with wallet provider. There are no transfer restrictions imposed by the Offeror following delivery, unless otherwise stated in this White Paper.
#### E.28 Transfer Time Schedule
SPK tokens will become claimable by eligible holders in accordance with any claiming schedules announced on Spark's official website. Upon claiming, tokens will be transferred in full to the holder’s wallet with no further vesting, lock-up, or time-based release restrictions imposed by the Offeror.
#### E.29 Purchaser’s Technical Requirement
To receive and hold SPK tokens, eligible holders must have access to a compatible, self-custodied wallet capable of interacting with the Ethereum blockchain, where SPK is deployed as an ERC-20 standard token.
The wallet must support:
* Secure storage of private keys and recovery phrases;
* On-chain interaction with smart contracts
(e.g., for claiming SPK tokens)
* The ability to pay applicable network transaction fees (gas) in the native blockchain token, ETH.
The Offeror does not provide wallet infrastructure or custody services. It is the sole responsibility of the eligible holder to:
* Secure their private keys;
* Ensure uninterrupted access to their wallet;
* Ensure the wallet address used for claiming is correct and under their exclusive control.
Failure to meet the above requirements may result in the holder’s inability to claim or access the SPK tokens, for which the Offeror assumes no responsibility.
#### E.30 Crypto-asset service provider (CASP) name
Not applicable
#### E.31 CASP identifier
Not applicable
#### E.32 Placement form
NTAV
#### E.33 Trading Platforms name
Not applicable
#### E.34 Trading Platforms Market Identifier Code (MIC)
Not applicable
#### E.35 Trading Platforms Access
Not applicable
#### E.36 Involved costs
Not applicable
#### E.37 Offer Expenses
No placement fees, subscription fees, or transaction fees are charged to the eligible holder by the Offeror in connection with the receipt or claiming of SPK tokens.
Eligible holders may be required to pay standard network transaction fees (gas fees) to claim their tokens via the designated on-chain interface. These fees are paid directly to the blockchain network and not retained by the Offeror.
All costs associated with the development, structuring, and execution of the offering, including legal, technical, and marketing expenses, are borne by the Offeror.
#### E.38 Conflicts of Interest
Spark Foundation is expected to receive an allocation of approximately 1 billion SPK tokens following the TGE. These SPK tokens will be used by the Spark Foundation to support protocol development, governance, ecosystem incentives, and other community-aligned initiatives. It is the assessment of the Offeror that this allocation does not give rise to a conflict of interest within the meaning of Article 14(1)(c) of MiCA, as Spark Foundation operates with a mandate to promote the long-term success of the ecosystem and not for private gain. The Offeror will continue to monitor for potential conflicts of interest on an ongoing basis and will take appropriate steps to disclose and mitigate any such conflicts should they arise.
#### E.39 Applicable law
This offering and the contractual rights and obligations arising between the Offeror and eligible holders in connection with SPK tokens shall be governed by and construed in accordance with the laws of the British Virgin Islands. Notwithstanding the above, this White Paper and the offer of SPK tokens to the public within the European Union are made in accordance with MiCA.
#### E.40 Competent court
Any dispute arising out of or in connection with this offering or the SPK tokens shall be subject to the exclusive jurisdiction of the courts of the British Virgin Islands. This is without prejudice to the rights of retail holders residing in the European Union to bring claims before the courts of their place of residence, in accordance with applicable consumer protection and private international law rules.
### PART F – INFORMATION ABOUT THE CRYPTO-ASSETS
#### F.1 Crypto-Asset Type
Crypto-asset other than an asset-referenced token or e-money token.
#### F.2 Crypto-Asset Functionality
SPK token is a fungible crypto-asset within the meaning of Article 3(1)(5) of MiCA. It does not qualify as an asset-referenced token (ART) or e-money token (EMT) under MiCA and is offered to the public under the Title II framework.
SPK token is implemented as a standard ERC-20 token on the Ethereum blockchain and is freely transferable following its delivery to the holder, subject to any applicable legal or contractual restrictions described in this White Paper.
SPK token is designed primarily for the use within Spark ecosystem, including participation in governance, reward programs, and future protocol-based activities. It does not represent a financial claim or entitlement to any underlying asset, nor does it confer ownership or profit rights in the Offeror or any affiliated entity.
#### F.3 Planned Application of Functionalities
At the time of publishing this White Paper, the SPK token’s core functionalities are described below and will be made available progressively after Offering:
* **Governance**: SPK token holders will be able to participate in the governance of the Spark protocol. This may include the right to vote on proposals concerning matters like protocol parameters, treasury allocation, grant distributions, and technical upgrades. Governance mechanisms will evolve under a decentralised governance model managed via the SparkDAO.
* **Staking**: SPK tokens may be staked by holders. In return for staking, participants may earn rewards. The staking mechanism is governed by smart contracts and requires the transfer of SPK tokens to a dedicated staking contract.
* **Rewards and Incentives**: SPK tokens will be distributed as part of airdrop campaigns and incentive programmes as described in this White Paper. These may include rewards for early use of DeFi products within the Spark application. In addition, SPK tokens may be used in future farming mechanisms or liquidity incentives across various Spark-related services.
All functionalities are accessible through the Spark application or approved interfaces. Certain features, such as staking and voting, may be made available in phases, with implementation timelines subject to further governance decisions. Any material updates to the functionalities or use of SPK tokens will be reflected through updates to this white paper in accordance with MiCA Article 12.
**A description of the characteristics of the crypto-asset, including the data necessary for classification of the crypto-asset white paper in the register referred to in Article 109 of Regulation (EU) 2023/1114, as specified in accordance with paragraph 8 of that Article**
#### F.4 Type of white paper
OTHR
#### F.5 The type of submission
MODI
#### F.6 Crypto-asset Characteristics
See Part D and Section F.2.
#### F.7 Commercial name or trading
Spark / SPK token name
#### F.8 Website of the issuer
The Issuer does not have a website.
The website of the project is [https://spark.fi/](https://spark.fi/).
#### F.9 Starting date of offer to the public or admission to trading
2025-06-17
#### F.10 Publication date
2025-06-20
#### F.11 Any other services provided by the issuer
The Offeror does not offer any other services covered by MiCA
#### F.12 Identifier of operator of the trading platform
Not applicable
#### F.13 Language or languages of the white paper
English
#### F.14 Digital Token Identifier Code used to uniquely identify the crypto-asset or each of the several crypto-assets to which the white paper relates, where available
SPK
#### F.15 Functionally Fungible Group Digital Token Identifier, where available
Not applicable
#### F.16 Voluntary data flag
false
#### F.17 Personal data flag
true
#### F.18 LEI eligibility
false
#### F.19 Home Member State
Denmark
#### F.20 Host Member States
The offer to the public of SPK tokens is passported to the following countries:
* Austria
* Belgium
* Bulgaria
* Croatia
* Cyprus
* Czech Republic
* Estonia
* Finland
* France
* Germany
* Greece
* Hungary
* Iceland
* Ireland
* Italy
* Latvia
* Liechtenstein
* Lithuania
* Luxembourg
* Malta
* Netherlands
* Norway
* Poland
* Portugal
* Romania
* Slovakia
* Slovenia
* Spain
* Sweden
### PART G – INFORMATION ON THE RIGHTS AND OBLIGATIONS ATTACHED TO THE CRYPTO-ASSETS
#### G.1 Purchaser Rights and Obligations
Upon receipt of SPK tokens, holders are granted the right to hold, transfer, and utilise the tokens in accordance with the functionalities set out in this White Paper. Where implemented, such functionalities may include the ability to participate in governance processes and protocol-level decision-making, as well as to access certain staking or reward mechanisms as described herein.
SPK tokens do not confer on holders any ownership interest, profit-sharing rights, equity claims, or creditor rights against the Offeror. The tokens do not represent financial instruments, electronic money, or asset-referenced tokens within the meaning of MiCA.
SPK token holders shall be solely responsible for maintaining secure custody of their private keys, ensuring accurate and timely use of the designated claiming interface, and bearing any applicable network transaction fees incurred during claiming, transferring, or using SPK tokens. Token holders must also ensure compliance with any applicable legal, regulatory, or tax obligations in their jurisdiction of residence. No additional rights or obligations are imposed on holders beyond those expressly described in this White Paper.
#### G.2 Exercise of Rights and obligations
The rights associated with SPK tokens may be exercised exclusively through the designated blockchain interfaces, smart contracts, or governance mechanisms made available. Access to these rights requires that the SPK token holder maintains control over a compatible self-custodied wallet and engages directly with the supported interfaces.
Participation in governance, staking, or any reward-based functionality shall be subject to the technical implementation of such features and any applicable eligibility conditions, timelines, or procedural requirements as further communicated via official channels of the Spark ecosystem.
The obligations of SPK token holders, including the payment of any network fees and compliance with applicable legal requirements, are to be fulfilled independently and at the sole responsibility of the holder.
#### G.3 Conditions for modifications of rights and obligations
The rights and obligations associated with SPK tokens may be modified in the future as a result of governance decisions adopted in accordance with the decentralised governance framework of the Spark protocol. Such modifications may include changes to token functionalities, staking parameters, voting mechanisms, or eligibility criteria for participation in network incentives.
The Offeror does not retain unilateral discretion to amend the rights or obligations of retail holders after the issuance of SPK tokens. Any material change to the governance structure or token utility will be subject to the governance procedures established within the Spark ecosystem, including proposal submission, voting thresholds, and quorum requirements, as applicable.
#### G.4 Future Public Offers
At the time of publication of this white paper, the Offeror does not have any confirmed plans for future public offers of SPK tokens. Should the Offeror initiate any such offering in the future, a separate or updated white paper will be prepared, notified to the competent authority, and published in accordance with Article 12 of MiCA.
#### G.5 Issuer Retained Crypto-Assets
0
#### G.6 Utility Token Classification
false
#### G.7 Key Features of Goods/Services of Utility Tokens
Not applicable
#### G.8 Utility Token Redemption
Not Applicable
#### G.9 Non-Trading request
true
#### G.10 Crypto-Assets purchase or sale modalities
Not applicable
#### G.11 Crypto-Assets Transfer Restrictions
The Offeror does not impose any transfer restrictions.
#### G.12 Supply Adjustment Protocols
false
#### G.13 Supply Adjustment Mechanisms
SPK does not currently have any automatic or algorithmic supply adjustment mechanisms linked to market demand. There is no pre-programmed rebasing, burning, or minting functionality designed to increase or decrease the token supply based on price or demand fluctuations.
However, the total supply of SPK may be increased in the future through governance proposals adopted by the SkyDAO, the decentralised governance structure associated with the Spark protocol. Any such supply adjustment would be subject to the applicable governance rules and would require approval through the established voting procedures.
#### G.14 Token Value Protection Scheme
false
#### G.15 Token Value Protection Schemes Description
Not applicable
#### G.16 Compensation Schemes
false
#### G.17 Compensation Schemes Description
Not applicable
#### G.18 Applicable law
This white paper, and any contractual rights and obligations arising in connection with the receipt and use of SPK tokens, shall be governed by and construed in accordance with the laws of the British Virgin Islands.
#### G.19 Competent court
Any dispute arising out of or in connection with this offering shall be subject to the exclusive jurisdiction of the courts of the British Virgin Islands.
This is without prejudice to the rights of retail holders who are natural persons and habitually resident in a Member State of the European Union to bring proceedings before the courts of their place of residence, in accordance with applicable EU consumer protection and private international law rules.
### Part H – INFORMATION ON THE UNDERLYING TECHNOLOGY
#### H.1 Distributed ledger technology
SPK token is deployed on the Ethereum mainnet, a public and permissionless distributed ledger based on blockchain technology. The token is implemented via a set of smart contracts deployed to Ethereum and is accessible to any compatible wallet.
#### H.2 Protocols and technical
SPK tokens conform to the ERC-20 token standard standards and interacts with Ethereum-compatible smart contracts to facilitate distribution, claiming, staking, and governance. Token transfers, approvals, and other on-chain operations follow the established ERC-20 interface.
#### H.3 Technology Used
As an ERC-20 token, the SPK token will be deployed as a smart contract on the Ethereum blockchain. Users can manage the SPK tokens through their own non-custodial wallet software provided by third parties or by interacting directly with the SPK token’s smart contract through a third-party API.
#### H.4 Consensus Mechanism
The SPK token is deployed on the Ethereum blockchain. Ethereum operates using a Proof of Stake (PoS) consensus mechanism, wherein network validators are selected based on staked ETH to confirm transactions and propose new blocks.
#### H.5 Incentive Mechanisms and Applicable Fees
SPK token holders may earn SPK tokens as rewards through staking or participation in Spark ecosystem activities, as described in this White Paper.
The Offeror does not charge any placement or transaction fees in connection with the receipt or use of SPK tokens. However, all on-chain transactions on Ethereum, including claiming and transferring SPK tokens, require the payment of network gas fees.
Gas fees are denominated in ETH and paid directly to the Ethereum network. Following the implementation of Ethereum Improvement Proposal 1559 (EIP-1559), gas fees consist of two components:
* **Base fee**:\
This is automatically calculated based on current network demand and is burned, meaning it is removed from circulation.
* **Priority fee (tip)**:\
This is paid to the validator that successfully proposes the block in which the transaction is included.
Ethereum validators are incentivised through a combination of block rewards and priority fees paid in ETH. Validators who misbehave or act maliciously are subject to slashing penalties, resulting in the loss of a portion of their staked ETH.
The Offeror has no control over Ethereum blockchain fees, validator behaviour, or the consensus process.
#### H.6 Use of Distributed Ledger Technology
false
#### H.7 DLT Functionality Description
Not applicable
#### H.8 Audit
false
#### H.9 Audit outcome
Not applicable
#### PART J – INFORMATION ON THE SUSTAINABILITY INDICATORS IN RELATION TO ADVERSE IMPACT ON THE CLIMATE AND OTHER ENVIRONMENT-RELATED ADVERSE IMPACTS
#### General information
#### S.1 Name
SPK Company Ltd
#### S.2 Relevant legal entity identifier
*Identifier stated to in section A*
Not available
#### S.3 Name of the crypto-asset
*Name of the crypto-asset as stated to in section A*
Spark / SPK
#### S.4 Consensus Mechanism
The SPK token is deployed on the Ethereum blockchain. *The consensus mechanism,* Ethereum operates using a Proof of Stake (PoS) *as stated in Section H* consensus mechanism, wherein network validators are selected based on staked ETH to confirm transactions and propose new blocks.
#### S.5 Incentive Mechanisms and Applicable Fees
*Incentive mechanisms to secure transactions and any fees applicable as stated in section H.*
SPK token holders may earn SPK tokens as rewards through staking or participation in Spark ecosystem activities, as described in this White Paper.
The Offeror does not charge any placement or transaction fees in connection with the receipt or use of SPK tokens. However, all on-chain transactions on Ethereum, including claiming and transferring SPK tokens, require the payment of network gas fees.
Gas fees are denominated in ETH and paid directly to the Ethereum network. Following the implementation of Ethereum Improvement Proposal 1559 (EIP-1559), gas fees consist of two components:
* **Base fee**:
This is automatically calculated based on current network demand and is burned, meaning it is removed from circulation.
* **Priority fee (tip)**:\
This is paid to the validator that successfully proposes the block in which the transaction is included.
Ethereum validators are incentivised through a combination of block rewards and priority fees paid in ETH. Validators who misbehave or act maliciously are subject to slashing penalties, resulting in the loss of a portion of their staked ETH.
The Offeror has no control over Ethereum blockchain fees, validator behaviour, or the consensus process.
#### S.6 Beginning of the period to which the disclosed information relates
2024-05-08
#### S.7 End of the period to which the disclosure relates
2025-05-08
#### **Mandatory key indicator on energy consumption**
#### S.8 Energy consumption
*Total amount of energy used for the validation of transactions and the maintenance of the integrity of the distributed ledger, expressed in kilowatt-hours per calendar year*
4,871,148.30 kWh
#### **Sources and methodologies**
#### S.9 Energy consumption
*Sources and methodologies used in relation to the information reported above*
The estimated energy consumption provided in Section sources and S.8 has been calculated using the CCRI Crypto methodologies Sustainability Metrics provided by the Crypto Carbon Ratings Institute (source: [https://indices.carbon-ratings.com/](https://indices.carbon-ratings.com/)).
Since the Token has not yet been created, the energy consumption pertains to the previous calendar year, as an estimate of what can be consumed during the Token’s first year by the Ethereum blockchain.
## SPK Company Ltd. - SPK Token White paper
Version 3.0 - July 2025
Edition: Markets in Crypto-Assets Regulation White Paper for European Union & European Economic Area.
Date of notification: 2025-06-11
Purpose: Offer to the public of a crypto-asset other than an asset-referenced token or e-money token.
Note: This crypto-asset white paper has not been approved by any competent authority in any Member State of the European Union. The offeror of the crypto-asset is solely responsible for the content of this crypto-asset white paper.
### Table of Contents
* [**Important Notice**](#important-notice)
* [**Warning**](#warning)
* [Characteristics of the crypto-asset](#characteristics-of-the-crypto-asset)
* [Key information about the offer to the public](#key-information-about-the-offer-to-the-public)
* [**Part I – Information on Risks**](#part-i--information-on-risks)
* [I.1 Offer-Related Risks](#i1-offer-related-risks)
* [I.2 Issuer-Related Risks](#i2-issuer-related-risks)
* [I.3 Crypto-Assets-related Risks](#i3-crypto-assets-related-risks)
* [I.4 Project Implementation-Related Risks](#i4-project-implementation-related-risks)
* [I.5 Technology-Related Risks](#i5-technology-related-risks)
* [I.6 Mitigation measures](#i6-mitigation-measures)
* [**Part A – Information About the Offeror of the Crypto-Asset**](#part-a--information-about-the-offeror-of-the-crypto-asset)
* [**Part B – Information About the Issuer, If Different from the Offeror or Person Seeking Admission to Trading**](#part-b--information-about-the-issuer-if-different-from-the-offeror-or-person-seeking-admission-to-trading)
* [**Part C – Information About the Operator of the Trading Platform**](#part-c--information-about-the-operator-of-the-trading-platform)
* [**Part D – Information About Crypto-Asset Project**](#part-d--information-about-crypto-asset-project)
* [D.8 Plans for the token](#d8-plans-for-the-token)
* [D.9 Resource Allocation](#d9-resource-allocation)
* [D.10 Planned Use of Collected Funds or Crypto-Assets](#d10-planned-use-of-collected-funds-or-crypto-assets)
* [**Part E – Information About the Offer to the Public**](#part-e--information-about-the-offer-to-the-public)
* [E.2 Reasons for Public Offer](#e2-reasons-for-public-offer)
* [Refund Mechanism](#refund-mechanism)
* [**Part F – Information About the Crypto-Assets**](#part-f--information-about-the-crypto-assets)
* [**Part G – Information on the Rights and Obligations Attached to the Crypto-Assets**](#part-g--information-on-the-rights-and-obligations-attached-to-the-crypto-assets)
* [**Part H – Information on the Underlying Technology**](#part-h--information-on-the-underlying-technology)
* [**Part J – Information on the Sustainability Indicators in Relation to Adverse Impact on the Climate and Other Environment-Related Adverse Impacts**](#part-j--information-on-the-sustainability-indicators-in-relation-to-adverse-impact-on-the-climate-and-other-environment-related-adverse-impacts)
### IMPORTANT NOTICE
Please carefully review the following notice before proceeding. This notice applies to the entire white paper, regardless of how you received it, whether by email, website access, or any other form of electronic communication. By accessing, reviewing, or otherwise using this white paper, you expressly acknowledge and agree to comply with all terms, conditions, and restrictions outlined herein, including any updates or supplements provided from time to time.
This crypto-asset white paper complies with Title II of Regulation (EU) 2023/1114 (“MiCA”) and, to the best of the knowledge of the management body, the information presented in the crypto-asset white paper is fair, clear and not misleading and the crypto-asset white paper makes no omission likely to affect its import.
The crypto-asset referred to in the White Paper may lose its value partially or in full, may not always be transferable and may not be liquid.
The crypto-asset referred to in this white paper is not covered by the investor compensation schemes under Directive 97/9/EC of the European Parliament and of the Council.
The crypto-asset referred to in this white paper is not covered by the deposit guarantee schemes under Directive 2014/49/EU of the European Parliament and of the Council.
### WARNING
This summary should be read as an introduction to the crypto-asset white paper (the “White Paper”). The offer to the public of this crypto-asset does not constitute an offer or solicitation to purchase financial instruments, and any such offer or solicitation can be made only by means of a prospectus or other offer documents pursuant to the applicable national law.
This crypto-asset white paper does not constitute a prospectus as referred to in Regulation (EU) 2017/1129 of the European Parliament and of the Council (36) or any other offer document pursuant to Union or national law.
### Characteristics of the crypto-asset
SPK is a fungible crypto-asset issued on the Ethereum blockchain, designed for use within the Spark ecosystem. It does not represent ownership, profit rights, or a claim against the Offeror. SPK tokens can be freely held, transferred, and used in accordance with the functionalities described in this White Paper.
Holders of SPK may be entitled to participate in decentralised governance, access staking mechanisms, or engage in incentive-based activities, subject to eligibility criteria and the availability of such functionalities. All such rights are exercised through the Spark application or associated interfaces, or direct interaction with the blockchain, using a self-custodied blockchain wallet.
The exercise of rights requires active engagement by the holder and may involve network transaction fees (gas fees) payable to the Ethereum blockchain. SPK token holders are responsible for maintaining access to their wallet and acting in accordance with the Spark protocol.
The rights and obligations associated with SPK tokens may be modified in the future only through valid governance decisions adopted in accordance with the decentralised governance framework of the Spark protocol. That framework will reflect certain requirements, guidelines and practices derived from Sky governance and the Sky Atlas. Any material change to SPK token functionalities or holder rights will be communicated in accordance with Article 12 of MiCA and reflected in an updated version of this White Paper.
### Key information about the offer to the public
This White Paper relates to the public offering of SPK tokens. The offer consists of multiple distribution phases during which eligible users may claim SPK tokens, subject to conditions described in this document. No payment is required from eligible holders to participate in the offering, and no subscription or placement fees are charged by the Offeror.
The total number of SPK tokens available through this offer is capped at 910,000,000, representing the full allocation set aside for public distribution. There is no minimum or maximum subscription target, and no discounted purchase prices or bonuses for early participants apply, as SPK tokens are distributed without monetary consideration.
The offer is structured in distinct phases based on past activity and also participation in ecosystem-related campaigns. Each phase has a defined eligibility window and a claim period during which users may collect their allocated tokens via the official claiming interface. Claims are processed on-chain and subject to standard Ethereum gas fees.
This offer does not involve an issue price, as SPK tokens are not sold but offered for free to eligible participants. Additional distribution phases may be introduced in the future under this framework, and the White Paper will be updated if material changes occur.
The Offeror seeks to offer the SPK tokens to the public to increase the liquidity and distribution of the Token, facilitate more participation in governance, and increase the number of tokens in circulation.
### PART I – INFORMATION ON RISKS
#### I.1 Offer-Related Risks
Although SPK tokens are distributed without monetary payment, recipients incur potential risks relating to time, effort, and opportunity costs associated with qualifying actions. These include engaging with DeFi protocols, staking tokens, or performing specific on-chain activities.
The primary offer-related risks involve post-receipt use and trading of SPK tokens. Once listed, token value may fluctuate significantly due to market speculation, macroeconomic factors, or project developments, which can affect the perceived benefit of having received the tokens.
Low liquidity on trading venues may impair a recipient's ability to sell or use SPK tokens efficiently. Listings are not guaranteed, and the Offeror cannot ensure continued support from exchanges. A delisting or lack of market depth may result in SPK tokens being practically unusable.
Trading venues, whether decentralised or centralised, pose operational and counterparty risks.
Users may face delays, hacks, or insolvency events, which could hinder access to tokens. Neither the Spark Foundation nor the Offeror is liable for such outcomes.
Any future increase in the total supply of SPK - including the newly approved expansion from 710 million to 910 million tokens - will proportionally reduce each existing holder’s relative stake and may exert downward pressure on the token’s market value.
Smart contract risks also exist during the claim or staking processes. Errors, vulnerabilities, or incorrect wallet use may lead to permanent loss of SPK tokens, despite the token having been free.
Finally, recipients may still incur tax liabilities on receipt, even without monetary investment. Participants must assess these risks individually and ensure compliance with local regulations.
#### I.2 Issuer-Related Risks
The Issuer's sole function is to issue and distribute SPK tokens. It does not manage or operate any technical infrastructure, oversee governance processes, or maintain control over the protocol or community.
This limited operational role means the Issuer cannot respond to technical failures, governance disputes, or security incidents within the broader ecosystem. If issues arise post-distribution such as bugs in smart contracts or shifts in network governance, the Issuer has no authority or capacity to intervene or implement corrective measures.
Furthermore, the Offeror provides no guarantees regarding the future value, usability, or development of the SPK token or the Spark ecosystem. All post-distribution developments depend on decentralised community governance or third-party contributors, over whom the Offeror has no influence.
Participants should therefore understand that their reliance on the Issuer is limited strictly to the issuance of SPK tokens. Any expectations beyond that, whether technical, economic, or governance-related, must be assessed based on the broader ecosystem's operations and risks.
#### I.3 Crypto-Assets-related Risks
As a Crypto-asset, SPK tokens carry risks inherent to digital tokens built on public blockchains. These risks are present regardless of whether a token is purchased or received for free.
SPK operates on the Ethereum network and is subject to blockchain-related vulnerabilities. Network congestion, outages, or high transaction fees could impact users’ ability to claim, transfer, or use SPK tokens in a timely or cost-effective manner.
The token's value is also highly volatile. While there is no direct financial cost to acquiring SPK tokens through airdrops or qualifying actions, token holders may still face opportunity costs if the value declines sharply or if the token becomes unusable due to low adoption or regulatory constraints.
Smart contract vulnerabilities pose another key risk. Even audited contracts can contain bugs or be exploited. Losses stemming from contract-level attacks could affect staking, transfers, or functionality tied to SPK tokens.
Custody of SPK tokens requires secure private key management. Loss or theft of private keys will result in irreversible loss of tokens. Participants are solely responsible for securing their wallet access and recovery information.
SPK token holders may also be targeted by fraud, phishing attacks, or scams that impersonate the Offeror or promote counterfeit tokens. Engaging with unverified links, dApps, or communications could result in loss of assets.
Finally, evolving regulations in different jurisdictions may restrict use or access to SPK, especially if the token is later deemed to fall within specific legal classifications. This could limit its utility or expose holders to compliance obligations.
#### I.4 Project Implementation-Related Risks
The long-term success of SPK is closely tied to the ongoing implementation of the broader Spark project. This process faces a number of technical, operational, and strategic risks.
Technical risks include the potential for bugs or vulnerabilities in smart contracts, governance modules, or infrastructure upgrades. Even with careful development and auditing, errors could affect token functionality or user funds.
Operational risks arise from the allocation of resources, including developer attention, treasury funding, and community engagement. If these are insufficient or misaligned, project timelines may slip or core features may never be completed.
The project’s governance and roadmap are shaped by a decentralised community. This structure can result in slow decision-making, conflicting interests, or even governance capture, where a small group steers development against the broader community's interests.
Adoption risk is also significant. SPK tokens’ utility depends on community participation and real-world integrations. Without active use and credible demand for the Spark ecosystem’s services, the token’s role and relevance may diminish.
In addition, external dependencies such as integration with third-party protocols, platforms, and infrastructure providers can introduce delays or disruptions. Any instability or failure in these components could stall project delivery or impair functionality.
Finally, the broader regulatory and technological environment can shift rapidly. Changes in crypto-asset regulation, competition from new technologies, or loss of ecosystem partners may materially alter the implementation trajectory of the project.
#### I.5 Technology-Related Risks
SPK relies on blockchain infrastructure and smart contract technology that is still evolving. These underlying technologies present several risks that could affect the SPK token's security, performance, and usability.
Distributed ledger networks like the Ethereum blockchain may experience congestion, downtime, or forks, all of which can disrupt token transfers or contract interactions. In extreme cases, users may lose access to their tokens or experience unexpected delays or errors.
Smart contracts governing SPK token-related operations are immutable once deployed. Security flaws or exploits may be used to manipulate SPK token transfers, staking mechanisms, or governance processes.
Token holders are fully responsible for managing their private keys. Mistakes in wallet configuration or loss of access credentials result in permanent token loss, as transactions on the blockchain are irreversible.
Compatibility and access risks may arise if wallet software becomes outdated, unsupported, or incompatible with new SPK token upgrades or infrastructure. Users relying on specific platforms may lose access if those platforms shut down or fail to update their systems.
Moreover, SPK tokens depend on integrations with third-party services like decentralised exchanges, bridges, oracles, and custodians. Failures, security breaches, or regulatory actions affecting these services could degrade SPK tokens’ functionality or cause temporary inaccessibility.
The SPK token is also exposed to long-term risks from technological disruption. Innovations such as quantum computing could weaken cryptographic systems securing blockchain networks. While such risks remain largely theoretical, they could undermine user confidence or lead to structural changes in the network.
In summary, while the SPK ecosystem employs best practices in smart contract development and network integration, the rapidly changing technological landscape presents ongoing risks that may affect security, accessibility, and user experience.
#### I.6 Mitigation measures
To address the range of risks associated with SPK, the project has implemented multiple mitigation strategies across technical, operational, and governance layers.
* **Smart Contract Audits** **–** All critical contracts are subject to external audits by reputable security firms. Audits help identify vulnerabilities before deployment and reduce the likelihood of exploitation. Previous audits are accessible at [http://docs.spark.fi/dev/security/security-and-audits](http://docs.spark.fi/dev/security/security-and-audits).
* **Progressive rollout** **–** SPK token distribution and product features are introduced gradually to allow for testing and feedback, minimising systemic risk and improving resilience.
* **Decentralised Governance** **–** SPK token governance is structured through community mechanisms, including SparkDAO and SkyDAO governance. This provides checks and balances, limits centralised control, and enables dynamic adaptation to new risks.
* **Transparent communication** **–** Ongoing disclosures via public documentation, white paper updates, forums, and governance proposals foster community awareness and help participants make informed decisions.
* **Liquidity support and listings –** While no guarantee is provided, the Offeror may collaborate with market participants to encourage liquidity provision and exchange listings where feasible.
* **Regulatory Alignment** **–** The project tracks legal developments in key jurisdictions to align with regulatory frameworks, particularly those under MiCA.
These measures do not eliminate risk, but they significantly reduce the likelihood or severity of adverse events. Participants should still exercise caution and adopt personal risk management strategies when engaging with SPK tokens or the broader Spark ecosystem.
### PART A – INFORMATION ABOUT THE OFFEROR OF THE CRYPTO-ASSET
#### A.1 Name
SPK Company Ltd.
#### A.2 Legal Form
Company limited by shares
#### A.3 Registered address
SHRM Trustees (BVI) Limited of Trinity Chambers, PO Box 4301.
#### A.4 Head office
Road Town, Tortola, British Virgin Islands
#### A.5 Registration Date
2025-02-19
#### A.6 Legal entity identifier
Not available
#### A.7 Another identifier required pursuant to applicable national law
2170013
#### A.8/9/10 Contacting the Offeror
The Offeror can be contacted by telephone or email using the details provided below. The Offeror will respond within 14 business days.
Glenn Kennedy: [gkennedy@leewardmanagement.ky](mailto\:gkennedy@leewardmanagement.ky)
Marc Piano: [piano@horizonsglobal.io](mailto\:piano@horizonsglobal.io)
Telephone number: +1 345-749-9601 Email address:
The Offeror does not have a website. The website of the project is [https://spark.fi/](https://spark.fi/).
#### A.11 Parent Company
Spark Foundation
#### A.12 Identity of the management body
The sole director of the Offeror is Spark Foundation
The directors of Spark Foundation are Glenn Kennedy and Marc Piano
Business address of Spark Foundation is Leeward Management Limited, Suite 3119, 9 Forum Lane, Camana Bay, PO Box 144, George Town, Grand Cayman KY1-9006, Cayman Islands
#### A.13 Business activity
The only purpose is to issue and distribute the Token.
#### A.14 Parent Company Business Activity
To support, promote, and advance the development, adoption, security, and growth of Spark.
#### A.15 Newly Established
true
#### A.16 Financial condition for the past three years
The Offeror is a newly incorporated company with no material liabilities as of the date of this White Paper. The Offeror will be capitalised as needed to fulfil its mandate of issuing SPK tokens and distributing them.
#### A.17 Financial condition since registration
The Offeror is a newly incorporated company with no material liabilities as of the date of this White Paper. The Offeror will be capitalised as needed to fulfil its mandate of issuing SPK tokens and distributing them.
### PART B – INFORMATION ABOUT THE ISSUER, IF DIFFERENT FROM THE OFFEROR OR PERSON SEEKING ADMISSION TO TRADING
This section is not applicable. Part B does not apply as the issuer and the offeror are the same legal entity.
### PART C – INFORMATION ABOUT THE OPERATOR OF THE TRADING PLATFORM
This section is not applicable. No trading platform has drawn up or contributed to the preparation of this White Paper.
### PART D – INFORMATION ABOUT CRYPTO-ASSET PROJECT
#### D.1 Crypto-asset project name
Spark
#### D.2 Crypto-asset name
Spark
#### D.3 Abbreviation
SPK
#### D.4 Crypto-asset project description
The project is a DeFi protocol, which emerged from Sky, previously known as MakerDAO, and serves as a ‘Sky Star’, a subDAO within the Sky ecosystem. It consists of three main components: SparkLend, a stablecoin lending market; Spark Savings, for earning yield on certain stablecoins; and Spark Liquidity Layer, a backend capital allocator that routes liquidity across select DeFi protocols.
#### D.5 Details of all natural or legal persons involved in the implementation of the crypto-asset project
SPK Company, Ltd.
c/o SHRM Trustee (BVI) Ltd.
Trinity Chambers
PO Box 4301
Road Town, Tortola, British Virgin Islands
Spark Foundation
c/o Leeward Management Limited
Suite 3119, 9 Forum Lane Camana Bay, George Town,
Grand Cayman KY1-9006, Cayman Islands
#### D.6 Utility token classification
false
#### D.7 Key Features of Goods/Services for Utility Token Projects
Not applicable
#### D.8 Plans for the token
The SPK token is designed to function as a cornerstone of the Spark ecosystem, enabling long-term value creation through decentralised incentives, participation, and infrastructure support. SPK is distributed without monetary consideration and built with clear alignment between user effort and ecosystem growth.
##### **Community-Driven Distribution**
SPK token’s distribution model prioritises organic community involvement. Tokens are allocated via airdrops, on-chain activity, and reward mechanisms tied to meaningful user engagement.
These distribution channels are permissionless, performance-based and structured to encourage use among committed participants.
##### **Protocol Utility and Staking**
SPK tokens are expected to play a role in supporting the reliability and functionality of the Spark protocol over time. SPK token holders may be given the option to stake their SPK to contribute to the network's resilience or participate in reward systems. Staking mechanisms could be linked to protocol components such as cross-chain infrastructure or security features, although specifics may evolve based on governance decisions and technical development. Staking may involve time-bound commitments, and rewards, if any, will reflect the level of engagement and the function being supported.
##### **Incentive structures**
The token design incorporates the possibility of allocating SPK tokens to participants who contribute to the ecosystem’s growth and operational soundness. This may include users who interact with infrastructure components, provide liquidity, or contribute to early adoption efforts. These measures aim to foster long-term engagement.
##### **Governance Engagement**
SPK tokens may also function as a governance tool, enabling holders to take part in decentralised decision-making processes. These could include discussions and votes on treasury use, protocol evolution, or other strategic priorities. The governance model is intended to be adaptable, subject to community feedback and emerging needs.
##### **Future Outlook**
As the Spark project grows, SPK tokens may become relevant in additional modules or integrations, including those related to cross-chain operations, coordination layers, or service modules. These developments will be introduced incrementally and in alignment with broader ecosystem goals.
The vision for SPK tokens is to support a sustainable, community-driven network. Its role is not fixed but is intended to reflect the evolving needs of a decentralised ecosystem prioritising fairness, resilience, and meaningful engagement.
#### D.9 Resource Allocation
The Spark ecosystem incorporates a structured approach to resource allocation, aimed at ensuring long-term operational sustainability and adaptability. SPK tokens are reserved across specific categories to support development, governance, and ecosystem initiatives.
A dedicated share of the SPK token supply is earmarked for operational costs, reflecting the ongoing need to maintain infrastructure, support contributors, and cover administrative requirements. Additionally, Spark will receive initial grant funding from Sky to help bootstrap Spark’s growth. These resources enable the protocol to remain functional and responsive without immediate reliance on external funding.
In parallel, a treasury allocation is established to provide flexibility over time. This reserve is governed by community processes and may be used to support future proposals, ecosystem incentives, or strategic partnerships.
The resource model aligns token distribution with the needs of a dynamic and participatory ecosystem, allowing SPK tokens to function as a mechanism for funding public goods and sustaining the protocol over time.
#### D.10 Planned Use of Collected Funds or Crypto-Assets
The offer to the public will take place without raising funds or accepting any crypto-assets, as outlined in Section E.
### PART E – INFORMATION ABOUT THE OFFER TO THE PUBLIC
#### E.1 Public Offering
OTPC
#### E.2 Reasons for Public Offer
The public offer of SPK tokens is intended to initiate the launch of the Spark project and to incentivise early engagement with the Spark protocol. The offer is designed to encourage the use of its services and to establish a decentralised and active user base from the outset. The tokens will be distributed without collecting any funds or crypto-assets from participants. Instead, the offer is structured around non-monetary contribution mechanisms such as protocol usage, on-chain activity, staking engagement, and other qualifying actions.
Tokens are provided free of charge or in exchange for specific actions that demonstrate interest or involvement in the ecosystem. These distribution mechanisms include airdrops based on past engagement, performance-based eligibility, and participation in pre-defined incentive programs as specified in more detail in section E.18.
The public offer is not intended as a capital-raising measure and does not involve the collection of funds or crypto-assets. Accordingly, no proceeds will be received by the Offeror or any affiliated entity in connection with the distribution of SPK tokens. The offer is exclusively designed to support the initial development of a decentralised user base by allocating tokens to participants on the basis of non-financial contributions. The Offeror does not intend to derive any financial gain from the offer, and the distribution is structured to ensure compliance with applicable regulatory exemptions concerning public offerings without consideration.
#### E.3 Fundraising target
Not applicable
#### E.4 Minimum Subscription Goal
Not applicable
#### E.5 Maximum Subscription Goal
Not applicable
#### E.6 Oversubscription Acceptance
false
#### E.7 Oversubscription Allocation
Not applicable
#### E.8 Issue Price
€0
#### E.9 Official currency or any other crypto-assets determining the issue price
Not applicable
#### E.10 Subscription fee
€0
#### E.11 Offer Price Determination Method
The SPK tokens will be allocated without consideration and exclusively based on demonstrable user actions or prior holdings. No monetary payment or transfer of crypto-assets is required or accepted in exchange for the receipt of SPK tokens.
#### E.12 Total Number of Offered Crypto-Assets
910,000,000 SPK tokens
#### E.13 Targeted Holders
ALL
#### E.14 Holder restrictions
The offer of SPK tokens is not subject to any general restriction with respect to the type of recipient. However, the distribution is limited to individuals and entities that are not subject to applicable sanctions or other regulatory prohibitions. The Offeror reserves the right to exclude from eligibility any user or wallet address that is reasonably believed to be associated with a jurisdiction, entity, or individual subject to relevant restrictions under applicable law. Further, any user or wallet address reasonably suspected of being a Sybil wallet or involved in fraudulent, manipulative, or malicious activity may be excluded from participation in the offer. Users are responsible for ensuring that their receipt and holding of SPK tokens are lawful in their respective jurisdictions.
Participants must self-certify that they are not residents of, or otherwise located in, any jurisdiction where the receipt or holding of crypto-assets is restricted or prohibited.
#### E.15
Purchasers participating in the offer to the public of crypto-asset will be able to be reimbursed if the minimum target subscription goal is not reached at the end of the offer to the public, if they exercise the right to withdrawal foreseen in Article 13 of Regulation (EU) 2023/1114 or if the offer is cancelled.
#### E.16 Refund Mechanism
Pursuant to Article 13 of MiCA, retail holders who have agreed to receive SPK tokens from the Offeror shall have a right to withdraw from such agreement within a period of 14 calendar days from the date of such agreement, without giving any reason and without incurring any costs.
Retail holders may exercise their right of withdrawal by following the process available at [www.spark.fi/mica](http://www.spark.fi/mica). The notice must be submitted no later than 14 calendar days after the date on which the agreement to acquire SPK tokens was concluded.
Upon receiving the withdrawal notice, the Offeror will provide the retail holder with a blockchain address to which the tokens must be returned.
##### **Return of Tokens and Reimbursement**
The retail holder shall return the acquired SPK tokens to the Offeror without undue delay and no later than 14 calendar days after submitting the withdrawal notice. As no monetary payment was made by the holder, no reimbursement shall be due. Due to this, the tokens shall be returned and the agreement voided without further obligation from either party.
The Offeror will not impose any fee or penalty in connection with the exercise of the right of withdrawal. Gas fees incurred on-chain in connection with the return of tokens shall be borne by the retail holder unless otherwise agreed.
#### E.17 Refund Timeline
The designated refund wallet address shall be made available to the holder upon receipt of the withdrawal notice and shall remain available for the return of tokens for a minimum period of 14 calendar days thereafter.
#### E.18 Offer Phases
The public offering of SPK tokens will occur in separate phases, each designed to distribute tokens to distinct participant groups based on eligibility criteria and pre-defined allocation methodologies. Claims will be made available via on-chain claiming interfaces following the Token Generation Event (TGE), with each phase subject to its own claiming window.
##### **Phase 1**:
This phase includes distributions to early participants who interacted with designated DeFi protocols prior to the TGE. Allocation is based on historic on-chain activity, with protocol-specific criteria and anti-sybil measures applied. Eligible users may claim their tokens starting at TGE for a limited duration.
##### **Phase 2**:
This phase encompasses broader ecosystem distribution based on historical activity across multiple chains, platforms and applications. Allocations are determined using a point-based system reflecting user exposure to selected assets and protocols. Eligibility is non-transferable and fixed prior to the TGE. The claiming period for this phase begins at TGE and concludes following a pre-defined window.
##### **Phase 3**:
This phase involves distribution to participants in Spark’s post-TGE ecosystem campaigns, including social and engagement-based reward initiatives. Participants may earn eligibility by completing campaign tasks or interacting with designated applications. Each campaign includes an earning period and a subsequent claim window. Unclaimed tokens after the claim period expires will revert to the treasury.
All phases are subject to eligibility verification, including sanctions screening and wallet verification. Tokens may only be claimed via the official interface during the applicable claiming window.
Eligibility criteria and claiming instructions for each phase will be published on the official claiming interface on Spark’s website, [spark.fi](http://spark.fi/), prior to the commencement of the relevant claiming window.
This white paper covers a continuous offering of SPK tokens through multiple time-limited phases. Each phase has a defined claim period, but the Offeror may initiate additional distribution phases in the future under the same framework. The offer shall remain open for purposes of MiCA Article 10(2) until otherwise stated, and the number of tokens in circulation will be published at least monthly on the Offeror’s website.
In the event that future phases are materially different from those described herein, whether in terms of structure or claiming mechanisms, the Offeror will update and notify the white paper in accordance with MiCA Article 12 prior to the commencement of such phases.
#### E.19 Early Purchase Discount
Not applicable.
#### E.20 Time-limited offer
false
#### E.21 Subscription period beginning
Not applicable
#### E.22 Subscription period end
Not applicable
#### E.23 Safeguarding Arrangements for Offered Funds/Crypto-Assets
Not applicable
#### E.24 Payment Methods for Crypto-Asset Purchase
The SPK tokens are offered without payment of any monetary benefit, but based on pre-defined actions and on-chain activity.
#### E.25 Value Transfer Methods for Reimbursement
No reimbursement shall be due.
#### E.26 Right of Withdrawal
In accordance with Article 13 of MiCA, any retail holder who enters into an agreement to acquire SPK tokens as part of this public offering shall have the right to withdraw from the agreement within a period of 14 calendar days from the date of such agreement, without giving any reason and without incurring any cost.
Retail holders may exercise it by following the process outlined under Refund Mechanism.
#### E.27 Transfer of Purchased Crypto-Assets
Upon satisfying the eligibility criteria for a given phase of the offer, SPK tokens will become claimable by the eligible holder at or after the TGE. Tokens will be made available via an on-chain claiming mechanism, and holders must actively claim their allocation through the designated interface.
Upon successful claiming, the SPK tokens will be transferred to the holder’s self-custodied wallet address, at which point the holder obtains full control and ability to transfer, subject to applicable legal or contractual restrictions with wallet provider. There are no transfer restrictions imposed by the Offeror following delivery, unless otherwise stated in this White Paper.
#### E.28 Transfer Time Schedule
SPK tokens will become claimable by eligible holders in accordance with any claiming schedules announced on Spark's official website. Upon claiming, tokens will be transferred in full to the holder’s wallet with no further vesting, lock-up, or time-based release restrictions imposed by the Offeror.
#### E.29 Purchaser’s Technical Requirement
To receive and hold SPK tokens, eligible holders must have access to a compatible, self-custodied wallet capable of interacting with the Ethereum blockchain, where SPK is deployed as an ERC-20 standard token.
The wallet must support:
* Secure storage of private keys and recovery phrases;
* On-chain interaction with smart contracts
(e.g., for claiming SPK tokens)
* The ability to pay applicable network transaction fees (gas) in the native blockchain token, ETH.
The Offeror does not provide wallet infrastructure or custody services. It is the sole responsibility of the eligible holder to:
* Secure their private keys;
* Ensure uninterrupted access to their wallet;
* Ensure the wallet address used for claiming is correct and under their exclusive control.
Failure to meet the above requirements may result in the holder’s inability to claim or access the SPK tokens, for which the Offeror assumes no responsibility.
#### E.30 Crypto-asset service provider (CASP) name
Not applicable
#### E.31 CASP identifier
Not applicable
#### E.32 Placement form
NTAV
#### E.33 Trading Platforms name
Not applicable
#### E.34 Trading Platforms Market Identifier Code (MIC)
Not applicable
#### E.35 Trading Platforms Access
Not applicable
#### E.36 Involved costs
Not applicable
#### E.37 Offer Expenses
No placement fees, subscription fees, or transaction fees are charged to the eligible holder by the Offeror in connection with the receipt or claiming of SPK tokens.
Eligible holders may be required to pay standard network transaction fees (gas fees) to claim their tokens via the designated on-chain interface. These fees are paid directly to the blockchain network and not retained by the Offeror.
All costs associated with the development, structuring, and execution of the offering, including legal, technical, and marketing expenses, are borne by the Offeror.
#### E.38 Conflicts of Interest
Spark Foundation is expected to receive an allocation of approximately 1 billion SPK tokens following the TGE. These SPK tokens will be used by the Spark Foundation to support protocol development, governance, ecosystem incentives, and other community-aligned initiatives. It is the assessment of the Offeror that this allocation does not give rise to a conflict of interest within the meaning of Article 14(1)(c) of MiCA, as Spark Foundation operates with a mandate to promote the long-term success of the ecosystem and not for private gain. The Offeror will continue to monitor for potential conflicts of interest on an ongoing basis and will take appropriate steps to disclose and mitigate any such conflicts should they arise.
#### E.39 Applicable law
This offering and the contractual rights and obligations arising between the Offeror and eligible holders in connection with SPK tokens shall be governed by and construed in accordance with the laws of the British Virgin Islands. Notwithstanding the above, this White Paper and the offer of SPK tokens to the public within the European Union are made in accordance with MiCA.
#### E.40 Competent court
Any dispute arising out of or in connection with this offering or the SPK tokens shall be subject to the exclusive jurisdiction of the courts of the British Virgin Islands. This is without prejudice to the rights of retail holders residing in the European Union to bring claims before the courts of their place of residence, in accordance with applicable consumer protection and private international law rules.
### PART F – INFORMATION ABOUT THE CRYPTO-ASSETS
#### F.1 Crypto-Asset Type
Crypto-asset other than an asset-referenced token or e-money token.
#### F.2 Crypto-Asset Functionality
SPK token is a fungible crypto-asset within the meaning of Article 3(1)(5) of MiCA. It does not qualify as an asset-referenced token (ART) or e-money token (EMT) under MiCA and is offered to the public under the Title II framework.
SPK token is implemented as a standard ERC-20 token on the Ethereum blockchain and is freely transferable following its delivery to the holder, subject to any applicable legal or contractual restrictions described in this White Paper.
SPK token is designed primarily for the use within Spark ecosystem, including participation in governance, reward programs, and future protocol-based activities. It does not represent a financial claim or entitlement to any underlying asset, nor does it confer ownership or profit rights in the Offeror or any affiliated entity.
#### F.3 Planned Application of Functionalities
At the time of publishing this White Paper, the SPK token’s core functionalities are described below and will be made available progressively after Offering:
* **Governance**: SPK token holders will be able to participate in the governance of the Spark protocol. This may include the right to vote on proposals concerning matters like protocol parameters, treasury allocation, grant distributions, and technical upgrades. Governance mechanisms will evolve under a decentralised governance model managed via the SparkDAO.
* **Staking**: SPK tokens may be staked by holders. In return for staking, participants may earn rewards. The staking mechanism is governed by smart contracts and requires the transfer of SPK tokens to a dedicated staking contract.
* **Rewards and Incentives**: SPK tokens will be distributed as part of airdrop campaigns and incentive programmes as described in this White Paper. These may include rewards for early use of DeFi products within the Spark application. In addition, SPK tokens may be used in future farming mechanisms or liquidity incentives across various Spark-related services.
All functionalities are accessible through the Spark application or approved interfaces. Certain features, such as staking and voting, may be made available in phases, with implementation timelines subject to further governance decisions. Any material updates to the functionalities or use of SPK tokens will be reflected through updates to this white paper in accordance with MiCA Article 12.
**A description of the characteristics of the crypto-asset, including the data necessary for classification of the crypto-asset white paper in the register referred to in Article 109 of Regulation (EU) 2023/1114, as specified in accordance with paragraph 8 of that Article**
#### F.4 Type of white paper
OTHR
#### F.5 The type of submission
MODI
#### F.6 Crypto-asset Characteristics
See Part D and Section F.2.
#### F.7 Commercial name or trading
Spark / SPK token name
#### F.8 Website of the issuer
The Issuer does not have a website.
The website of the project is [https://spark.fi/](https://spark.fi/).
#### F.9 Starting date of offer to the public or admission to trading
2025-06-17
#### F.10 Publication date
2025-06-20
#### F.11 Any other services provided by the issuer
The Offeror does not offer any other services covered by MiCA
#### F.12 Identifier of operator of the trading platform
Not applicable
#### F.13 Language or languages of the white paper
English
#### F.14 Digital Token Identifier Code used to uniquely identify the crypto-asset or each of the several crypto-assets to which the white paper relates, where available
SPK
#### F.15 Functionally Fungible Group Digital Token Identifier, where available
Not applicable
#### F.16 Voluntary data flag
false
#### F.17 Personal data flag
true
#### F.18 LEI eligibility
false
#### F.19 Home Member State
Denmark
#### F.20 Host Member States
The offer to the public of SPK tokens is passported to the following countries:
* Austria
* Belgium
* Bulgaria
* Croatia
* Cyprus
* Czech Republic
* Estonia
* Finland
* France
* Germany
* Greece
* Hungary
* Iceland
* Ireland
* Italy
* Latvia
* Liechtenstein
* Lithuania
* Luxembourg
* Malta
* Netherlands
* Norway
* Poland
* Portugal
* Romania
* Slovakia
* Slovenia
* Spain
* Sweden
### PART G – INFORMATION ON THE RIGHTS AND OBLIGATIONS ATTACHED TO THE CRYPTO-ASSETS
#### G.1 Purchaser Rights and Obligations
Upon receipt of SPK tokens, holders are granted the right to hold, transfer, and utilise the tokens in accordance with the functionalities set out in this White Paper. Where implemented, such functionalities may include the ability to participate in governance processes and protocol-level decision-making, as well as to access certain staking or reward mechanisms as described herein.
SPK tokens do not confer on holders any ownership interest, profit-sharing rights, equity claims, or creditor rights against the Offeror. The tokens do not represent financial instruments, electronic money, or asset-referenced tokens within the meaning of MiCA.
SPK token holders shall be solely responsible for maintaining secure custody of their private keys, ensuring accurate and timely use of the designated claiming interface, and bearing any applicable network transaction fees incurred during claiming, transferring, or using SPK tokens. Token holders must also ensure compliance with any applicable legal, regulatory, or tax obligations in their jurisdiction of residence. No additional rights or obligations are imposed on holders beyond those expressly described in this White Paper.
#### G.2 Exercise of Rights and obligations
The rights associated with SPK tokens may be exercised exclusively through the designated blockchain interfaces, smart contracts, or governance mechanisms made available. Access to these rights requires that the SPK token holder maintains control over a compatible self-custodied wallet and engages directly with the supported interfaces.
Participation in governance, staking, or any reward-based functionality shall be subject to the technical implementation of such features and any applicable eligibility conditions, timelines, or procedural requirements as further communicated via official channels of the Spark ecosystem.
The obligations of SPK token holders, including the payment of any network fees and compliance with applicable legal requirements, are to be fulfilled independently and at the sole responsibility of the holder.
#### G.3 Conditions for modifications of rights and obligations
The rights and obligations associated with SPK tokens may be modified in the future as a result of governance decisions adopted in accordance with the decentralised governance framework of the Spark protocol. Such modifications may include changes to token functionalities, staking parameters, voting mechanisms, or eligibility criteria for participation in network incentives.
The Offeror does not retain unilateral discretion to amend the rights or obligations of retail holders after the issuance of SPK tokens. Any material change to the governance structure or token utility will be subject to the governance procedures established within the Spark ecosystem, including proposal submission, voting thresholds, and quorum requirements, as applicable.
#### G.4 Future Public Offers
At the time of publication of this white paper, the Offeror does not have any confirmed plans for future public offers of SPK tokens. Should the Offeror initiate any such offering in the future, a separate or updated white paper will be prepared, notified to the competent authority, and published in accordance with Article 12 of MiCA.
#### G.5 Issuer Retained Crypto-Assets
0
#### G.6 Utility Token Classification
false
#### G.7 Key Features of Goods/Services of Utility Tokens
Not applicable
#### G.8 Utility Token Redemption
Not Applicable
#### G.9 Non-Trading request
true
#### G.10 Crypto-Assets purchase or sale modalities
Not applicable
#### G.11 Crypto-Assets Transfer Restrictions
The Offeror does not impose any transfer restrictions.
#### G.12 Supply Adjustment Protocols
false
#### G.13 Supply Adjustment Mechanisms
SPK does not currently have any automatic or algorithmic supply adjustment mechanisms linked to market demand. There is no pre-programmed rebasing, burning, or minting functionality designed to increase or decrease the token supply based on price or demand fluctuations.
However, the total supply of SPK may be increased in the future through governance proposals adopted by the SkyDAO, the decentralised governance structure associated with the Spark protocol. Any such supply adjustment would be subject to the applicable governance rules and would require approval through the established voting procedures.
#### G.14 Token Value Protection Scheme
false
#### G.15 Token Value Protection Schemes Description
Not applicable
#### G.16 Compensation Schemes
false
#### G.17 Compensation Schemes Description
Not applicable
#### G.18 Applicable law
This white paper, and any contractual rights and obligations arising in connection with the receipt and use of SPK tokens, shall be governed by and construed in accordance with the laws of the British Virgin Islands.
#### G.19 Competent court
Any dispute arising out of or in connection with this offering shall be subject to the exclusive jurisdiction of the courts of the British Virgin Islands.
This is without prejudice to the rights of retail holders who are natural persons and habitually resident in a Member State of the European Union to bring proceedings before the courts of their place of residence, in accordance with applicable EU consumer protection and private international law rules.
### Part H – INFORMATION ON THE UNDERLYING TECHNOLOGY
#### H.1 Distributed ledger technology
SPK token is deployed on the Ethereum mainnet, a public and permissionless distributed ledger based on blockchain technology. The token is implemented via a set of smart contracts deployed to Ethereum and is accessible to any compatible wallet.
#### H.2 Protocols and technical
SPK tokens conform to the ERC-20 token standard standards and interacts with Ethereum-compatible smart contracts to facilitate distribution, claiming, staking, and governance. Token transfers, approvals, and other on-chain operations follow the established ERC-20 interface.
#### H.3 Technology Used
As an ERC-20 token, the SPK token will be deployed as a smart contract on the Ethereum blockchain. Users can manage the SPK tokens through their own non-custodial wallet software provided by third parties or by interacting directly with the SPK token’s smart contract through a third-party API.
#### H.4 Consensus Mechanism
The SPK token is deployed on the Ethereum blockchain. Ethereum operates using a Proof of Stake (PoS) consensus mechanism, wherein network validators are selected based on staked ETH to confirm transactions and propose new blocks.
#### H.5 Incentive Mechanisms and Applicable Fees
SPK token holders may earn SPK tokens as rewards through staking or participation in Spark ecosystem activities, as described in this White Paper.
The Offeror does not charge any placement or transaction fees in connection with the receipt or use of SPK tokens. However, all on-chain transactions on Ethereum, including claiming and transferring SPK tokens, require the payment of network gas fees.
Gas fees are denominated in ETH and paid directly to the Ethereum network. Following the implementation of Ethereum Improvement Proposal 1559 (EIP-1559), gas fees consist of two components:
* **Base fee**:\
This is automatically calculated based on current network demand and is burned, meaning it is removed from circulation.
* **Priority fee (tip)**:\
This is paid to the validator that successfully proposes the block in which the transaction is included.
Ethereum validators are incentivised through a combination of block rewards and priority fees paid in ETH. Validators who misbehave or act maliciously are subject to slashing penalties, resulting in the loss of a portion of their staked ETH.
The Offeror has no control over Ethereum blockchain fees, validator behaviour, or the consensus process.
#### H.6 Use of Distributed Ledger Technology
false
#### H.7 DLT Functionality Description
Not applicable
#### H.8 Audit
false
#### H.9 Audit outcome
Not applicable
#### PART J – INFORMATION ON THE SUSTAINABILITY INDICATORS IN RELATION TO ADVERSE IMPACT ON THE CLIMATE AND OTHER ENVIRONMENT-RELATED ADVERSE IMPACTS
#### General information
#### S.1 Name
SPK Company Ltd
#### S.2 Relevant legal entity identifier
*Identifier stated to in section A*
Not available
#### S.3 Name of the crypto-asset
*Name of the crypto-asset as stated to in section A*
Spark / SPK
#### S.4 Consensus Mechanism
The SPK token is deployed on the Ethereum blockchain. *The consensus mechanism,* Ethereum operates using a Proof of Stake (PoS) *as stated in Section H* consensus mechanism, wherein network validators are selected based on staked ETH to confirm transactions and propose new blocks.
#### S.5 Incentive Mechanisms and Applicable Fees
*Incentive mechanisms to secure transactions and any fees applicable as stated in section H.*
SPK token holders may earn SPK tokens as rewards through staking or participation in Spark ecosystem activities, as described in this White Paper.
The Offeror does not charge any placement or transaction fees in connection with the receipt or use of SPK tokens. However, all on-chain transactions on Ethereum, including claiming and transferring SPK tokens, require the payment of network gas fees.
Gas fees are denominated in ETH and paid directly to the Ethereum network. Following the implementation of Ethereum Improvement Proposal 1559 (EIP-1559), gas fees consist of two components:
* **Base fee**:
This is automatically calculated based on current network demand and is burned, meaning it is removed from circulation.
* **Priority fee (tip)**:\
This is paid to the validator that successfully proposes the block in which the transaction is included.
Ethereum validators are incentivised through a combination of block rewards and priority fees paid in ETH. Validators who misbehave or act maliciously are subject to slashing penalties, resulting in the loss of a portion of their staked ETH.
The Offeror has no control over Ethereum blockchain fees, validator behaviour, or the consensus process.
#### S.6 Beginning of the period to which the disclosed information relates
2024-05-08
#### S.7 End of the period to which the disclosure relates
2025-05-08
#### **Mandatory key indicator on energy consumption**
#### S.8 Energy consumption
*Total amount of energy used for the validation of transactions and the maintenance of the integrity of the distributed ledger, expressed in kilowatt-hours per calendar year*
4,871,148.30 kWh
#### **Sources and methodologies**
#### S.9 Energy consumption
*Sources and methodologies used in relation to the information reported above*
The estimated energy consumption provided in Section sources and S.8 has been calculated using the CCRI Crypto methodologies Sustainability Metrics provided by the Crypto Carbon Ratings Institute (source: [https://indices.carbon-ratings.com/](https://indices.carbon-ratings.com/)).
Since the Token has not yet been created, the energy consumption pertains to the previous calendar year, as an estimate of what can be consumed during the Token’s first year by the Ethereum blockchain.
| 0 | Table of content | Date of notification Statement in accordance with Article 6(3) of Regulation (EU) 2023/1114 Compliance statement in accordance with Article 6(6) of Regulation (EU) 2023/1114 Statement in accordance with Article 6(5), points (a), (b), (c) of Regulation (EU) 2023/1114 Statement in accordance with Article 6(5), point (d) of Regulation (EU) 2023/1114 Statement in accordance with Article 6(5), points (e) and (f) of Regulation (EU) 2023/1114 SUMMARY Warning in accordance with Article 6(7), second subparagraph of Regulation (EU) 2023/1114 Characteristics of the crypto-asset Key information about the offer to the public or admission to trading Part I – Information on risks Offer-Related Risks Issuer-Related Risks Crypto-Assets-related Risks Project Implementation-Related Risks Technology-Related Risks Mitigation measures Part A - Information about the offeror or the person seeking admission to trading Name Legal form Registered address Head office Registration Date Legal entity identifier Another identifier required pursuant to applicable national law Contact telephone number E-mail address Response Time (Days) Parent Company Members of the Management body Business Activity Parent Company Business Activity Newly Established Financial condition for the past three years Financial condition since registration Part B - Information about the issuer, if different from the offeror or person seeking admission to trading Issuer different from offeror or person seeking admission to trading Name Legal form Registered address Head office Registration Date Legal entity identifier Another identifier required pursuant to applicable national law Parent Company Members of the Management body Business Activity Parent Company Business Activity Part C - Information about the operator of the trading platform in cases where it draws up the crypto-asset white paper and information about other persons drawing the crypto-asset white paper pursuant to Article 6(1), second subparagraph, of Regulation (EU) 2023/1114 Name Legal form Registered address Head office Registration Date Legal entity identifier of the operator of the trading platform Another identifier required pursuant to applicable national law Parent Company Reason for Crypto-Asset White Paper Preparation Members of the Management body Operator Business Activity Parent Company Business Activity Other persons drawing up the crypto-asset white paper according to Article 6(1), second subparagraph, of Regulation (EU) 2023/1114 Reason for drawing the white paper by persons referred to in Article 6(1), second subparagraph, of Regulation (EU) 2023/1114 Part D - Information about the crypto-asset project Crypto-asset project name Crypto-assets name Abbreviation Crypto-asset project description Details of all natural or legal persons involved in the implementation of the crypto-asset project Utility Token Classification Key Features of Goods/Services for Utility Token Projects Plans for the token Resource Allocation Planned Use of Collected Funds or Crypto-Assets Part E - Information about the offer to the public of crypto-assets or their admission to trading Public Offering or Admission to trading Reasons for Public Offer or Admission to trading Fundraising Target Minimum Subscription Goals Maximum Subscription Goal Oversubscription Acceptance Oversubscription Allocation Issue Price Official currency or any other crypto-assets determining the issue price Subscription fee Offer Price Determination Method Total Number of Offered/Traded Crypto-Assets Targeted Holders Holder restrictions Reimbursement Notice Refund Mechanism Refund Timeline Offer Phases Early Purchase Discount Time-limited offer Subscription period beginning Subscription period end Safeguarding Arrangements for Offered Funds/Crypto-Assets Payment Methods for Crypto-Asset Purchase Value Transfer Methods for Reimbursement Right of Withdrawal Transfer of Purchased Crypto-Assets Transfer Time Schedule Purchaser's Technical Requirements Crypto-asset service provider (CASP) name CASP identifier Placement form Trading Platforms name Trading Platforms Market Identifier Code (MIC) Trading Platforms Access Involved costs Offer Expenses Conflicts of Interest Applicable law Competent court Part F - Information about the crypto-assets Crypto-Asset Type Crypto-Asset Functionality Planned Application of Functionalities A description of the characteristics of the crypto-asset, including the data necessary for classification of the crypto-asset white paper in the register referred to in Article 109 of Regulation (EU) 2023/1114, as specified in accordance with paragraph 8 of that Article Type of white paper The type of submission Crypto-Asset Characteristics Commercial name or trading name Website of the issuer Starting date of offer to the public or admission to trading Publication date Any other services provided by the issuer Identifier of operator of the trading platform Language or languages of the white paper Digital Token Identifier Code used to uniquely identify the crypto-asset or each of the several crypto assets to which the white paper relates, where available Functionally Fungible Group Digital Token Identifier, where available Voluntary data flag Personal data flag LEI eligibility Home Member State Host Member States Part G - Information on the rights and obligations attached to the crypto-assets Purchaser Rights and Obligations Exercise of Rights and obligations Conditions for modifications of rights and obligations Future Public Offers Issuer Retained Crypto-Assets Utility Token Classification Key Features of Goods/Services of Utility Tokens Utility Tokens Redemption Non-Trading request Crypto-Assets purchase or sale modalities Crypto-Assets Transfer Restrictions Supply Adjustment Protocols Supply Adjustment Mechanisms Token Value Protection Schemes Token Value Protection Schemes Description Compensation Schemes Compensation Schemes Description Applicable law Competent court Part H – Information on the underlying technology Distributed ledger technology Protocols and technical standards Technology Used Consensus Mechanism Incentive Mechanisms and Applicable Fees Use of Distributed Ledger Technology DLT Functionality Description Audit Audit outcome Part J – Information on the sustainability indicators in relation to adverse impact on the climate and other environment-related adverse impacts Name Relevant legal entity identifier Name of the crypto-asset Consensus Mechanism Incentive Mechanisms and Applicable Fees Beginning of the Period to which the Disclosed Information Relates End of the Period to which the Disclosed Information Relates Mandatory key indicator on energy consumption Energy Consumption Sources and methodologies Energy Consumption Sources and Methodologies |
| :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------ | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **1** | **Date of notification** | 2025-08-20 |
| **2** | **Statement in accordance with Article 6(3) of Regulation (EU) 2023/1114** | This crypto-asset white paper has not been approved by any competent authority in any Member State of the European Union. The person seeking admission of trading of the crypto-asset is solely responsible for the content of this crypto-asset white paper. |
| **3** | **Compliance statement in accordance with Article 6(6) of Regulation (EU) 2023/1114** | This crypto-asset white paper complies with Title II of Regulation (EU) 2023/1114 and, to the best of the knowledge of the management body, the information presented in the crypto-asset white paper is fair, clear and not misleading and the crypto-asset white paper makes no omission likely to affect its import. |
| **4** | **Statement in accordance with Article 6(5), points (a), (b), (c) of Regulation (EU) 2023/1114** | The crypto-asset referred to in this white paper may lose its value in part or in full, may not always be transferable and may not be liquid. |
| **5** | **Statement in accordance with Article 6(5), point (d) of Regulation (EU) 2023/1114** | FALSE |
| **6** | **Statement in accordance with Article 6(5), points (e) and (f) of Regulation (EU) 2023/1114** | The crypto-asset referred to in this white paper is not covered by the investor compensation schemes under Directive 97/9/EC of the European Parliament and of the Council.The crypto-asset referred to in this white paper is not covered by the deposit guarantee schemes under Directive 2014/49/EU of the European Parliament and of the Council. |
| **SUMMARY** | | |
| **7** | **Warning in accordance with Article 6(7), second subparagraph of Regulation (EU) 2023/1114** | Warning
This summary should be read as an introduction to the crypto-asset white paper. The prospective holder should base any decision to purchase this crypto-asset on the content of the crypto-asset white paper as a whole and not on the summary alone.
The admission to trading of this crypto-asset does not constitute an offer or solicitation to purchase financial instruments and any such offer or solicitation can be made only by means of a prospectus or other offer documents pursuant to the applicable national law.
This crypto-asset white paper does not constitute a prospectus as referred to in Regulation (EU) 2017/1129 of the European Parliament and of the Council (36) or any other offer document pursuant to Union or national law. |
| **8** | **Characteristics of the crypto-asset** | SPK (the "***Token***") will be launched as an ERC-20 token on the Ethereum blockchain. The Token will provide its holders with a set of rights within Spark (the "***Project***"), a decentralised finance application. Holders of SPK may be entitled to participate in decentralised governance, access staking mechanisms, or engage in incentive-based activities, subject to eligibility criteria and the availability of such functionalities. All such rights are exercised through the Project or associated interfaces, or direct interaction with the blockchain, using a self-custodied blockchain wallet.
It is anticipated that the Token will serve as a governance token, allowing holders to help shape the future of the Project. Any governance rights granted to Token holders will be subject to the disclaimers and qualifications made in Section F.3 and Section G.3. The exercise of rights requires active engagement by the holder and may involve network transaction fees (gas fees) payable to the Ethereum blockchain. SPK token holders are responsible for maintaining access to their wallet and acting in accordance with the Spark protocol. |
| **09** | | Not applicable |
| **10** | **Key information about the offer to the public or admission to trading** | Spark Foundation (the "***Foundation***") seeks admission of the Token to trading on multiple trading platforms (the "***Exchanges***") in order to increase the liquidity and exchangeability of the Token, facilitate more participation in governance, and increase the number of tokens staked that may secure one or more components of the Project. |
| **Part I – Information on risks** | | |
| **I.1** | **Offer-Related Risks** | The Foundation neither operates, controls, oversees, nor manages the functioning of the Exchanges where the Token will be admitted. Additionally, the Token's underlying protocol and governance structure may evolve due to ongoing technical, regulatory, and industry developments. Unforeseen risks may arise, and new challenges or opportunities may necessitate changes in the Project's strategies, goals, and structure. The risks outlined below highlight regulatory uncertainty, liquidity limitations, governance risks, network centralisation concerns, security vulnerabilities, and potential adjustments to fees or token supply that could impact the offer and trading of the Token.
**Regulatory Compliance Risks**: Evolving regulatory landscapes could impact the Token's classification, trading status, or market acceptance. Changes in regulatory requirements may necessitate modifications to the Project's operation, structure, or governance. **Market Volatility**: The Token may be subject to extreme price fluctuations, influenced by speculation, market sentiment, and broader industry trends. External factors, such as regulatory announcements or technological developments, may further contribute to volatility, potentially leading to financial losses for holders. **Liquidity Risks**: The ability to buy and sell Tokens depends on trading activity on decentralised exchanges ("***DEXs***") and, if applicable, centralised exchanges ("***CEXs***"). Limited liquidity may result in difficulties executing large trades without significant price impact, increasing the risk of loss. **Risk of Trading Platforms**: When Token holders trade on Exchanges, neither the Issuer nor the Foundation acts as a contractual party to these transactions. All legal relationships regarding these trading platforms are subject to their respective terms and conditions, with no responsibility assumed by the Foundation for their operations, services, or outcomes. **Risk of Delisting**: There is no guarantee that the Token will remain listed on any exchange. Delisting could significantly hinder the ability to trade Tokens, reducing liquidity and market value. **Risk of Bankruptcy**: The Exchanges or trading platforms where the Token is listed may become insolvent or cease operations, potentially resulting in a loss of access to funds or Tokens. **Blockchain and Smart Contract Dependency**: The Token relies entirely on its blockchain infrastructure. Any network downtime, congestion, security vulnerabilities, or smart contract failures could negatively impact its functionality, accessibility, or security. **Governance and Economic Model Risks**: While no inflationary events are currently anticipated, Sky governance will retain the power to mint new Tokens in the future. **Legal Risks**: Uncertainties in legal frameworks, regulatory changes, potential lawsuits, or adverse legal rulings could pose significant risks, affecting the value of the Token. **Reputational Risks**: Negative publicity – whether due to operational failures, security breaches, or associations with illicit activities—could damage the Project's reputation and, by extension, impact the value and acceptance of the Token. **Technology Management Risks**: Inadequate management of technological updates or failure to keep pace with advancements may result in security vulnerabilities, inefficiencies, or obsolescence of the Token and its supporting infrastructure. **Concentration and Conflicts of Interest**: Concentration of Token holdings may lead to governance decisions that favour the interests of one or more specific holders rather than the interests of the community, potentially affecting the value of the Token. **Decentralised Governance Risk**: The majority of the Token supply will be managed by decentralised governance, including Sky governance and Spark governance. Risks associated with decentralised governance, including without limitation the risk of capture, may negatively impact the value of the Token. **Industry Competition Risks**: The Project faces competition from other projects, including larger and well-funded ventures that may attract more users and liquidity, potentially diminishing the viability of the Token. **Unanticipated Risks**: There may be additional risks that cannot be foreseen. Some risks may materialise as unexpected variations or combinations of the factors discussed in this section. |
| **I.2** | **Issuer-Related Risks** | The Issuer's sole function is to issue and distribute the Tokens. It does not manage or operate any technical infrastructure, oversee governance processes, or maintain control over the protocol or community.
**Operational Risk**: This limited operational role means the Issuer cannot respond to technical failures, governance disputes, or security incidents within the broader ecosystem. If issues arise post-distribution such as bugs in smart contracts or shifts in network governance, the Issuer has no authority or capacity to intervene or implement corrective measures. **Decentralized Governance Risk**: Furthermore, all post-distribution developments depend on decentralised community governance or third-party contributors, over whom the Issuer has no influence. Participants should therefore understand that their reliance on the Issuer is limited strictly to the issuance of the Tokens. Any expectations beyond that, whether technical, economic, or governance-related, must be assessed based on the broader ecosystem's operations and risks. |
| **I.3** | **Crypto-Assets-related Risks** | **Market Volatility Risks**: It is anticipated that the Token's value will be highly volatile and may fluctuate due to market speculation, investor sentiment, regulatory developments, and technological advancements. External factors, such as shifting trends in the crypto industry, changes in demand for blockchain services, or macroeconomic conditions, could contribute to extreme price fluctuations, potentially leading to total depreciation. **Liquidity Risks**: The ability to trade the Token depends on the level of activity on DEXs and, where applicable, CEXs. Low trading volume may result in difficulties executing large transactions without significant price impact. Limited demand for the Token or the underlying protocol may further reduce liquidity, making it difficult to acquire or sell the Token. **Adoption and Project Demand Risks**: The long-term success of the Token is dependent on widespread adoption of the Project. Adoption is influenced by various external factors, including user demand, competitive market conditions, and organic community-driven expansion. The Foundation has no control over the pace of adoption, and there is no guarantee that the Project will gain sufficient traction to sustain its economic model. **Blockchain Dependency Risks**: The Token operates exclusively on its underlying blockchain network. Any disruptions, such as network congestion, downtime, or security vulnerabilities, could impact the ability to transfer, store, or trade the Token. Changes to blockchain infrastructure, governance, or transaction fees may also influence the Token's usability and cost-effectiveness. **Transaction Costs:** While blockchain fees are generally low, network congestion, high demand, or changes in blockchain fee structures may increase transaction costs, potentially reducing the economic viability of using the Token. **Security Risks**: ***Smart Contract Vulnerabilities***: Despite security audits and best practices, unforeseen vulnerabilities in smart contracts could lead to security breaches, impacting Token security or functionality. ***Private Key Management***: Token holders are solely responsible for safeguarding their private keys and recovery phrases. Loss of wallet credentials will result in the permanent loss of Tokens, as blockchain transactions are irreversible. **Scam and Fraud Risks**: Token holders are exposed to risks associated with scams, phishing attacks, fake giveaways, impersonation of the Foundation or its team, counterfeit Tokens, and fraudulent airdrops. Engaging with unverified third-party platforms or unofficial communications increases the risk of fraud. **Community and Narrative Risks**: The Token's success is closely tied to community interest and the broader crypto narrative. Market trends, emerging competitors, or declining community engagement may negatively impact the Token's perceived value and adoption. **Regulatory and Compliance Risks**: ***Evolving Legal Frameworks***: Regulations governing crypto-assets differ across jurisdictions and are subject to change. New legal requirements may impact the Token's classification, availability, or functionality. ***Jurisdictional Restrictions***: Some jurisdictions may impose restrictions or prohibitions on the trading or use of the Token, limiting its accessibility for certain users. **Technological Obsolescence Risks**: The blockchain and crypto industries evolve rapidly. The emergence of new technologies, changes in market demand, or advancements in competing protocols could render the Token or its underlying blockchain infrastructure less competitive, reducing adoption and utility. **Software Weakness Risks**: The Token's infrastructure relies on relatively new blockchain technologies, which may contain undiscovered bugs, vulnerabilities, or inefficiencies. There is no guarantee that the process of transacting, storing, or interacting with the Token will be uninterrupted or error-free. **Unanticipated Risks**: Beyond the risks outlined above, additional unforeseen risks may emerge due to changes in regulatory, technological, or market conditions, potentially affecting the Token's security, functionality, or value. |
| **I.4** | **Project Implementation-Related Risks** | The Foundation neither operates, controls, oversees, nor manages the technology underlying the Project. While efforts are made to ensure security and stability, blockchain-based technologies are still evolving, and various risks exist. Additionally, the success and sustainability of the Project rely on various external factors, including market conditions, regulatory developments, and technological advancements.
**Technical Development Risks**: ***Smart Contract Issues***: Despite robust security measures, unforeseen vulnerabilities or bugs in the smart contracts could disrupt Token distribution, refunds, or vesting mechanisms.
***Blockchain Dependency***: The Token operates exclusively on its underlying blockchain. Any network congestion, downtime, or security breaches could impact the Project's implementation and functionality. ***Risk of Security Weaknesses in Core Infrastructure***: The Project relies on open-source software, which may be modified by third parties. Weaknesses or bugs introduced into the core infrastructure could compromise security and lead to the loss of digital assets. Furthermore, malfunctions or inadequate maintenance of the Project may negatively impact the Token's usability. ***Bugs in Core Blockchain Code***: Even with rigorous testing, unknown bugs may exist in the blockchain protocol, potentially leading to disruptions, incorrect transaction processing, or security vulnerabilities. **Regulatory and Compliance Risks:** ***Regulatory Actions in One or More Jurisdictions***: The Token and the underlying Project could be impacted by regulatory inquiries or actions, which may restrict further development, implementation, or usage. ***Evolving Laws and Regulations***: New and changing laws related to financial securities, consumer protection, data privacy, cybersecurity, and intellectual property could impact the Project and the Token. ***Governance Risk***: Decision-making mechanisms in blockchain governance may be inefficient, slow, or disproportionately influenced by specific stakeholders, leading to potential centralisation or unfavourable governance outcomes. **Operational Risks**: ***Resource Allocation***: The Project's success depends on the team allocating sufficient resources (both financial and non-financial) to ensure timely development and deployment. Poor resource management could lead to delays or failure to achieve key milestones. **Market Adoption Risks**: ***Competitive Environment***: The crypto-asset market is highly competitive and trend-driven. There is a risk that the Token may fail to capture sufficient interest, limiting its adoption. ***Community Engagement Risks***: The success of the Token depends heavily on community-driven marketing and engagement. Failure to build or sustain an active community could hinder growth and long-term tradability. **Timeline and Milestone Risks**: ***Delayed Milestones***: Key milestones may face delays due to technical, operational, or funding challenges. ***CEX Listing Risks***: Listings on centralised exchanges depend on securing the necessary funding for listing fees and meeting platform-specific requirements. Delays or insufficient resources could postpone broader market access. **Ecosystem Risks**: ***Dependence on External Parties***: The Project relies on infrastructure providers and other third-party service providers. Any failure or delay from third-parties could disrupt implementation plans. **Technology and Software Risks**: ***Risk of Software Weakness***: Blockchain and smart contract technologies are still evolving. There is no guarantee that Token usage will be uninterrupted or error-free. Vulnerabilities in the underlying blockchain, smart contracts, or supporting technologies could lead to the complete loss of Tokens or their functionality. ***Dependency on Underlying Technology***: The Project relies on blockchain infrastructure, hardware, and network connectivity, all of which may be subject to failures, outages, or vulnerabilities. ***Risk of Technological Disruption***: The emergence of new technology, such as quantum computing, could undermine the security of blockchain encryption and compromise the integrity of digital assets. **Network Security Risks**: ***Network Attacks and Cybersecurity Threats***: Blockchain networks can be vulnerable to cyberattacks such as 51% attacks, Sybil attacks, or distributed denial-of-service ("***DDoS***") attacks. These threats could disrupt network operations and compromise security. ***Blockchain Network Attacks***: The Network may be subject to mining attacks, including double-spend attacks, reorganisations, majority mining power attacks, "selfish-mining" attacks, and work race condition attacks. Successful attacks could compromise the proper execution of transactions and smart contracts. **Privacy and Anonymity Risks**: ***Public Ledger Transparency***: Blockchain transactions are recorded on a public ledger, which may expose transaction history and financial activity. Certain transactions could be linked to specific wallet addresses, making users vulnerable to fraud, phishing attacks, or targeted scams. **Economic and Governance Risks**: ***Incentive Model Risks***: Governance decisions could result in modifications that impact Token holders, including inflationary adjustments, transaction fees, or redistribution of rewards. **Software Weakness Risks**: ***Unforeseen Bugs and Security Vulnerabilities***: The Token and its supporting infrastructure rely on blockchain technologies that may still be evolving. There is no guarantee that Token transactions will be uninterrupted or error-free. Software vulnerabilities, weaknesses in smart contracts, or infrastructure issues may result in loss of assets, security breaches, or unexpected network failures. **Unanticipated Risks**: ***Unforeseen Regulatory, Technological, or Market Challenges***: In addition to the risks identified, new threats may emerge due to changes in legal, technological, or economic conditions. Developments such as regulatory actions, unforeseen Project vulnerabilities, or disruptive innovations could impact the usability, security, or value of the Token in ways not currently foreseeable. |
| **I.5** | **Technology-Related Risks** | The Foundation neither operates, controls, oversees, nor manages the technology underlying the Project. While efforts are made to ensure security and stability, blockchain-based technologies are still evolving, and various risks exist. **Blockchain Dependency Risks**: ***Network Downtime and Congestion***: The Token relies entirely on its underlying blockchain network, which may experience outages, congestion, or downtime. Such events could disrupt Token transfers, trading, or other functionalities. ***Scalability Challenges***: As transaction volume grows, the blockchain network may face scaling limitations. Increased congestion could lead to slower transaction processing times and higher fees, reducing efficiency and usability. ***Settlement and Transaction Finality Risks***: Blockchain transactions are designed to be irreversible; however, under exceptional circumstances such as network forks or consensus failures, there remains a theoretical risk that transactions could be reversed or multiple competing ledger versions could persist. Transactions sent to an incorrect address are not recoverable, leading to permanent loss of assets. **Smart Contract Risks**: ***Immutability Risks***: Once deployed, some smart contracts cannot be altered. Errors or security flaws in the code could result in operational failures without the possibility of corrections. ***Security Exploits***: Bugs or vulnerabilities in smart contracts may expose the Token ecosystem to potential hacks, allowing attackers to manipulate transactions, drain liquidity, or disrupt contract execution. **Wallet and Storage Risks**: ***Private Key Management***: Token holders are solely responsible for securing their private keys and recovery phrases. The loss of private keys results in irreversible loss of Tokens, as blockchain transactions are final and cannot be undone. ***Compatibility Issues***: The Token is supported only by blockchain-compatible wallets. Incompatibility with specific wallet software, network malfunctions, or wallet provider shutdowns may affect access to and usability of the Token. **Ecosystem Dependency Risks**: ***DEX and CEX Integration Issues***: The Token's availability depends on integration with DEXs and CEXs. Technical failures, security breaches, or de-listings from these platforms could limit liquidity, disrupt trading, and reduce market accessibility. ***Reliance on Third-Party Services***: Many blockchain services, including wallets, bridges, and oracles, depend on third-party providers. Failures, security breaches, or regulatory actions against these services could negatively affect the functionality of the Token. **Software and Project Risks**: ***Risk of Attacks and Forks***: The underlying blockchain may be susceptible to consensus-related attacks, such as double-spend attacks, majority validation power takeovers, censorship attacks, or forks. These risks could affect Token transactions, balance integrity, and overall network security. ***Risk of Technological Disruption***: Emerging technologies, such as quantum computing, could potentially compromise blockchain encryption, making networks vulnerable to attacks that could compromise data integrity or enable unauthorised asset transfers. ***Dependency on Underlying Technology***: The stability of the Token ecosystem relies on underlying technical infrastructures, including internet connectivity, computing hardware, and cryptographic algorithms. Disruptions in these foundational technologies may impact network security and operational efficiency. ***Unforeseen Vulnerabilities in Blockchain***: The Token and its supporting infrastructure rely on blockchain technologies that may still be evolving. There is no guarantee that Token transactions will be uninterrupted or error-free. Software vulnerabilities, weaknesses in smart contracts, or infrastructure issues may result in loss of assets, security breaches, or unexpected network failures. **Privacy and Anonymity Risks**: ***Public Ledger Transparency***: Blockchain transactions are recorded on a publicly accessible ledger, which may expose sensitive transaction data. While addresses do not directly reveal identities, sophisticated data analysis could potentially link certain transactions to specific individuals or entities. ***Exposure to Fraud and Targeted Attacks***: Increased transparency may lead to risks such as phishing, fraud, or unauthorised tracking of user activity by malicious actors. Individuals with significant Token holdings may be targeted for scams or social engineering attacks. **Economic and Project Viability Risks**: ***Incentive Model Risks***: Governance proposals may introduce modifications that impact Token holders, including inflation adjustments, transaction fees, or changes to rewards. **Unanticipated Risks**: ***Unforeseen Regulatory, Technological, or Market Challenges***: In addition to the risks identified, new threats may emerge due to changes in legal, technological, or economic conditions. Developments such as regulatory actions, unforeseen Project vulnerabilities, or disruptive innovations could impact the usability, security, or value of the Token in ways not currently foreseeable. |
| **I.6** | **Mitigation measures** | To address the range of risks associated with the Token, the Project has implemented multiple mitigation strategies across technical, operational, and governance layers.
Smart Contract Audits: All critical smart contracts are subject to external audits by reputable security firms. Audits help identify vulnerabilities before deployment and reduce the likelihood of exploitation. Previous audits are accessible at [http://docs.spark.fi/dev/security/security-and-audits](http://docs.spark.fi/dev/security/security-and-audits). Progressive rollout: The Token distribution and product features are introduced gradually to allow for testing and feedback, minimising systemic risk and improving resilience. Decentralised Governance: The Token's governance is structured through community mechanisms, including SparkDAO and SkyDAO governance. This provides checks and balances, limits centralised control, and enables dynamic adaptation to new risks. Transparent communication: Ongoing disclosures via public documentation, white paper updates, forums, and governance proposals foster community awareness and help participants make informed decisions. Liquidity support and listings: While no guarantee is provided, the Issuer and the Foundation may collaborate with market participants to encourage liquidity provision and exchange listings where feasible. Regulatory Alignment: The Project tracks legal developments in key jurisdictions to align with regulatory frameworks, particularly those under MiCA.
These measures do not eliminate risk, but they significantly reduce the likelihood or severity of adverse events. Participants should still exercise caution and adopt personal risk management strategies when engaging with the Tokens or the broader Spark ecosystem. |
| **Part A - Information about the offeror or the person seeking admission to trading** | | |
| **A.1** | **Name** | Spark Foundation |
| **A.2** | **Legal form** | Foundation company limited by guarantee without share capital |
| **A.3** | **Registered address** | Leeward Management Limited, Suite 3119, 9 Forum Lane, Camana Bay, PO Box 144, George Town, Grand Cayman KY1-9006, Cayman Islands |
| **A.4** | **Head office** | Leeward Management Limited, Suite 3119, 9 Forum Lane, Camana Bay, PO Box 144, George Town, Grand Cayman KY1-9006, Cayman Islands |
| **A.5** | **Registration Date** | 2025-02-05 |
| **A.6** | **Legal entity identifier** | Not available |
| **A.7** | **Another identifier required pursuant to applicable national law** | 418210 |
| **A.8** | **Contact telephone number** | 001 345-749-9601 |
| **A.9** | **E-mail address** | Glenn Kennedy: [gkennedy@leewardmanagement.ky](mailto\:gkennedy@leewardmanagement.ky) Marc Piano: [piano@horizonsglobal.io](mailto\:piano@horizonsglobal.io) |
| **A.10** | **Response Time (Days)** | Fourteen (14) days |
| **A.11** | **Parent Company** | Not applicable |
| **A.12** | **Members of the Management body** | **Glenn Kennedy** Director Leeward Management Limited, Suite 3119, 9 Forum Lane, Camana Bay, PO Box 144, George Town, Grand Cayman KY1-9006, Cayman Islands
**Marc Piano** Director Leeward Management Limited, Suite 3119, 9 Forum Lane, Camana Bay, PO Box 144, George Town, Grand Cayman KY1-9006, Cayman Islands |
| **A.13** | **Business Activity** | To support, promote, and advance the development, adoption, security, and growth of Spark. |
| **A.14** | **Parent Company Business Activity** | Not applicable |
| **A.15** | **Newly Established** | TRUE |
| **A.16** | **Financial condition for the past three years** | Not applicable |
| **A.17** | **Financial condition since registration** | The Foundation will be capitalised as needed to fulfil its mandate of supporting the Spark ecosystem. It has no debt and being a brand new company, should have no material liabilities as of the date of this whitepaper. |
| **Part B - Information about the issuer, if different from the offeror or person seeking admission to trading** | | |
| **B.1** | **Issuer different from offeror or person seeking admission to trading** | TRUE |
| **B.2** | **Name** | SPK Company Ltd. |
| **B.3** | **Legal form** | Company limited by shares |
| **B.4** | **Registered address** | SHRM Trustees (BVI) Limited of Trinity Chambers, PO Box 4301, Road Town, Tortola, British Virgin Islands |
| **B.5** | **Head office** | SHRM Trustees (BVI) Limited of Trinity Chambers, PO Box 4301, Road Town, Tortola, British Virgin Islands |
| **B.6** | **Registration Date** | 2025-02-19 |
| **B.7** | **Legal entity identifier** | Not available |
| **B.8** | **Another identifier required pursuant to applicable national law** | 2170013 |
| **B.9** | **Parent Company** | Spark Foundation |
| **B.10** | **Members of the Management body** | The sole director of the Issuer is **Spark Foundation**
The directors of Spark Foundation are Glenn Kennedy and Marc Piano
Business address of Spark Foundation is Leeward Management Limited, Suite 3119, 9 Forum Lane, Camana Bay, PO Box 144, George Town, Grand Cayman KY1-9006, Cayman Islands |
| **B.11** | **Business Activity** | The only purpose is to issue and distribute the Token. |
| **B.12** | **Parent Company Business Activity** | See Section A.13. |
| **Part C - Information about the operator of the trading platform in cases where it draws up the crypto-asset white paper and information about other persons drawing the crypto-asset white paper pursuant to Article 6(1), second subparagraph, of Regulation (EU) 2023/1114** | | |
| **C.1** | **Name** | Not applicable |
| **C.2** | **Legal form** | Not applicable |
| **C.3** | **Registered address** | Not applicable |
| **C.4** | **Head office** | Not applicable |
| **C.5** | **Registration Date** | Not applicable |
| **C.6** | **Legal entity identifier of the operator of the trading platform** | Not applicable |
| **C.7** | **Another identifier required pursuant to applicable national law** | Not applicable |
| **C.8** | **Parent Company** | Not applicable |
| **C.9** | **Reason for Crypto-Asset White Paper Preparation** | Not applicable |
| **C.10** | **Members of the Management body** | Not applicable |
| **C.11** | **Operator Business Activity** | Not applicable |
| **C.12** | **Parent Company Business Activity** | Not applicable |
| **C.13** | **Other persons drawing up the crypto-asset white paper according to Article 6(1), second subparagraph, of Regulation (EU) 2023/1114** | Not applicable |
| **C.14** | **Reason for drawing the white paper by persons referred to in Article 6(1), second subparagraph, of Regulation (EU) 2023/1114** | Not applicable |
| **Part D - Information about the crypto-asset project** | | |
| **D.1** | **Crypto-asset project name** | Spark |
| **D.2** | **Crypto-assets name** | Spark |
| **D.3** | **Abbreviation** | SPK |
| **D.4** | **Crypto-asset project description** | The Project is a DeFi protocol which emerged from Sky, previously known as MakerDAO, and serves as a 'Sky Star', a subDAO within the Sky ecosystem. It consists of three main components: SparkLend, a stablecoin lending market; Spark Savings, for earning yield on certain stablecoins; and Spark Liquidity Layer, a backend capital allocator that routes liquidity across select DeFi protocols. |
| **D.5** | **Details of all natural or legal persons involved in the implementation of the crypto-asset project** | **SPK Company, Ltd.** c/o SHRM Trustee (BVI) Ltd. Trinity Chambers PO Box 4301 Road Town, Tortola, British Virgin Islands
**Spark Foundation** c/o Leeward Management Limited Suite 3119, 9 Forum Lane Camana Bay, George Town, Grand Cayman KY1-9006, Cayman Islands |
| **D.6** | **Utility Token Classification** | FALSE |
| **D.7** | **Key Features of Goods/Services for Utility Token Projects** | Not applicable |
| **D.8** | **Plans for the token** | **Rewards:** Soon after the token generation event, a portion of the Token allocation will be used for airdrops to reward early supporters of the Project as well as its early users. Tokens may also be used in the future to reward users who use the Project. **Staking in exchange for Rewards:** Token holders may be given the option to stake their Tokens to contribute to the network's resilience or participate in reward systems. Staking mechanisms could be linked to protocol components such as cross-chain infrastructure or security features, although specifics may evolve based on governance decisions and technical development. Staking may involve time-bound commitments, and the Foundation anticipates that rewards, if any, will reflect the level of engagement and the function being supported. **Governance:** It is anticipated that the Token will serve as a governance token, allowing holders to help shape the future of the Project. Any governance rights granted to Token holders will be subject to the disclaimers and qualifications made in Section F.3 and Section G.3. **Future Outlook:** As the the Project grows, the Tokens may become relevant in additional modules or integrations, including those related to cross-chain operations, coordination layers, or service modules. These developments will be introduced incrementally and in alignment with broader ecosystem goals. **Vision:** The vision for the Tokens is to support a sustainable, community-driven network. Its role is not fixed but is intended to reflect the evolving needs of a decentralised ecosystem prioritising fairness, resilience, and meaningful engagement. |
| **D.9** | **Resource Allocation** | Allocated resources include technical resources from developers, legal and compliance resources from counsel, and financial resources by means of grants from Sky's DAO. |
| **D.10** | **Planned Use of Collected Funds or Crypto-Assets** | Not applicable |
| **Part E - Information about the offer to the public of crypto-assets or their admission to trading** | | |
| **E.1** | **Public Offering or Admission to trading** | ATTR |
| **E.2** | **Reasons for Public Offer or Admission to trading** | The Foundation seeks admission of the Token to trading on multiple Exchanges in order to increase the liquidity and exchangeability of the Token, facilitate more participation in governance, and increase the number of tokens staked that may secure one or more components of the Project. |
| **E.3** | **Fundraising Target** | Not applicable |
| **E.4** | **Minimum Subscription Goals** | Not applicable |
| **E.5** | **Maximum Subscription Goal** | Not applicable |
| **E.6** | **Oversubscription Acceptance** | Not applicable |
| **E.7** | **Oversubscription Allocation** | Not applicable |
| **E.8** | **Issue Price** | Not applicable |
| **E.9** | **Official currency or any other crypto-assets determining the issue price** | Not applicable |
| **E.10** | **Subscription fee** | Not applicable |
| **E.11** | **Offer Price Determination Method** | Not applicable |
| **E.12** | **Total Number of Offered/Traded Crypto-Assets** | Not applicable |
| **E.13** | **Targeted Holders** | ALL |
| **E.14** | **Holder restrictions** | The purchase of the Token from EU-regulated Exchanges will be available to all users of such Exchanges. Most trading and exchange services offered by Exchanges are open to retail holders and may be subject to the compliance requirements of the respective Exchange.
The Exchanges may impose restrictions on holders of Tokens on their respective Exchanges, in accordance with applicable laws and internal policies. |
| **E.15** | **Reimbursement Notice** | Not applicable |
| **E.16** | **Refund Mechanism** | Not applicable |
| **E.17** | **Refund Timeline** | Not applicable |
| **E.18** | **Offer Phases** | Not applicable |
| **E.19** | **Early Purchase Discount** | Not applicable |
| **E.20** | **Time-limited offer** | Not applicable |
| **E.21** | **Subscription period beginning** | Not applicable |
| **E.22** | **Subscription period end** | Not applicable |
| **E.23** | **Safeguarding Arrangements for Offered Funds/Crypto-Assets** | Not applicable |
| **E.24** | **Payment Methods for Crypto-Asset Purchase** | The methods available for purchasing the Token depend on the functionality and policies of the Exchanges or other third-party platforms through which the Token is admitted to trading. Accepted payment methods may include fiat currencies, other crypto-assets, or stablecoins, subject to the configuration and offerings of each respective platform. |
| **E.25** | **Value Transfer Methods for Reimbursement** | Not applicable |
| **E.26** | **Right of Withdrawal** | Not applicable |
| **E.27** | **Transfer of Purchased Crypto-Assets** | Not applicable |
| **E.28** | **Transfer Time Schedule** | Not applicable |
| **E.29** | **Purchaser's Technical Requirements** | To access and trade the Tokens following their admission to trading, purchasers must meet certain technical requirements. These requirements are primarily determined by the centralized Exchanges where the Tokens are listed, and may include the following:
A device (computer or mobile) capable of securely accessing and operating an account on an Exchange; A stable internet connection to interact with the Exchange interface and execute transactions; The ability to receive and store Tokens within the exchange account infrastructure, as provided by the Exchange;
Where trading takes place on decentralized exchanges (DEXs), or where tokens are withdrawn to self-custodied wallets, additional technical requirements apply:
Access to a compatible digital wallet capable of interacting with the Token's blockchain (e.g., Ethereum for ERC-20 Tokens); Secure management of private keys and recovery phrases; The ability to sign transactions and pay applicable network (gas) fees on the Ethereum blockchain.
The Foundation does not provide technical infrastructure such as exchange access, custody services, or wallets. It is the responsibility of the purchaser to ensure that all relevant technical requirements are met in order to receive and transact with the Tokens. |
| **E.30** | **Crypto-asset service provider (CASP) name** | Not applicable |
| **E.31** | **CASP identifier** | Not applicable |
| **E.32** | **Placement form** | NTAV |
| **E.33** | **Trading Platforms name** | **OKX**: [https://www.okx.com/](https://www.okx.com/) **Binance**: [https://www.binance.com/](https://www.binance.com/) **Upbit**: [https://upbit.com/](https://upbit.com/) **Coinbase**: [https://www.coinbase.com/](https://www.coinbase.com/) **Bybit**: [https://www.bybit.com/](https://www.bybit.com/) **Gate.io**: [https://www.gate.io/](https://www.gate.io/) **Bithumb**: [https://www.bithumb.com/](https://www.bithumb.com/) **KuCoin**: [https://www.kucoin.com/](https://www.kucoin.com/) **Kraken**: [https://www.kraken.com/](https://www.kraken.com/) **Bitget**: [https://www.bitget.com/](https://www.bitget.com/) **HTX**: [https://www.htx.com/](https://www.htx.com/) **Crypto.com**: [https://crypto.com/](https://crypto.com/) **Bitvavo**: [https://bitvavo.com/](https://bitvavo.com/) **Bitkub**: [https://www.bitkub.com/](https://www.bitkub.com/) **MEXC**: [https://www.mexc.com/](https://www.mexc.com/) **Coinone**: [https://coinone.co.kr/](https://coinone.co.kr/) **Bitstamp**: [https://www.bitstamp.net/](https://www.bitstamp.net/) **Revolut**: [https://www.revolut.com/](https://www.revolut.com/) **Paribu**: [https://www.paribu.com/](https://www.paribu.com/) **Pintu**: [https://pintu.co.id/](https://pintu.co.id/) **LBank**: [https://www.lbank.info/](https://www.lbank.info/) **Bitpanda**: [https://www.bitpanda.com/](https://www.bitpanda.com/) **Ourbit**: [https://www.ourbit.com/](https://www.ourbit.com/) **Hashkey**: [https://www.hashkey.com/](https://www.hashkey.com/) **Bitfinex**: [https://www.bitfinex.com/](https://www.bitfinex.com/) **CoinDCX**: [https://coindcx.com/](https://coindcx.com/) **BTSE**: [https://www.btse.com/](https://www.btse.com/) **BitMEX**: [https://www.bitmex.com/](https://www.bitmex.com/) **XT.COM**: [https://www.xt.com/](https://www.xt.com/) **Bilaxy**: [https://www.bilaxy.com/](https://www.bilaxy.com/) **AscendEX**: [https://ascendex.com/](https://ascendex.com/) **CoinList**: [https://coinlist.co/](https://coinlist.co/) **BingX**: [https://www.bingx.com/](https://www.bingx.com/) **BitMart**: [https://www.bitmart.com/](https://www.bitmart.com/) **CoinW**: [https://www.coinw.com/](https://www.coinw.com/) **WhiteBIT**: [https://whitebit.com/](https://whitebit.com/) **Bitrue**: [https://www.bitrue.com/](https://www.bitrue.com/) **Phemex**: [https://phemex.com/](https://phemex.com/) **WazirX**: [https://wazirx.com/](https://wazirx.com/) **WOO X**: [https://woo.org/](https://woo.org/) **Poloniex**: [https://poloniex.com/](https://poloniex.com/) |
| **E.34** | **Trading Platforms Market Identifier Code (MIC)** | Not applicable |
| **E.35** | **Trading Platforms Access** | The Exchanges are accessible via their respective websites. |
| **E.36** | **Involved costs** | Not applicable |
| **E.37** | **Offer Expenses** | Not applicable |
| **E.38** | **Conflicts of Interest** | Not applicable |
| **E.39** | **Applicable law** | This white paper is being published solely for purposes of admission to trading, not an offer to the public of the Token. However, subject to mandatory applicable law, to the extent legal disputes arise in relation to the Token, such matters would likely fall under the laws of the British Virgin Islands, the jurisdiction of incorporation of the Issuer, and be subject to the courts of that jurisdiction. |
| **E.40** | **Competent court** | See Section E.39. |
| **Part F - Information about the crypto-assets** | | |
| **F.1** | **Crypto-Asset Type** | Crypto-asset other than an asset-referenced token or e-money token |
| **F.2** | **Crypto-Asset Functionality** | According to the article 3(1)(5) of MiCA, a crypto-asset is a digital representation of a value or of a right that is able to be transferred and stored electronically using distributed ledger technology or similar technology. As reminded by the European Banking Authority ("EBA"), the term 'right' should be interpreted broadly in accordance with recital (2) of MiCA.
The Token qualifies as a crypto-asset within the meaning of MiCA, as it is a digital representation of the right to access the Ecosystem and participate in the Ecosystem's governance. The Token can be transferred and stored using the distributed ledger technology ("DLT").
The Token displays the following functionalities:
**Rewards and Incentive Structures:** The Token is intended to support the long-term functionality, security, and decentralization of the Spark ecosystem through various incentive mechanisms. Token holders may have the opportunity to engage in network activities such as staking, which is designed to enhance protocol resilience and performance. Staking may be associated with specific components of the protocol, for example, cross-chain infrastructure or network security mechanisms, and may require time-bound commitments or minimum engagement thresholds. The Foundation anticipates that rewards, where applicable, will be designed to reflect the level and nature of participation, as determined by the parameters of the relevant mechanism. All such mechanisms, including staking terms and reward structures, remain subject to further refinement through governance processes and technical development. **Governance:** It is anticipated that the Token will serve as a governance token, allowing holders to help shape the future of the Project. Any governance rights granted to Token holders will be subject to the disclaimers and qualifications made in Section F.3 and Section G.3. Overall: The Token is designed primarily as a token for use within the Spark ecosystem, enabling holders to participate in governance, access reward and incentive programs, and interact with protocol features as they evolve over time. |
| **F.3** | **Planned Application of Functionalities** | At the time of publication of this whitepaper, the Foundation anticipates the following: the rewards and incentive structures described in Section F.2 and in other parts of this whitepaper will be made available for the Token holders progressively following the Token Generation Event ('TGE'); and the governance feature described in Section F.2 and in other parts of this whitepaper will also evolve over time by the governance community and development team. Any governance rights granted to Token holders will be subject to any rules applicable to the Project's governance, including but not limited to the Sky Atlas. |
| **A description of the characteristics of the crypto-asset, including the data necessary for classification of the crypto-asset white paper in the register referred to in Article 109 of Regulation (EU) 2023/1114, as specified in accordance with paragraph 8 of that Article** | | |
| **F.4** | **Type of white paper** | OTHR |
| **F.5** | **The type of submission** | MODI |
| **F.6** | **Crypto-Asset Characteristics** | See Section 8. |
| **F.7** | **Commercial name or trading name** | Spark |
| **F.8** | **Website of the issuer** | Neither the Foundation nor the Issuer have a website. The website of the Project is [https://spark.fi/](https://spark.fi/) |
| **F.9** | **Starting date of offer to the public or admission to trading** | 2025-05-28 |
| **F.10** | **Publication date** | 2025-06-03 |
| **F.11** | **Any other services provided by the issuer** | Neither the Foundation nor the Issuer provide any other services not covered by Regulation (EU) 2023/1114. |
| **F.12** | **Identifier of operator of the trading platform** | Not applicable |
| **F.13** | **Language or languages of the white paper** | English |
| **F.14** | **Digital Token Identifier Code used to uniquely identify the crypto-asset or each of the several crypto assets to which the white paper relates, where available** | SPK |
| **F.15** | **Functionally Fungible Group Digital Token Identifier, where available** | Not applicable |
| **F.16** | **Voluntary data flag** | FALSE |
| **F.17** | **Personal data flag** | TRUE |
| **F.18** | **LEI eligibility** | FALSE |
| **F.19** | **Home Member State** | Malta |
| **F.20** | **Host Member States** | The admission to trading of the Token is passported in the following countries: Austria Belgium Bulgaria Croatia Cyprus Czech Republic Germany Denmark Estonia Spain Finland France Greece Hungary Iceland Ireland Italy Latvia Liechtenstein Lithuania Luxembourg Netherlands Norway Poland Portugal Romania Slovakia Slovenia Sweden |
| **Part G - Information on the rights and obligations attached to the crypto-assets** | | |
| **G.1** | **Purchaser Rights and Obligations** | The Token enables its holders to interact with the Project that operates autonomously and without the Foundation having an operative role. As a result, the Foundation, to the fullest extent permitted by applicable laws, disclaims all warranties, whether express or implied. This includes but is not limited to, implied warranties of merchantability and fitness for a particular purpose. Moreover, to the fullest extent permissible by applicable laws, the Foundation is not liable for any damages arising from the holding, use, transfer, or interactions involving Tokens and the Project. This limitation applies to all forms of damages, including direct, indirect, incidental, punitive, and consequential damages. |
| **G.2** | **Exercise of Rights and obligations** | Any rights associated with the Tokens may be exercised exclusively through the designated blockchain interfaces, smart contracts, or governance mechanisms made available. Access to these rights requires that the Token holder maintains control over a compatible self-custodied wallet and engages directly with the supported interfaces. Participation in any functionality associated with the Token shall be subject to the technical implementation of such features and any applicable eligibility conditions, timelines, or procedural requirements as further communicated via official channels of the Spark ecosystem.
The obligations of the Token holders, including the payment of any network fees and compliance with applicable legal requirements, are to be fulfilled independently and at the sole responsibility of the holder. |
| **G.3** | **Conditions for modifications of rights and obligations** | Neither the Foundation nor the Issuer has the ability to unilaterally modify the rights or obligations attached to the Token. However, the functionalities or rights attaching to the Token may be affected by changes made to the Project by the governance community and development team. These protocol-level changes may impact on the ways in which the Token can be used. Holders are encouraged to monitor official protocol channels for updates, including but not limited to the Project's website ([https://spark.fi/](https://spark.fi/)mica). |
| **G.4** | **Future Public Offers** | The Issuer has submitted a white paper for the offering of the Tokens to the public. The white paper will be accessible at [https://spark.fi/mica](https://spark.fi/mica) upon the end of the notification period. |
| **G.5** | **Issuer Retained Crypto-Assets** | 0 |
| **G.6** | **Utility Token Classification** | FALSE |
| **G.7** | **Key Features of Goods/Services of Utility Tokens** | Not applicable |
| **G.8** | **Utility Tokens Redemption** | No redemption |
| **G.9** | **Non-Trading request** | TRUE |
| **G.10** | **Crypto-Assets purchase or sale modalities** | Not applicable |
| **G.11** | **Crypto-Assets Transfer Restrictions** | The Exchanges may impose restrictions on holders of Tokens on their respective Exchanges, in accordance with applicable laws and internal policies. Token holders who acquire the Token through "private sales" are subject to restrictions as per the terms of sale. |
| **G.12** | **Supply Adjustment Protocols** | FALSE |
| **G.13** | **Supply Adjustment Mechanisms** | Sky governance will control the Token's mint and burn functionality. Therefore, modifications to the Token's supply can only occur via a vote of Sky governance. |
| **G.14** | **Token Value Protection Schemes** | FALSE |
| **G.15** | **Token Value Protection Schemes Description** | Not applicable |
| **G.16** | **Compensation Schemes** | FALSE |
| **G.17** | **Compensation Schemes Description** | Not applicable |
| **G.18** | **Applicable law** | Subject to mandatory applicable law, to the extent legal disputes arise in relation to the Token, such matters would likely fall under the laws of the British Virgin Islands, the jurisdiction of incorporation of the Issuer, and be subject to the courts of that jurisdiction. |
| **G.19** | **Competent court** | See Section G.18. |
| **Part H – Information on the underlying technology** | | |
| **H.1** | **Distributed ledger technology** | The Token is deployed on the Ethereum mainnet, a public and permissionless distributed ledger based on blockchain technology. The Token is implemented via a set of smart contracts deployed to Ethereum and is accessible to any compatible wallet. |
| **H.2** | **Protocols and technical standards** | The Token conforms to the ERC-20 token standard and interacts with Ethereum-compatible smart contracts to facilitate distribution, claiming, staking, and governance. Token transfers, approvals, and other on-chain operations follow the established ERC-20 interface. |
| **H.3** | **Technology Used** | As an ERC-20 token, the Token will be deployed as a smart contract on the Ethereum blockchain. Users can manage the Token through their own non-custodial wallet software provided by third parties or by directly interacting with the Token's smart contract through a third-party API. |
| **H.4** | **Consensus Mechanism** | The Token will be launched on the Ethereum blockchain, which relies on a Proof of Stake ("PoS") consensus mechanism. In Ethereum's PoS consensus mechanism, validators are randomly selected to propose and attest to blocks. To participate as an Ethereum validator, they must stake at least 32 ETH and run the software established for that end. |
| **H.5** | **Incentive Mechanisms and Applicable Fees** | Validators are compensated with ETH in exchange for proposing and attesting to proposed blocks. Their compensation is sourced from a portion of transaction fees and a block reward. If validators misbehave, they will be penalised with slashing, involving losing part of their staked ETH.
Every Ethereum transaction requires the payment of gas fees. Since the implementation of EIP-1559, the fee is split into two components:
**Base fee:** Automatically calculated based on network demand and is burned (removed from circulation), and **Priority fee (or tip):** Paid to the validator for including the transaction in a proposed block. The priority fee is earned by the validator that proposed the block in which the transaction is included.
Ethereum validators are incentivised through a combination of block rewards and priority fees paid in ETH. Validators who misbehave, or act maliciously are subject to slashing penalties, resulting in the loss of a portion of their staked ETH. The person seeking admission to trading has no control over Ethereum blockchain fees, validator behaviour, or the consensus process. |
| **H.6** | **Use of Distributed Ledger Technology** | FALSE |
| **H.7** | **DLT Functionality Description** | Not applicable |
| **H.8** | **Audit** | FALSE |
| **H.9** | **Audit outcome** | Not applicable |
| **Part J – Information on the sustainability indicators in relation to adverse impact on the climate and other environment-related adverse impacts** | | |
| **S.01** | **Name** | Spark Foundation |
| **S.02** | **Relevant legal entity identifier** | Not available |
| **S.03** | **Name of the crypto-asset** | SPK |
| **S.04** | **Consensus Mechanism** | The Token will be launched on the Ethereum blockchain, which relies on a PoS consensus mechanism. In Ethereum's PoS consensus mechanism, validators are randomly selected to propose and attest to blocks. To participate as an Ethereum validator, they must stake at least 32 ETH and run the software established for that end. |
| **S.05** | **Incentive Mechanisms and Applicable Fees** | Validators are compensated with ETH in exchange for proposing and attesting to proposed blocks. Their compensation is sourced from a portion of transaction fees and a block reward. If validators misbehave, they will be penalised with slashing, involving losing part of their staked ETH.
Every Ethereum transaction requires the payment of gas fees. Since the implementation of EIP-1559, the fee is split into two components:
**Base fee:** Automatically calculated based on network demand and is burned (removed from circulation), and **Priority fee (or tip):** Paid to the validator for including the transaction in a proposed block. The priority fee is earned by the validator that proposed the block in which the transaction is included.
Ethereum validators are incentivised through a combination of block rewards and priority fees paid in ETH. Validators who misbehave, or act maliciously are subject to slashing penalties, resulting in the loss of a portion of their staked ETH. The person seeking admission to trading has no control over Ethereum blockchain fees, validator behaviour, or the consensus process. |
| **S.06** | **Beginning of the Period to which the Disclosed Information Relates** | 2024/05/08 |
| **S.07** | **End of the Period to which the Disclosed Information Relates** | 2025/05/08 |
| **Mandatory key indicator on energy consumption** | | |
| **S.08** | **Energy Consumption** | 6,490,000 kWh |
| **Sources and methodologies** | | |
| **S.09** | **Energy Consumption Sources and Methodologies** | "For the calculation of energy consumption, a bottom-up approach, as described in the CBNSI methodology, is used. In this approach, Ethereum network nodes are considered the central factor determining total energy demand. Hardware assumptions are based on empirical findings from public information sources, open-source network crawlers, and analytical tools developed by CCAF. The main determinants for estimating the hardware used within the network are the operational requirements of the Ethereum client software. The electricity consumption of the relevant hardware configurations has been measured in certified test laboratories, as set out in the referenced methodology.
CBNSI's model estimates the average power demand of the Ethereum consensus layer on a daily basis, using observed Beacon node counts, client software distribution, and typical hardware profiles. The model then annualises these daily figures to produce an annual electricity consumption estimate.
Secondary cross-check: The CBNSI figures are consistent in order of magnitude with the Digiconomist – Ethereum Energy Consumption Index, which applies a separate estimation methodology.
Reference period: Please refer to S.6 and S.7.
Calculation for SPK token: As SPK is an ERC-20 token on the Ethereum network, the token's share of total network electricity consumption may be approximated by the proportion of total Ethereum gas usage attributable to SPK-related transactions in the reference period. This pro-rata value is calculated as:
`Espk = Ethereum x SPK_gas_used / Total_Ethereum_gas_used`
Since the SPK token has only recently been created, the energy consumption figure relates to the previous calendar year and serves as an estimate of what may be consumed during the SPK token's first year of operation on the Ethereum blockchain. |
| **S.10** | **Renewable energy consumption (%)** | "Based on the CBNSI methodology and the geographical distribution of Ethereum validator nodes, approximately 40.0 % (0.400) of the electricity used for the validation of transactions and the maintenance of the integrity of the Ethereum distributed ledger originates from renewable energy sources.
This percentage is calculated by weighting the renewable share of the electricity grid in each country/region hosting validator nodes according to the proportion of validators located there. Regional renewable share data is sourced from official statistics (e.g., Eurostat for the EU, U.S. Energy Information Administration for the United States, and equivalent agencies for other regions)." |
| **S.11** | **Energy consumption per transaction (kWh/transaction)** | "Based on the total annual energy consumption disclosed in J.8 (6,490,000 kWh) and the total number of Ethereum transactions in the reference period (468,000,000, source: Etherscan), the average energy consumption per transaction is:
This represents the average network-wide figure and is not limited to the SPK-related transactions." |
| **S.12** | **Scope 1 greenhouse gas emissions (tCO₂e/year)** | "For the Ethereum proof-of-stake network, scope 1 greenhouse gas emissions – defined as direct emissions from owned or controlled sources – are negligible, as validators do not burn fossil fuels on-site for consensus operations.
Accordingly, the annualised scope 1 greenhouse gas emissions for the reference period are reported as 0tCO₂e/year." |
| **S.13** | **Scope 2 greenhouse gas emissions (tCO₂e/year)** | "Based on the total annual energy consumption disclosed in J.8 (6 490 000 kWh) and an average grid emission factor of 0.35 kg CO₂e/kWh (source: European Environment Agency – EU residual mix 2023), the estimated annualised scope 2 greenhouse gas emissions are:
`6,490,000 x 0.35kgCO2e ≈ 2,271,500kgCO2e/year)` `(≈ 2,272 tCO2e/year)`
Scope 2 emissions represent indirect emissions from the generation of purchased electricity consumed by Ethereum validators.
Scope 1 emissions for the Ethereum proof-of-stake network are negligible and reported as zero in J.12." |
| **S.14** | **Total greenhouse gas emissions per transaction (kgCO₂e/transaction)** | "Total annual GHG emissions (scope 1 + scope 2) are 2,272 tCO₂e/year (see J.12–J.13). Based on 468,000,000 Ethereum transactions in the reference period, the average emissions per transaction are:
`kgCO2e/tx = 2,272,000 kgCO2e / 468,000,000 tx` `kgCO2e/tx ≈ 0.00485 kgCO2e/tx`" |
| **S.15** | **Sources of data** | "Primary source: Cambridge Centre for Alternative Finance (CCAF) – Cambridge Blockchain Network Sustainability Index (CBNSI) – Ethereum.
Secondary source: Digiconomist – Ethereum Energy Consumption Index (cross-check).
Emissions factor source: European Environment Agency – EU residual mix 2023." |
| **S.16** | **Methodologies applied** | "The energy consumption figures are calculated using CBNSI's "bottom-up" methodology: network node counts, client software distribution, and typical hardware configurations are combined to estimate total network electricity demand. Hardware power draw values are obtained from certified laboratory tests. Daily estimates are annualised using a 7-day moving average. Emissions are calculated by multiplying total electricity consumption by the average grid emission factor for the geographical distribution of nodes. Renewable share is derived from the renewable percentage of the relevant grid mixes. Transaction counts are obtained from on-chain data (Etherscan API).
For SPK, as an ERC-20 token on Ethereum, energy consumption and emissions are expressed at the network level; a pro-rata allocation based on SPK's share of total Ethereum gas usage can also be provided for illustrative purposes." |
## SPK Company Ltd. - SPK Token White paper
Version 4.0 - August 2025
Edition: Markets in Crypto-Assets Regulation White Paper for European Union & European Economic Area.
Date of notification: 2025-08-20
Purpose: Offer to the public of a crypto-asset other than an asset-referenced token or e-money token.
Note: This crypto-asset white paper has not been approved by any competent authority in any Member State of the European Union. The offeror of the crypto-asset is solely responsible for the content of this crypto-asset white paper.
### Table of Contents
* [**Important Notice**](#important-notice)
* [**Warning**](#warning)
* [Characteristics of the crypto-asset](#characteristics-of-the-crypto-asset)
* [Key information about the offer to the public](#key-information-about-the-offer-to-the-public)
* [**Part I – Information on Risks**](#part-i--information-on-risks)
* [I.1 Offer-Related Risks](#i1-offer-related-risks)
* [I.2 Issuer-Related Risks](#i2-issuer-related-risks)
* [I.3 Crypto-Assets-related Risks](#i3-crypto-assets-related-risks)
* [I.4 Project Implementation-Related Risks](#i4-project-implementation-related-risks)
* [I.5 Technology-Related Risks](#i5-technology-related-risks)
* [I.6 Mitigation measures](#i6-mitigation-measures)
* [**Part A – Information About the Offeror of the Crypto-Asset**](#part-a--information-about-the-offeror-of-the-crypto-asset)
* [**Part B – Information About the Issuer, If Different from the Offeror or Person Seeking Admission to Trading**](#part-b--information-about-the-issuer-if-different-from-the-offeror-or-person-seeking-admission-to-trading)
* [**Part C – Information About the Operator of the Trading Platform**](#part-c--information-about-the-operator-of-the-trading-platform)
* [**Part D – Information About Crypto-Asset Project**](#part-d--information-about-crypto-asset-project)
* [D.8 Plans for the token](#d8-plans-for-the-token)
* [D.9 Resource Allocation](#d9-resource-allocation)
* [D.10 Planned Use of Collected Funds or Crypto-Assets](#d10-planned-use-of-collected-funds-or-crypto-assets)
* [**Part E – Information About the Offer to the Public**](#part-e--information-about-the-offer-to-the-public)
* [E.2 Reasons for Public Offer](#e2-reasons-for-public-offer)
* [Refund Mechanism](#refund-mechanism)
* [**Part F – Information About the Crypto-Assets**](#part-f--information-about-the-crypto-assets)
* [**Part G – Information on the Rights and Obligations Attached to the Crypto-Assets**](#part-g--information-on-the-rights-and-obligations-attached-to-the-crypto-assets)
* [**Part H – Information on the Underlying Technology**](#part-h--information-on-the-underlying-technology)
* [**Part J – Information on the Sustainability Indicators in Relation to Adverse Impact on the Climate and Other Environment-Related Adverse Impacts**](#part-j--information-on-the-sustainability-indicators-in-relation-to-adverse-impact-on-the-climate-and-other-environment-related-adverse-impacts)
### IMPORTANT NOTICE
Please carefully review the following notice before proceeding. This notice applies to the entire white paper, regardless of how you received it, whether by email, website access, or any other form of electronic communication. By accessing, reviewing, or otherwise using this white paper, you expressly acknowledge and agree to comply with all terms, conditions, and restrictions outlined herein, including any updates or supplements provided from time to time.
This crypto-asset white paper complies with Title II of Regulation (EU) 2023/1114 (“MiCA”) and, to the best of the knowledge of the management body, the information presented in the crypto-asset white paper is fair, clear and not misleading and the crypto-asset white paper makes no omission likely to affect its import.
The crypto-asset referred to in the White Paper may lose its value partially or in full, may not always be transferable and may not be liquid.
The crypto-asset referred to in this white paper is not covered by the investor compensation schemes under Directive 97/9/EC of the European Parliament and of the Council.
The crypto-asset referred to in this white paper is not covered by the deposit guarantee schemes under Directive 2014/49/EU of the European Parliament and of the Council.
### WARNING
This summary should be read as an introduction to the crypto-asset white paper (the “White Paper”). The offer to the public of this crypto-asset does not constitute an offer or solicitation to purchase financial instruments, and any such offer or solicitation can be made only by means of a prospectus or other offer documents pursuant to the applicable national law.
This crypto-asset white paper does not constitute a prospectus as referred to in Regulation (EU) 2017/1129 of the European Parliament and of the Council (36) or any other offer document pursuant to Union or national law.
### Characteristics of the crypto-asset
SPK is a fungible crypto-asset issued on the Ethereum blockchain, designed for use within the Spark ecosystem. It does not represent ownership, profit rights, or a claim against the Offeror. SPK tokens can be freely held, transferred, and used in accordance with the functionalities described in this White Paper.
Holders of SPK may be entitled to participate in decentralised governance, access staking mechanisms, or engage in incentive-based activities, subject to eligibility criteria and the availability of such functionalities. All such rights are exercised through the Spark application or associated interfaces, or direct interaction with the blockchain, using a self-custodied blockchain wallet.
The exercise of rights requires active engagement by the holder and may involve network transaction fees (gas fees) payable to the Ethereum blockchain. SPK token holders are responsible for maintaining access to their wallet and acting in accordance with the Spark protocol.
The rights and obligations associated with SPK tokens may be modified in the future only through valid governance decisions adopted in accordance with the decentralised governance framework of the Spark protocol. That framework will reflect certain requirements, guidelines and practices derived from Sky governance and the Sky Atlas. Any material change to SPK token functionalities or holder rights will be communicated in accordance with Article 12 of MiCA and reflected in an updated version of this White Paper.
### Key information about the offer to the public
This White Paper relates to the public offering of SPK tokens. The offer consists of multiple distribution phases during which eligible users may claim SPK tokens, subject to conditions described in this document. No payment is required from eligible holders to participate in the offering, and no subscription or placement fees are charged by the Offeror.
The total number of SPK tokens available through this offer is capped at 910,000,000, representing the full allocation set aside for public distribution. There is no minimum or maximum subscription target, and no discounted purchase prices or bonuses for early participants apply, as SPK tokens are distributed without monetary consideration.
The offer is structured in distinct phases based on past activity and also participation in ecosystem-related campaigns. Each phase has a defined eligibility window and a claim period during which users may collect their allocated tokens via the official claiming interface. Claims are processed on-chain and subject to standard Ethereum gas fees.
This offer does not involve an issue price, as SPK tokens are not sold but offered for free to eligible participants. Additional distribution phases may be introduced in the future under this framework, and the White Paper will be updated if material changes occur.
The Offeror seeks to offer the SPK tokens to the public to increase the liquidity and distribution of the Token, facilitate more participation in governance, and increase the number of tokens in circulation.
### PART I – INFORMATION ON RISKS
#### I.1 Offer-Related Risks
Although SPK tokens are distributed without monetary payment, recipients incur potential risks relating to time, effort, and opportunity costs associated with qualifying actions. These include engaging with DeFi protocols, staking tokens, or performing specific on-chain activities.
The primary offer-related risks involve post-receipt use and trading of SPK tokens. Once listed, token value may fluctuate significantly due to market speculation, macroeconomic factors, or project developments, which can affect the perceived benefit of having received the tokens.
Low liquidity on trading venues may impair a recipient's ability to sell or use SPK tokens efficiently. Listings are not guaranteed, and the Offeror cannot ensure continued support from exchanges. A delisting or lack of market depth may result in SPK tokens being practically unusable.
Trading venues, whether decentralised or centralised, pose operational and counterparty risks.
Users may face delays, hacks, or insolvency events, which could hinder access to tokens. Neither the Spark Foundation nor the Offeror is liable for such outcomes.
Any future increase in the total supply of SPK - including the newly approved expansion from 710 million to 910 million tokens - will proportionally reduce each existing holder’s relative stake and may exert downward pressure on the token’s market value.
Smart contract risks also exist during the claim or staking processes. Errors, vulnerabilities, or incorrect wallet use may lead to permanent loss of SPK tokens, despite the token having been free.
Finally, recipients may still incur tax liabilities on receipt, even without monetary investment. Participants must assess these risks individually and ensure compliance with local regulations.
#### I.2 Issuer-Related Risks
The Issuer's sole function is to issue and distribute SPK tokens. It does not manage or operate any technical infrastructure, oversee governance processes, or maintain control over the protocol or community.
This limited operational role means the Issuer cannot respond to technical failures, governance disputes, or security incidents within the broader ecosystem. If issues arise post-distribution such as bugs in smart contracts or shifts in network governance, the Issuer has no authority or capacity to intervene or implement corrective measures.
Furthermore, the Offeror provides no guarantees regarding the future value, usability, or development of the SPK token or the Spark ecosystem. All post-distribution developments depend on decentralised community governance or third-party contributors, over whom the Offeror has no influence.
Participants should therefore understand that their reliance on the Issuer is limited strictly to the issuance of SPK tokens. Any expectations beyond that, whether technical, economic, or governance-related, must be assessed based on the broader ecosystem's operations and risks.
#### I.3 Crypto-Assets-related Risks
As a Crypto-asset, SPK tokens carry risks inherent to digital tokens built on public blockchains. These risks are present regardless of whether a token is purchased or received for free.
SPK operates on the Ethereum network and is subject to blockchain-related vulnerabilities. Network congestion, outages, or high transaction fees could impact users’ ability to claim, transfer, or use SPK tokens in a timely or cost-effective manner.
The token's value is also highly volatile. While there is no direct financial cost to acquiring SPK tokens through airdrops or qualifying actions, token holders may still face opportunity costs if the value declines sharply or if the token becomes unusable due to low adoption or regulatory constraints.
Smart contract vulnerabilities pose another key risk. Even audited contracts can contain bugs or be exploited. Losses stemming from contract-level attacks could affect staking, transfers, or functionality tied to SPK tokens.
Custody of SPK tokens requires secure private key management. Loss or theft of private keys will result in irreversible loss of tokens. Participants are solely responsible for securing their wallet access and recovery information.
SPK token holders may also be targeted by fraud, phishing attacks, or scams that impersonate the Offeror or promote counterfeit tokens. Engaging with unverified links, dApps, or communications could result in loss of assets.
Finally, evolving regulations in different jurisdictions may restrict use or access to SPK, especially if the token is later deemed to fall within specific legal classifications. This could limit its utility or expose holders to compliance obligations.
#### I.4 Project Implementation-Related Risks
The long-term success of SPK is closely tied to the ongoing implementation of the broader Spark project. This process faces a number of technical, operational, and strategic risks.
Technical risks include the potential for bugs or vulnerabilities in smart contracts, governance modules, or infrastructure upgrades. Even with careful development and auditing, errors could affect token functionality or user funds.
Operational risks arise from the allocation of resources, including developer attention, treasury funding, and community engagement. If these are insufficient or misaligned, project timelines may slip or core features may never be completed.
The project’s governance and roadmap are shaped by a decentralised community. This structure can result in slow decision-making, conflicting interests, or even governance capture, where a small group steers development against the broader community's interests.
Adoption risk is also significant. SPK tokens’ utility depends on community participation and real-world integrations. Without active use and credible demand for the Spark ecosystem’s services, the token’s role and relevance may diminish.
In addition, external dependencies such as integration with third-party protocols, platforms, and infrastructure providers can introduce delays or disruptions. Any instability or failure in these components could stall project delivery or impair functionality.
Finally, the broader regulatory and technological environment can shift rapidly. Changes in crypto-asset regulation, competition from new technologies, or loss of ecosystem partners may materially alter the implementation trajectory of the project.
#### I.5 Technology-Related Risks
SPK relies on blockchain infrastructure and smart contract technology that is still evolving. These underlying technologies present several risks that could affect the SPK token's security, performance, and usability.
Distributed ledger networks like the Ethereum blockchain may experience congestion, downtime, or forks, all of which can disrupt token transfers or contract interactions. In extreme cases, users may lose access to their tokens or experience unexpected delays or errors.
Smart contracts governing SPK token-related operations are immutable once deployed. Security flaws or exploits may be used to manipulate SPK token transfers, staking mechanisms, or governance processes.
Token holders are fully responsible for managing their private keys. Mistakes in wallet configuration or loss of access credentials result in permanent token loss, as transactions on the blockchain are irreversible.
Compatibility and access risks may arise if wallet software becomes outdated, unsupported, or incompatible with new SPK token upgrades or infrastructure. Users relying on specific platforms may lose access if those platforms shut down or fail to update their systems.
Moreover, SPK tokens depend on integrations with third-party services like decentralised exchanges, bridges, oracles, and custodians. Failures, security breaches, or regulatory actions affecting these services could degrade SPK tokens’ functionality or cause temporary inaccessibility.
The SPK token is also exposed to long-term risks from technological disruption. Innovations such as quantum computing could weaken cryptographic systems securing blockchain networks. While such risks remain largely theoretical, they could undermine user confidence or lead to structural changes in the network.
In summary, while the SPK ecosystem employs best practices in smart contract development and network integration, the rapidly changing technological landscape presents ongoing risks that may affect security, accessibility, and user experience.
#### I.6 Mitigation measures
To address the range of risks associated with SPK, the project has implemented multiple mitigation strategies across technical, operational, and governance layers.
* **Smart Contract Audits** **–** All critical contracts are subject to external audits by reputable security firms. Audits help identify vulnerabilities before deployment and reduce the likelihood of exploitation. Previous audits are accessible at [http://docs.spark.fi/dev/security/security-and-audits](http://docs.spark.fi/dev/security/security-and-audits).
* **Progressive rollout** **–** SPK token distribution and product features are introduced gradually to allow for testing and feedback, minimising systemic risk and improving resilience.
* **Decentralised Governance** **–** SPK token governance is structured through community mechanisms, including SparkDAO and SkyDAO governance. This provides checks and balances, limits centralised control, and enables dynamic adaptation to new risks.
* **Transparent communication** **–** Ongoing disclosures via public documentation, white paper updates, forums, and governance proposals foster community awareness and help participants make informed decisions.
* **Liquidity support and listings –** While no guarantee is provided, the Offeror may collaborate with market participants to encourage liquidity provision and exchange listings where feasible.
* **Regulatory Alignment** **–** The project tracks legal developments in key jurisdictions to align with regulatory frameworks, particularly those under MiCA.
These measures do not eliminate risk, but they significantly reduce the likelihood or severity of adverse events. Participants should still exercise caution and adopt personal risk management strategies when engaging with SPK tokens or the broader Spark ecosystem.
### PART A – INFORMATION ABOUT THE OFFEROR OF THE CRYPTO-ASSET
#### A.1 Name
SPK Company Ltd.
#### A.2 Legal Form
Company limited by shares
#### A.3 Registered address
SHRM Trustees (BVI) Limited of Trinity Chambers, PO Box 4301.
#### A.4 Head office
Road Town, Tortola, British Virgin Islands
#### A.5 Registration Date
2025-02-19
#### A.6 Legal entity identifier
Not available
#### A.7 Another identifier required pursuant to applicable national law
2170013
#### A.8/9/10 Contacting the Offeror
The Offeror can be contacted by telephone or email using the details provided below. The Offeror will respond within 14 business days.
Glenn Kennedy: [gkennedy@leewardmanagement.ky](mailto\:gkennedy@leewardmanagement.ky)
Marc Piano: [piano@horizonsglobal.io](mailto\:piano@horizonsglobal.io)
Telephone number: +1 345-749-9601 Email address:
The Offeror does not have a website. The website of the project is [https://spark.fi/](https://spark.fi/).
#### A.11 Parent Company
Spark Foundation
#### A.12 Identity of the management body
The sole director of the Offeror is Spark Foundation
The directors of Spark Foundation are Glenn Kennedy and Marc Piano
Business address of Spark Foundation is Leeward Management Limited, Suite 3119, 9 Forum Lane, Camana Bay, PO Box 144, George Town, Grand Cayman KY1-9006, Cayman Islands
#### A.13 Business activity
The only purpose is to issue and distribute the Token.
#### A.14 Parent Company Business Activity
To support, promote, and advance the development, adoption, security, and growth of Spark.
#### A.15 Newly Established
true
#### A.16 Financial condition for the past three years
The Offeror is a newly incorporated company with no material liabilities as of the date of this White Paper. The Offeror will be capitalised as needed to fulfil its mandate of issuing SPK tokens and distributing them.
#### A.17 Financial condition since registration
The Offeror is a newly incorporated company with no material liabilities as of the date of this White Paper. The Offeror will be capitalised as needed to fulfil its mandate of issuing SPK tokens and distributing them.
### PART B – INFORMATION ABOUT THE ISSUER, IF DIFFERENT FROM THE OFFEROR OR PERSON SEEKING ADMISSION TO TRADING
This section is not applicable. Part B does not apply as the issuer and the offeror are the same legal entity.
### PART C – INFORMATION ABOUT THE OPERATOR OF THE TRADING PLATFORM
This section is not applicable. No trading platform has drawn up or contributed to the preparation of this White Paper.
### PART D – INFORMATION ABOUT CRYPTO-ASSET PROJECT
#### D.1 Crypto-asset project name
Spark
#### D.2 Crypto-asset name
Spark
#### D.3 Abbreviation
SPK
#### D.4 Crypto-asset project description
The project is a DeFi protocol, which emerged from Sky, previously known as MakerDAO, and serves as a ‘Sky Star’, a subDAO within the Sky ecosystem. It consists of three main components: SparkLend, a stablecoin lending market; Spark Savings, for earning yield on certain stablecoins; and Spark Liquidity Layer, a backend capital allocator that routes liquidity across select DeFi protocols.
#### D.5 Details of all natural or legal persons involved in the implementation of the crypto-asset project
SPK Company, Ltd.
c/o SHRM Trustee (BVI) Ltd.
Trinity Chambers
PO Box 4301
Road Town, Tortola, British Virgin Islands
Spark Foundation
c/o Leeward Management Limited
Suite 3119, 9 Forum Lane Camana Bay, George Town,
Grand Cayman KY1-9006, Cayman Islands
#### D.6 Utility token classification
false
#### D.7 Key Features of Goods/Services for Utility Token Projects
Not applicable
#### D.8 Plans for the token
The SPK token is designed to function as a cornerstone of the Spark ecosystem, enabling long-term value creation through decentralised incentives, participation, and infrastructure support. SPK is distributed without monetary consideration and built with clear alignment between user effort and ecosystem growth.
##### **Community-Driven Distribution**
SPK token’s distribution model prioritises organic community involvement. Tokens are allocated via airdrops, on-chain activity, and reward mechanisms tied to meaningful user engagement.
These distribution channels are permissionless, performance-based and structured to encourage use among committed participants.
##### **Protocol Utility and Staking**
SPK tokens are expected to play a role in supporting the reliability and functionality of the Spark protocol over time. SPK token holders may be given the option to stake their SPK to contribute to the network's resilience or participate in reward systems. Staking mechanisms could be linked to protocol components such as cross-chain infrastructure or security features, although specifics may evolve based on governance decisions and technical development. Staking may involve time-bound commitments, and rewards, if any, will reflect the level of engagement and the function being supported.
##### **Incentive structures**
The token design incorporates the possibility of allocating SPK tokens to participants who contribute to the ecosystem’s growth and operational soundness. This may include users who interact with infrastructure components, provide liquidity, or contribute to early adoption efforts. These measures aim to foster long-term engagement.
##### **Governance Engagement**
SPK tokens may also function as a governance tool, enabling holders to take part in decentralised decision-making processes. These could include discussions and votes on treasury use, protocol evolution, or other strategic priorities. The governance model is intended to be adaptable, subject to community feedback and emerging needs.
##### **Future Outlook**
As the Spark project grows, SPK tokens may become relevant in additional modules or integrations, including those related to cross-chain operations, coordination layers, or service modules. These developments will be introduced incrementally and in alignment with broader ecosystem goals.
The vision for SPK tokens is to support a sustainable, community-driven network. Its role is not fixed but is intended to reflect the evolving needs of a decentralised ecosystem prioritising fairness, resilience, and meaningful engagement.
#### D.9 Resource Allocation
The Spark ecosystem incorporates a structured approach to resource allocation, aimed at ensuring long-term operational sustainability and adaptability. SPK tokens are reserved across specific categories to support development, governance, and ecosystem initiatives.
A dedicated share of the SPK token supply is earmarked for operational costs, reflecting the ongoing need to maintain infrastructure, support contributors, and cover administrative requirements. Additionally, Spark will receive initial grant funding from Sky to help bootstrap Spark’s growth. These resources enable the protocol to remain functional and responsive without immediate reliance on external funding.
In parallel, a treasury allocation is established to provide flexibility over time. This reserve is governed by community processes and may be used to support future proposals, ecosystem incentives, or strategic partnerships.
The resource model aligns token distribution with the needs of a dynamic and participatory ecosystem, allowing SPK tokens to function as a mechanism for funding public goods and sustaining the protocol over time.
#### D.10 Planned Use of Collected Funds or Crypto-Assets
The offer to the public will take place without raising funds or accepting any crypto-assets, as outlined in Section E.
### PART E – INFORMATION ABOUT THE OFFER TO THE PUBLIC
#### E.1 Public Offering
OTPC
#### E.2 Reasons for Public Offer
The public offer of SPK tokens is intended to initiate the launch of the Spark project and to incentivise early engagement with the Spark protocol. The offer is designed to encourage the use of its services and to establish a decentralised and active user base from the outset. The tokens will be distributed without collecting any funds or crypto-assets from participants. Instead, the offer is structured around non-monetary contribution mechanisms such as protocol usage, on-chain activity, staking engagement, and other qualifying actions.
Tokens are provided free of charge or in exchange for specific actions that demonstrate interest or involvement in the ecosystem. These distribution mechanisms include airdrops based on past engagement, performance-based eligibility, and participation in pre-defined incentive programs as specified in more detail in section E.18.
The public offer is not intended as a capital-raising measure and does not involve the collection of funds or crypto-assets. Accordingly, no proceeds will be received by the Offeror or any affiliated entity in connection with the distribution of SPK tokens. The offer is exclusively designed to support the initial development of a decentralised user base by allocating tokens to participants on the basis of non-financial contributions. The Offeror does not intend to derive any financial gain from the offer, and the distribution is structured to ensure compliance with applicable regulatory exemptions concerning public offerings without consideration.
#### E.3 Fundraising target
Not applicable
#### E.4 Minimum Subscription Goal
Not applicable
#### E.5 Maximum Subscription Goal
Not applicable
#### E.6 Oversubscription Acceptance
false
#### E.7 Oversubscription Allocation
Not applicable
#### E.8 Issue Price
€0
#### E.9 Official currency or any other crypto-assets determining the issue price
Not applicable
#### E.10 Subscription fee
€0
#### E.11 Offer Price Determination Method
The SPK tokens will be allocated without consideration and exclusively based on demonstrable user actions or prior holdings. No monetary payment or transfer of crypto-assets is required or accepted in exchange for the receipt of SPK tokens.
#### E.12 Total Number of Offered Crypto-Assets
910,000,000 SPK tokens
#### E.13 Targeted Holders
ALL
#### E.14 Holder restrictions
The offer of SPK tokens is not subject to any general restriction with respect to the type of recipient. However, the distribution is limited to individuals and entities that are not subject to applicable sanctions or other regulatory prohibitions. The Offeror reserves the right to exclude from eligibility any user or wallet address that is reasonably believed to be associated with a jurisdiction, entity, or individual subject to relevant restrictions under applicable law. Further, any user or wallet address reasonably suspected of being a Sybil wallet or involved in fraudulent, manipulative, or malicious activity may be excluded from participation in the offer. Users are responsible for ensuring that their receipt and holding of SPK tokens are lawful in their respective jurisdictions.
Participants must self-certify that they are not residents of, or otherwise located in, any jurisdiction where the receipt or holding of crypto-assets is restricted or prohibited.
#### E.15
Purchasers participating in the offer to the public of crypto-asset will be able to be reimbursed if the minimum target subscription goal is not reached at the end of the offer to the public, if they exercise the right to withdrawal foreseen in Article 13 of Regulation (EU) 2023/1114 or if the offer is cancelled.
#### E.16 Refund Mechanism
Pursuant to Article 13 of MiCA, retail holders who have agreed to receive SPK tokens from the Offeror shall have a right to withdraw from such agreement within a period of 14 calendar days from the date of such agreement, without giving any reason and without incurring any costs.
Retail holders may exercise their right of withdrawal by following the process available at [www.spark.fi/mica](http://www.spark.fi/mica). The notice must be submitted no later than 14 calendar days after the date on which the agreement to acquire SPK tokens was concluded.
Upon receiving the withdrawal notice, the Offeror will provide the retail holder with a blockchain address to which the tokens must be returned.
##### **Return of Tokens and Reimbursement**
The retail holder shall return the acquired SPK tokens to the Offeror without undue delay and no later than 14 calendar days after submitting the withdrawal notice. As no monetary payment was made by the holder, no reimbursement shall be due. Due to this, the tokens shall be returned and the agreement voided without further obligation from either party.
The Offeror will not impose any fee or penalty in connection with the exercise of the right of withdrawal. Gas fees incurred on-chain in connection with the return of tokens shall be borne by the retail holder unless otherwise agreed.
#### E.17 Refund Timeline
The designated refund wallet address shall be made available to the holder upon receipt of the withdrawal notice and shall remain available for the return of tokens for a minimum period of 14 calendar days thereafter.
#### E.18 Offer Phases
The public offering of SPK tokens will occur in separate phases, each designed to distribute tokens to distinct participant groups based on eligibility criteria and pre-defined allocation methodologies. Claims will be made available via on-chain claiming interfaces following the Token Generation Event (TGE), with each phase subject to its own claiming window.
##### **Phase 1**:
This phase includes distributions to early participants who interacted with designated DeFi protocols prior to the TGE. Allocation is based on historic on-chain activity, with protocol-specific criteria and anti-sybil measures applied. Eligible users may claim their tokens starting at TGE for a limited duration.
##### **Phase 2**:
This phase encompasses broader ecosystem distribution based on historical activity across multiple chains, platforms and applications. Allocations are determined using a point-based system reflecting user exposure to selected assets and protocols. Eligibility is non-transferable and fixed prior to the TGE. The claiming period for this phase begins at TGE and concludes following a pre-defined window.
##### **Phase 3**:
This phase involves distribution to participants in Spark’s post-TGE ecosystem campaigns, including social and engagement-based reward initiatives. Participants may earn eligibility by completing campaign tasks or interacting with designated applications. Each campaign includes an earning period and a subsequent claim window. Unclaimed tokens after the claim period expires will revert to the treasury.
All phases are subject to eligibility verification, including sanctions screening and wallet verification. Tokens may only be claimed via the official interface during the applicable claiming window.
Eligibility criteria and claiming instructions for each phase will be published on the official claiming interface on Spark’s website, [spark.fi](http://spark.fi/), prior to the commencement of the relevant claiming window.
This white paper covers a continuous offering of SPK tokens through multiple time-limited phases. Each phase has a defined claim period, but the Offeror may initiate additional distribution phases in the future under the same framework. The offer shall remain open for purposes of MiCA Article 10(2) until otherwise stated, and the number of tokens in circulation will be published at least monthly on the Offeror’s website.
In the event that future phases are materially different from those described herein, whether in terms of structure or claiming mechanisms, the Offeror will update and notify the white paper in accordance with MiCA Article 12 prior to the commencement of such phases.
#### E.19 Early Purchase Discount
Not applicable.
#### E.20 Time-limited offer
false
#### E.21 Subscription period beginning
Not applicable
#### E.22 Subscription period end
Not applicable
#### E.23 Safeguarding Arrangements for Offered Funds/Crypto-Assets
Not applicable
#### E.24 Payment Methods for Crypto-Asset Purchase
The SPK tokens are offered without payment of any monetary benefit, but based on pre-defined actions and on-chain activity.
#### E.25 Value Transfer Methods for Reimbursement
No reimbursement shall be due.
#### E.26 Right of Withdrawal
In accordance with Article 13 of MiCA, any retail holder who enters into an agreement to acquire SPK tokens as part of this public offering shall have the right to withdraw from the agreement within a period of 14 calendar days from the date of such agreement, without giving any reason and without incurring any cost.
Retail holders may exercise it by following the process outlined under Refund Mechanism.
#### E.27 Transfer of Purchased Crypto-Assets
Upon satisfying the eligibility criteria for a given phase of the offer, SPK tokens will become claimable by the eligible holder at or after the TGE. Tokens will be made available via an on-chain claiming mechanism, and holders must actively claim their allocation through the designated interface.
Upon successful claiming, the SPK tokens will be transferred to the holder’s self-custodied wallet address, at which point the holder obtains full control and ability to transfer, subject to applicable legal or contractual restrictions with wallet provider. There are no transfer restrictions imposed by the Offeror following delivery, unless otherwise stated in this White Paper.
#### E.28 Transfer Time Schedule
SPK tokens will become claimable by eligible holders in accordance with any claiming schedules announced on Spark's official website. Upon claiming, tokens will be transferred in full to the holder’s wallet with no further vesting, lock-up, or time-based release restrictions imposed by the Offeror.
#### E.29 Purchaser’s Technical Requirement
To receive and hold SPK tokens, eligible holders must have access to a compatible, self-custodied wallet capable of interacting with the Ethereum blockchain, where SPK is deployed as an ERC-20 standard token.
The wallet must support:
* Secure storage of private keys and recovery phrases;
* On-chain interaction with smart contracts
(e.g., for claiming SPK tokens)
* The ability to pay applicable network transaction fees (gas) in the native blockchain token, ETH.
The Offeror does not provide wallet infrastructure or custody services. It is the sole responsibility of the eligible holder to:
* Secure their private keys;
* Ensure uninterrupted access to their wallet;
* Ensure the wallet address used for claiming is correct and under their exclusive control.
Failure to meet the above requirements may result in the holder’s inability to claim or access the SPK tokens, for which the Offeror assumes no responsibility.
#### E.30 Crypto-asset service provider (CASP) name
Not applicable
#### E.31 CASP identifier
Not applicable
#### E.32 Placement form
NTAV
#### E.33 Trading Platforms name
Not applicable
#### E.34 Trading Platforms Market Identifier Code (MIC)
Not applicable
#### E.35 Trading Platforms Access
Not applicable
#### E.36 Involved costs
Not applicable
#### E.37 Offer Expenses
No placement fees, subscription fees, or transaction fees are charged to the eligible holder by the Offeror in connection with the receipt or claiming of SPK tokens.
Eligible holders may be required to pay standard network transaction fees (gas fees) to claim their tokens via the designated on-chain interface. These fees are paid directly to the blockchain network and not retained by the Offeror.
All costs associated with the development, structuring, and execution of the offering, including legal, technical, and marketing expenses, are borne by the Offeror.
#### E.38 Conflicts of Interest
Spark Foundation is expected to receive an allocation of approximately 1 billion SPK tokens following the TGE. These SPK tokens will be used by the Spark Foundation to support protocol development, governance, ecosystem incentives, and other community-aligned initiatives. It is the assessment of the Offeror that this allocation does not give rise to a conflict of interest within the meaning of Article 14(1)(c) of MiCA, as Spark Foundation operates with a mandate to promote the long-term success of the ecosystem and not for private gain. The Offeror will continue to monitor for potential conflicts of interest on an ongoing basis and will take appropriate steps to disclose and mitigate any such conflicts should they arise.
#### E.39 Applicable law
This offering and the contractual rights and obligations arising between the Offeror and eligible holders in connection with SPK tokens shall be governed by and construed in accordance with the laws of the British Virgin Islands. Notwithstanding the above, this White Paper and the offer of SPK tokens to the public within the European Union are made in accordance with MiCA.
#### E.40 Competent court
Any dispute arising out of or in connection with this offering or the SPK tokens shall be subject to the exclusive jurisdiction of the courts of the British Virgin Islands. This is without prejudice to the rights of retail holders residing in the European Union to bring claims before the courts of their place of residence, in accordance with applicable consumer protection and private international law rules.
### PART F – INFORMATION ABOUT THE CRYPTO-ASSETS
#### F.1 Crypto-Asset Type
Crypto-asset other than an asset-referenced token or e-money token.
#### F.2 Crypto-Asset Functionality
SPK token is a fungible crypto-asset within the meaning of Article 3(1)(5) of MiCA. It does not qualify as an asset-referenced token (ART) or e-money token (EMT) under MiCA and is offered to the public under the Title II framework.
SPK token is implemented as a standard ERC-20 token on the Ethereum blockchain and is freely transferable following its delivery to the holder, subject to any applicable legal or contractual restrictions described in this White Paper.
SPK token is designed primarily for the use within Spark ecosystem, including participation in governance, reward programs, and future protocol-based activities. It does not represent a financial claim or entitlement to any underlying asset, nor does it confer ownership or profit rights in the Offeror or any affiliated entity.
#### F.3 Planned Application of Functionalities
At the time of publishing this White Paper, the SPK token’s core functionalities are described below and will be made available progressively after Offering:
* **Governance**: SPK token holders will be able to participate in the governance of the Spark protocol. This may include the right to vote on proposals concerning matters like protocol parameters, treasury allocation, grant distributions, and technical upgrades. Governance mechanisms will evolve under a decentralised governance model managed via the SparkDAO.
* **Staking**: SPK tokens may be staked by holders. In return for staking, participants may earn rewards. The staking mechanism is governed by smart contracts and requires the transfer of SPK tokens to a dedicated staking contract.
* **Rewards and Incentives**: SPK tokens will be distributed as part of airdrop campaigns and incentive programmes as described in this White Paper. These may include rewards for early use of DeFi products within the Spark application. In addition, SPK tokens may be used in future farming mechanisms or liquidity incentives across various Spark-related services.
All functionalities are accessible through the Spark application or approved interfaces. Certain features, such as staking and voting, may be made available in phases, with implementation timelines subject to further governance decisions. Any material updates to the functionalities or use of SPK tokens will be reflected through updates to this white paper in accordance with MiCA Article 12.
**A description of the characteristics of the crypto-asset, including the data necessary for classification of the crypto-asset white paper in the register referred to in Article 109 of Regulation (EU) 2023/1114, as specified in accordance with paragraph 8 of that Article**
#### F.4 Type of white paper
OTHR
#### F.5 The type of submission
MODI
#### F.6 Crypto-asset Characteristics
See Part D and Section F.2.
#### F.7 Commercial name or trading
Spark / SPK token name
#### F.8 Website of the issuer
The Issuer does not have a website.
The website of the project is [https://spark.fi/](https://spark.fi/).
#### F.9 Starting date of offer to the public or admission to trading
2025-06-17
#### F.10 Publication date
2025-06-20
#### F.11 Any other services provided by the issuer
The Offeror does not offer any other services covered by MiCA
#### F.12 Identifier of operator of the trading platform
Not applicable
#### F.13 Language or languages of the white paper
English
#### F.14 Digital Token Identifier Code used to uniquely identify the crypto-asset or each of the several crypto-assets to which the white paper relates, where available
SPK
#### F.15 Functionally Fungible Group Digital Token Identifier, where available
Not applicable
#### F.16 Voluntary data flag
false
#### F.17 Personal data flag
true
#### F.18 LEI eligibility
false
#### F.19 Home Member State
Denmark
#### F.20 Host Member States
The offer to the public of SPK tokens is passported to the following countries:
* Austria
* Belgium
* Bulgaria
* Croatia
* Cyprus
* Czech Republic
* Estonia
* Finland
* France
* Germany
* Greece
* Hungary
* Iceland
* Ireland
* Italy
* Latvia
* Liechtenstein
* Lithuania
* Luxembourg
* Malta
* Netherlands
* Norway
* Poland
* Portugal
* Romania
* Slovakia
* Slovenia
* Spain
* Sweden
### PART G – INFORMATION ON THE RIGHTS AND OBLIGATIONS ATTACHED TO THE CRYPTO-ASSETS
#### G.1 Purchaser Rights and Obligations
Upon receipt of SPK tokens, holders are granted the right to hold, transfer, and utilise the tokens in accordance with the functionalities set out in this White Paper. Where implemented, such functionalities may include the ability to participate in governance processes and protocol-level decision-making, as well as to access certain staking or reward mechanisms as described herein.
SPK tokens do not confer on holders any ownership interest, profit-sharing rights, equity claims, or creditor rights against the Offeror. The tokens do not represent financial instruments, electronic money, or asset-referenced tokens within the meaning of MiCA.
SPK token holders shall be solely responsible for maintaining secure custody of their private keys, ensuring accurate and timely use of the designated claiming interface, and bearing any applicable network transaction fees incurred during claiming, transferring, or using SPK tokens. Token holders must also ensure compliance with any applicable legal, regulatory, or tax obligations in their jurisdiction of residence. No additional rights or obligations are imposed on holders beyond those expressly described in this White Paper.
#### G.2 Exercise of Rights and obligations
The rights associated with SPK tokens may be exercised exclusively through the designated blockchain interfaces, smart contracts, or governance mechanisms made available. Access to these rights requires that the SPK token holder maintains control over a compatible self-custodied wallet and engages directly with the supported interfaces.
Participation in governance, staking, or any reward-based functionality shall be subject to the technical implementation of such features and any applicable eligibility conditions, timelines, or procedural requirements as further communicated via official channels of the Spark ecosystem.
The obligations of SPK token holders, including the payment of any network fees and compliance with applicable legal requirements, are to be fulfilled independently and at the sole responsibility of the holder.
#### G.3 Conditions for modifications of rights and obligations
The rights and obligations associated with SPK tokens may be modified in the future as a result of governance decisions adopted in accordance with the decentralised governance framework of the Spark protocol. Such modifications may include changes to token functionalities, staking parameters, voting mechanisms, or eligibility criteria for participation in network incentives.
The Offeror does not retain unilateral discretion to amend the rights or obligations of retail holders after the issuance of SPK tokens. Any material change to the governance structure or token utility will be subject to the governance procedures established within the Spark ecosystem, including proposal submission, voting thresholds, and quorum requirements, as applicable.
#### G.4 Future Public Offers
At the time of publication of this white paper, the Offeror does not have any confirmed plans for future public offers of SPK tokens. Should the Offeror initiate any such offering in the future, a separate or updated white paper will be prepared, notified to the competent authority, and published in accordance with Article 12 of MiCA.
#### G.5 Issuer Retained Crypto-Assets
0
#### G.6 Utility Token Classification
false
#### G.7 Key Features of Goods/Services of Utility Tokens
Not applicable
#### G.8 Utility Token Redemption
Not Applicable
#### G.9 Non-Trading request
true
#### G.10 Crypto-Assets purchase or sale modalities
Not applicable
#### G.11 Crypto-Assets Transfer Restrictions
The Offeror does not impose any transfer restrictions.
#### G.12 Supply Adjustment Protocols
false
#### G.13 Supply Adjustment Mechanisms
SPK does not currently have any automatic or algorithmic supply adjustment mechanisms linked to market demand. There is no pre-programmed rebasing, burning, or minting functionality designed to increase or decrease the token supply based on price or demand fluctuations.
However, the total supply of SPK may be increased in the future through governance proposals adopted by the SkyDAO, the decentralised governance structure associated with the Spark protocol. Any such supply adjustment would be subject to the applicable governance rules and would require approval through the established voting procedures.
#### G.14 Token Value Protection Scheme
false
#### G.15 Token Value Protection Schemes Description
Not applicable
#### G.16 Compensation Schemes
false
#### G.17 Compensation Schemes Description
Not applicable
#### G.18 Applicable law
This white paper, and any contractual rights and obligations arising in connection with the receipt and use of SPK tokens, shall be governed by and construed in accordance with the laws of the British Virgin Islands.
#### G.19 Competent court
Any dispute arising out of or in connection with this offering shall be subject to the exclusive jurisdiction of the courts of the British Virgin Islands.
This is without prejudice to the rights of retail holders who are natural persons and habitually resident in a Member State of the European Union to bring proceedings before the courts of their place of residence, in accordance with applicable EU consumer protection and private international law rules.
### Part H – INFORMATION ON THE UNDERLYING TECHNOLOGY
#### H.1 Distributed ledger technology
SPK token is deployed on the Ethereum mainnet, a public and permissionless distributed ledger based on blockchain technology. The token is implemented via a set of smart contracts deployed to Ethereum and is accessible to any compatible wallet.
#### H.2 Protocols and technical
SPK tokens conform to the ERC-20 token standard standards and interacts with Ethereum-compatible smart contracts to facilitate distribution, claiming, staking, and governance. Token transfers, approvals, and other on-chain operations follow the established ERC-20 interface.
#### H.3 Technology Used
As an ERC-20 token, the SPK token will be deployed as a smart contract on the Ethereum blockchain. Users can manage the SPK tokens through their own non-custodial wallet software provided by third parties or by interacting directly with the SPK token’s smart contract through a third-party API.
#### H.4 Consensus Mechanism
The SPK token is deployed on the Ethereum blockchain. Ethereum operates using a Proof of Stake (PoS) consensus mechanism, wherein network validators are selected based on staked ETH to confirm transactions and propose new blocks.
#### H.5 Incentive Mechanisms and Applicable Fees
SPK token holders may earn SPK tokens as rewards through staking or participation in Spark ecosystem activities, as described in this White Paper.
The Offeror does not charge any placement or transaction fees in connection with the receipt or use of SPK tokens. However, all on-chain transactions on Ethereum, including claiming and transferring SPK tokens, require the payment of network gas fees.
Gas fees are denominated in ETH and paid directly to the Ethereum network. Following the implementation of Ethereum Improvement Proposal 1559 (EIP-1559), gas fees consist of two components:
* **Base fee**:\
This is automatically calculated based on current network demand and is burned, meaning it is removed from circulation.
* **Priority fee (tip)**:\
This is paid to the validator that successfully proposes the block in which the transaction is included.
Ethereum validators are incentivised through a combination of block rewards and priority fees paid in ETH. Validators who misbehave or act maliciously are subject to slashing penalties, resulting in the loss of a portion of their staked ETH.
The Offeror has no control over Ethereum blockchain fees, validator behaviour, or the consensus process.
#### H.6 Use of Distributed Ledger Technology
false
#### H.7 DLT Functionality Description
Not applicable
#### H.8 Audit
false
#### H.9 Audit outcome
Not applicable
#### PART J – INFORMATION ON THE SUSTAINABILITY INDICATORS IN RELATION TO ADVERSE IMPACT ON THE CLIMATE AND OTHER ENVIRONMENT-RELATED ADVERSE IMPACTS
#### General information
#### S.1 Name
SPK Company Ltd
#### S.2 Relevant legal entity identifier
*Identifier stated to in section A*
Not available
#### S.3 Name of the crypto-asset
*Name of the crypto-asset as stated to in section A*
Spark / SPK
#### S.4 Consensus Mechanism
The SPK token is deployed on the Ethereum blockchain. *The consensus mechanism,* Ethereum operates using a Proof of Stake (PoS) *as stated in Section H* consensus mechanism, wherein network validators are selected based on staked ETH to confirm transactions and propose new blocks.
#### S.5 Incentive Mechanisms and Applicable Fees
*Incentive mechanisms to secure transactions and any fees applicable as stated in section H.*
SPK token holders may earn SPK tokens as rewards through staking or participation in Spark ecosystem activities, as described in this White Paper.
The Offeror does not charge any placement or transaction fees in connection with the receipt or use of SPK tokens. However, all on-chain transactions on Ethereum, including claiming and transferring SPK tokens, require the payment of network gas fees.
Gas fees are denominated in ETH and paid directly to the Ethereum network. Following the implementation of Ethereum Improvement Proposal 1559 (EIP-1559), gas fees consist of two components:
* **Base fee**:
This is automatically calculated based on current network demand and is burned, meaning it is removed from circulation.
* **Priority fee (tip)**:\
This is paid to the validator that successfully proposes the block in which the transaction is included.
Ethereum validators are incentivised through a combination of block rewards and priority fees paid in ETH. Validators who misbehave or act maliciously are subject to slashing penalties, resulting in the loss of a portion of their staked ETH.
The Offeror has no control over Ethereum blockchain fees, validator behaviour, or the consensus process.
#### S.6 Beginning of the period to which the disclosed information relates
2024-05-08
#### S.7 End of the period to which the disclosure relates
2025-05-08
#### **Mandatory key indicator on energy consumption**
#### S.8 Energy consumption
*Total amount of energy used for the validation of transactions and the maintenance of the integrity of the distributed ledger, expressed in kilowatt-hours per calendar year*
6,490,000 kWh
#### **Sources and methodologies**
#### S.9 Energy Consumption Sources and Methodologies
*Sources and methodologies used in relation to the information reported above*
For the calculation of energy consumption, a bottom-up approach, as described in the CBNSI methodology, is used. In this approach, Ethereum network nodes are considered the central factor determining total energy demand. Hardware assumptions are based on empirical findings from public information sources, open-source network crawlers, and analytical tools developed by CCAF. The main determinants for estimating the hardware used within the network are the operational requirements of the Ethereum client software. The electricity consumption of the relevant hardware configurations has been measured in certified test laboratories, as set out in the referenced methodology.
CBNSI's model estimates the average power demand of the Ethereum consensus layer on a daily basis, using observed Beacon node counts, client software distribution, and typical hardware profiles. The model then annualises these daily figures to produce an annual electricity consumption estimate.
Secondary cross-check: The CBNSI figures are consistent in order of magnitude with the Digiconomist – Ethereum Energy Consumption Index, which applies a separate estimation methodology.
Reference period: Please refer to S.6 and S.7.
Calculation for SPK token: As SPK is an ERC-20 token on the Ethereum network, the token's share of total network electricity consumption may be approximated by the proportion of total Ethereum gas usage attributable to SPK-related transactions in the reference period. This pro-rata value is calculated as:
`Espk = Ethereum x SPK_gas_used / Total_Ethereum_gas_used`
Since the SPK token has only recently been created, the energy consumption figure relates to the previous calendar year and serves as an estimate of what may be consumed during the SPK token's first year of operation on the Ethereum blockchain.
#### S.10 Renewable energy consumption (%)
Based on the CBNSI methodology and the geographical distribution of Ethereum validator nodes, approximately 40.0 % (0.400) of the electricity used for the validation of transactions and the maintenance of the integrity of the Ethereum distributed ledger originates from renewable energy sources.
This percentage is calculated by weighting the renewable share of the electricity grid in each country/region hosting validator nodes according to the proportion of validators located there. Regional renewable share data is sourced from official statistics (e.g., Eurostat for the EU, U.S. Energy Information Administration for the United States, and equivalent agencies for other regions).
#### S.11 Energy consumption per transaction (kWh/transaction)
Based on the total annual energy consumption disclosed in S.8 (4,871,148.30 kWh) and the total number of Ethereum transactions in the reference period (468,000,000, source: Etherscan), the average energy consumption per transaction is:
`kWh/tx = 4,871,148.30 / 468,000,000 = 0.0104 kWh/tx`
This represents the average network-wide figure and is not limited to the SPK-related transactions.
#### S.12 Scope 1 greenhouse gas emissions (tCO₂e/year)
For the Ethereum proof-of-stake network, scope 1 greenhouse gas emissions – defined as direct emissions from owned or controlled sources – are negligible, as validators do not burn fossil fuels on-site for consensus operations.
Accordingly, the annualised scope 1 greenhouse gas emissions for the reference period are reported as 0tCO₂e/year.
#### S.13 Scope 2 greenhouse gas emissions (tCO₂e/year)
Based on the total annual energy consumption disclosed in S.8 (4,871,148.30 kWh) and an average grid emission factor of 0.35 kg CO₂e/kWh (source: European Environment Agency – EU residual mix 2023), the estimated annualised scope 2 greenhouse gas emissions are:
`4,871,148.30 x 0.35kgCO2e ≈ 1,704,902kgCO2e/year`
`(≈ 1,705 tCO2e/year)`
Scope 2 emissions represent indirect emissions from the generation of purchased electricity consumed by Ethereum validators.
Scope 1 emissions for the Ethereum proof-of-stake network are negligible and reported as zero in S.12.
#### S.14 Total greenhouse gas emissions per transaction (kgCO₂e/transaction)
Total annual GHG emissions (scope 1 + scope 2) are 1,705 tCO₂e/year (see S.12–S.13). Based on 468,000,000 Ethereum transactions in the reference period, the average emissions per transaction are:
`kgCO2e/tx = 1,705,000 kgCO2e / 468,000,000 tx`
`kgCO2e/tx ≈ 0.00364 kgCO2e/tx`
#### S.15 Sources of data
Primary source: Cambridge Centre for Alternative Finance (CCAF) – Cambridge Blockchain Network Sustainability Index (CBNSI) – Ethereum.
Secondary source: Digiconomist – Ethereum Energy Consumption Index (cross-check).
Emissions factor source: European Environment Agency – EU residual mix 2023.
#### S.16 Methodologies applied
The energy consumption figures are calculated using CBNSI's "bottom-up" methodology: network node counts, client software distribution, and typical hardware configurations are combined to estimate total network electricity demand. Hardware power draw values are obtained from certified laboratory tests. Daily estimates are annualised using a 7-day moving average. Emissions are calculated by multiplying total electricity consumption by the average grid emission factor for the geographical distribution of nodes. Renewable share is derived from the renewable percentage of the relevant grid mixes. Transaction counts are obtained from on-chain data (Etherscan API).
For SPK, as an ERC-20 token on Ethereum, energy consumption and emissions are expressed at the network level; a pro-rata allocation based on SPK's share of total Ethereum gas usage can also be provided for illustrative purposes.
## **Markets in Crypto-Assets (MiCA) Information**
### **White Papers for SPK Token**
| | Version | Notified To | Published On | Download | Machine- Readable Version |
| :---------------------------------------------------------------------------------------------- | :------ | :--------------------- | :----------- | :-------------------------------------------------------------------------------------------- | :------------------------ |
| Spark Foundation’s white paper seeking admission to trade | 1.0 | Malta, on 2025-04-16 | N/A | [Link](https://drive.google.com/file/d/1-w3NyktWcfsID-E6EeWY_78XIC-B1OHg/view?usp=drive_link) | [Link](/mica/1) |
| Spark Foundation’s white paper seeking admission to trade, as amended on May 22, 2025\* | 2.0 | Malta, on 2025-05-22 | 2025-06-12 | [Link](https://drive.google.com/file/d/1fwESrD0BMvATXyohfHxfq1agHccHTQSc/view?usp=drive_link) | [Link](/mica/2) |
| Spark Foundation’s white paper seeking admission to trade, as amended on August 20, 2025\* | 3.0 | Malta, on 2025-08-20 | 2025-08-30 | [Link](https://drive.google.com/file/d/1dDOLPJE33FR7akOiaP9FBFRRhhvx4FTu/view) | [Link](/mica/6) |
| SPK Company Ltd.’s white paper for an offer of crypto-assets | 1.0 | Denmark, on 2025-05-09 | 2025-06-12 | [Link](https://drive.google.com/file/d/16YVjMmJI73_PSIUt0_JP0crmDqP3ZBJT/view?usp=sharing) | [Link](/mica/3) |
| SPK Company Ltd.’s white paper for an offer of crypto-assets, as amended on June 11, 2025\*\* | 2.0 | Denmark, on 2025-06-11 | 2025-06-21 | [Link](https://drive.google.com/file/d/1m81OUa2vDchqAAteA9-jl7scToXkZsQr/view) | [Link](/mica/4) |
| SPK Company Ltd.’s white paper for an offer of crypto-assets, as amended on July 25, 2025\*\*\* | 3.0 | Denmark, on 2025-07-25 | 2025-08-11 | [Link](https://drive.google.com/file/d/18mFAtaPNKSCuBsq-MH56ebkJC6AN2JPM/view) | [Link](/mica/5) |
| SPK Company Ltd.’s white paper for an offer of crypto-assets, as amended on August 20, 2025 | 4.0 | Denmark, on 2025-08-20 | 2025-08-30 | [Link](https://drive.google.com/file/d/1mKp0dh-QicU1RQhIr8r3nHlAq89zbO6e/view?usp=drive_link) | [Link](/mica/7) |
This crypto-asset white paper has not been approved by any competent authority in any Member State of the European Union.
\*Key material updates include a revised disclaimer and warning notice specifically addressing admission to trading, clarification of staking provisions to accurately reflect their conditional nature dependent on governance and technical developments, updated corporate address details, inclusion of clear references to the separate Offer White Paper, and corrections to token classification and technical requirements. Additionally, statements regarding public token offerings and supply adjustment protocols have been corrected for regulatory accuracy.
\*\*The key material update is increasing the total number of offered tokens from 680,000,000 SPK to 710,000,000 SPK.
\*\*\*The key material update is increasing the total number of offered tokens from 710,000,000 SPK to 910,000,000 SPK.
### **Contact Information**
#### Regarding admission to trading of the SPK token:
* **Name:** Spark Foundation
* **Registered Address:** Leeward Management Limited, Suite 3119, 9 Forum Lane, Camana Bay, PO Box 144, George Town, Grand Cayman KY1-9006, Cayman Islands
* **Phone:** +1 345-749-9601
* **Email:** [mica@sparkfoundation.io](mailto\:mica@sparkfoundation.io)
#### Regarding the offer of the SPK token:
* **Name:** SPK Company Ltd.
* **Registered Address:** SHRM Trustees (BVI) Limited of Trinity Chambers, PO Box 4301, Road Town, Tortola, British Virgin Islands
* **Phone:** +1 345-749-9601
* **Email:** [mica@sparkfoundation.io](mailto\:mica@sparkfoundation.io)
Right of Withdrawal
Retail Holders’ Right of Withdrawal
Retail purchasers are entitled to a **14-day cooling-off period** during which they may withdraw from the purchase without fee or penalty. The procedural details are set out in **Part E (items E.16 & E.17)** of the White Paper.
### **Circulating Supply**
To see SPK’s current circulating supply, visit [https://data.spark.fi/spk](https://data.spark.fi/spk).
## Referral Codes
Spark assigns integrator partners a unique 3-digit **referral code** (a `uint16` in the range 100–999) that you embed in your integration so deposits coming from your product are attributed back to you.
### How it works
The Spark Vault `deposit` function has an overload that accepts a referral code:
```text
deposit(uint256 assets, address receiver, uint16 referral) returns (uint256 shares)
```
Pass your assigned code as the third argument when calling `deposit`. Deposits made with a code emit a `Referral(uint16 indexed referral, address indexed owner, uint256 assets, uint256 shares)` event — a reliable, tamper-proof on-chain signal of the TVL originating from your integration. Everything else about the integration stays the same — see the [Spark Vaults Smart Contracts integration guide](/integrators/spark-vaults-v2#deposit) and the [deposit examples](/integrators/spark-vaults-v2-examples#deposit) for the standard flow in viem, ethers, and Solidity.
If you do not have a referral code, use the two-argument `deposit(assets, receiver)` overload.
### What a referral code unlocks
* **Attribution & reporting.** Every referral code gets a dedicated [reporting dashboard](/integrators/reporting-dashboard) that maps deposits and TVL back to your code, so you can track the performance of your integration over time.
* **Partnerships & campaigns.** Some integrator partnerships unlock additional benefits on top of the standard vault rate, plus co-marketing and incentive campaigns tied to your integration's performance. These are activated through the same referral code, so the integration work is one-and-done.
### Getting a code
Referral codes are issued by the Spark team.
:::tip[Contact us]
If you are building an integration and want to request a referral code or discuss a partnership, fill out the [partner form](https://docs.google.com/forms/d/e/1FAIpQLSezdKGi98dUIBn-1jLbyJIqVB_S5XDs2esoK0IdAwWHc95pfA/viewform) or reach out on the [Spark Discord](https://discord.com/invite/sparkdotfi).
:::
## Reporting Dashboard
Every [referral code](/integrators/referral-codes) gets a dedicated reporting dashboard so you can track the performance of your integration over time.
### What it covers
* **Time-weighted TVL (TW-TVL)** — the core metric for campaign performance and incentive eligibility.
* **Total active users** — unique depositors attributed to your referral code.
* **Average deposit size** — distribution across your user base.
* **Daily inflows / outflows** — net flow trends over time.
* **User-level data** — per-wallet balances, entry dates, and activity.
### Getting set up
Dashboards are provisioned by Spark upon request.
:::tip[Request a dashboard]
Reach out via the [partner form](https://docs.google.com/forms/d/e/1FAIpQLSezdKGi98dUIBn-1jLbyJIqVB_S5XDs2esoK0IdAwWHc95pfA/viewform) to get your dashboard set up.
:::
## Spark Savings for Integrators
**Spark Savings Vaults** are ERC-4626 yield-bearing vaults that let anyone deposit a
stablecoin and earn a continuously compounding savings rate, backed by the Sky
ecosystem and the Spark Liquidity Layer. Deposits mint a savings token (e.g.
`spUSDC`, `spUSDT`) whose value grows every second at the vault savings rate — no
staking, no lockups, withdraw any time.
This section is for teams who want to bring that yield into their own product:
a wallet, an exchange, a treasury tool, or any app where users hold stablecoins.
A full integration combines both of the pieces below.
### The two building blocks
:::tip[On-chain contracts — move funds]
Spark Vaults are standard [ERC-4626](https://eips.ethereum.org/EIPS/eip-4626)
vaults. Call `deposit` / `mint` to enter a position and `withdraw` / `redeem` to
exit — the same interface across every supported vault. The
**[Spark Vaults Smart Contracts integration guide](/integrators/spark-vaults-v2)** walks through
each flow, with copy-paste **[examples](/integrators/spark-vaults-v2-examples)** in
viem, ethers, and Solidity. For large redemptions that exceed idle liquidity,
[Savings Vault Intents](/dev/savings/savings-vault-intents) provide a request-based
withdrawal flow.
:::
:::tip[Savings Data API — display data]
The **[Savings Data API](/integrators/savings-api-reference)** is a read-only REST API
exposing current and historic savings data for the vaults — savings rate, TVL,
depositors, available liquidity, and collateral composition. Use it to render rates
and dashboards in your UI without running your own indexer or on-chain calls. The
machine-readable OpenAPI spec is published at
[`https://api.spark.fi/openapi.json`](https://api.spark.fi/openapi.json).
:::
### Comprehensive enough to build from a single prompt
These docs are written to be self-contained — for human and LLM readers alike. The
ERC-4626 flows, the Savings Data API, and the machine-readable
[OpenAPI spec](https://api.spark.fi/openapi.json) give a coding assistant everything
it needs to scaffold a working integration without any extra context.
As a quick proof point, we handed these docs to ChatGPT and asked it to build a small
Spark Savings app. It produced a working result in a single shot:
:::tip[See it for yourself]
**[Building a Spark Savings app in one prompt →](https://chatgpt.com/share/6a1d7b92-eefc-83eb-ab2c-682d327c1abd)**
A shared ChatGPT session that turns these docs into a functioning savings app — no
hand-holding, no SDK.
:::
### Savings data, ready to present
The Savings Data API gives you live and historical data about each vault — savings
rates, balances, the assets backing the vault, the liquidity behind it, and more —
so you can present Spark Savings to your users however you like. The views below
are just a few examples of what that data can power.
Live savings rates per vaultRates and TVL over timeThe assets backing the vaultAvailable liquidity by source
See the [Savings Data API Reference](/integrators/savings-api-reference) for the full
set of data and endpoints.
### Deposits and withdrawals, on-chain
Because the vaults are ERC-4626, moving funds in and out takes only a handful of
standard calls — read a balance, deposit, withdraw, redeem. The
[Spark Vaults Smart Contracts integration guide](/integrators/spark-vaults-v2) covers every
flow, with full [examples](/integrators/spark-vaults-v2-examples) in viem, ethers,
and Solidity.
### Large withdrawals via Savings Liquidity Intents
Each Spark Savings vault keeps an idle liquidity buffer for instant withdrawals.
For redemptions that exceed that buffer, integrators submit a **Savings Liquidity
Intent** — an on-chain request that the [Spark Liquidity Layer](/products/spark-liquidity-layer)
picks up off-chain, prepares liquidity for, and fulfills atomically by calling
`redeem` on the user's behalf. The user keeps custody of their vault shares until
fulfillment, and every step in the lifecycle emits an on-chain event, so the full
state of any request is easy to follow from a node or indexer.
This is how the Spark Liquidity Layer keeps deposits productively deployed across
the Spark balance sheet while still providing liquidity on demand. The mechanism
is in production and has already served billions of dollars in large withdrawals.
* **[Savings Liquidity Intents guide](/products/spark-savings/guides/liquidity-intents)** — user-facing flow and what to expect in the app.
* **[Savings Vault Intents contract reference](/dev/savings/savings-vault-intents)** — full contract behavior, request lifecycle, and configuration.
* **[Savings Vault Intents in the integration guide](/integrators/spark-vaults-v2#savings-vault-intents)** — code-level usage alongside the standard ERC-4626 flows.
### Where to go next
* **[Savings Data API Reference](/integrators/savings-api-reference)** — interactive reference for the read-only data endpoints.
* **[Spark Vaults Smart Contracts Integration Guide](/integrators/spark-vaults-v2)** — read balances, deposit, withdraw, and request large withdrawals.
* **[Examples](/integrators/spark-vaults-v2-examples)** — full snippets in viem, ethers, and Solidity.
* **[Savings Liquidity Intents](/products/spark-savings/guides/liquidity-intents)** — request-based flow for redemptions larger than the idle buffer.
### Why a data API and a smart contracts guide, not an SDK
We deliberately ship a read-only data API and a smart contracts integration guide
instead of an SDK. The reasoning:
* **Spark Vaults are standard ERC-4626.** Once you know `deposit`, `withdraw`,
`redeem`, `balanceOf`, and `assetsOf`, there is nothing else to learn — the
contract is the surface area. An SDK would mostly re-wrap an interface every
EVM tool already supports out of the box.
* **You keep your stack.** Call the vaults directly with whatever you already
trust — viem, ethers, wagmi, raw JSON-RPC, or a non-JS language. The data API
is plain HTTP, so it works the same way from anywhere.
* **Easier to migrate.** EVM tooling moves fast. ERC-4626 callsites are trivial
to port between libraries; an SDK pins you to one stack and tends to fragment
across them (a viem build, an ethers build, a React wrapper, and so on).
* **One less dependency.** No SDK means one fewer package to version, audit, and
update alongside your own release cycle.
import { SavingsApiReference } from '../../components/SavingsApiReference'
{/*
The interactive reference is rendered client-side by Scalar, so it is absent
from the static HTML. This visually-hidden link keeps the machine-readable
OpenAPI spec discoverable in the server-rendered markup (for crawlers, LLMs,
and screen readers) without showing a redundant link to sighted users.
*/}
## Spark Vaults Smart Contracts Examples
These examples show common Spark Vaults flows in viem `2.51.0`, ethers `6.16.0`, and Solidity.
The examples use the mainnet spUSDC vault:
```text
Vault: 0x28B3a8fb53B741A8Fd78c0fb9A6B2393d896a43d
Asset: 0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48
SavingsVaultIntents: 0x592B7DB9906E6f8924C4D74c2A0aB86CE44fDDDf
```
:::info
USDT has non-standard allowance behavior: changing an existing non-zero allowance directly to another non-zero allowance can revert. For USDT deposits, reset allowance to `0` before setting the new allowance, or use an approval helper that handles this pattern.
:::
### Setup
:::code-group
```ts [viem]
import { createPublicClient, createWalletClient, custom, http, parseAbi, parseUnits } from 'viem'
import { mainnet } from 'viem/chains'
const vault = '0x28B3a8fb53B741A8Fd78c0fb9A6B2393d896a43d'
const asset = '0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48'
const intents = '0x592B7DB9906E6f8924C4D74c2A0aB86CE44fDDDf'
const erc20Abi = parseAbi([
'function approve(address spender, uint256 value) returns (bool)',
])
const vaultAbi = parseAbi([
'function balanceOf(address account) view returns (uint256 shares)',
'function assetsOf(address owner) view returns (uint256 assets)',
'function convertToAssets(uint256 shares) view returns (uint256 assets)',
'function deposit(uint256 assets, address receiver) returns (uint256 shares)',
'function withdraw(uint256 assets, address receiver, address owner) returns (uint256 shares)',
'function redeem(uint256 shares, address receiver, address owner) returns (uint256 assets)',
])
const intentsAbi = parseAbi([
'function request(address vault, uint256 shares, address recipient, uint256 deadline) returns (uint256 requestId)',
'function cancel(address vault) returns (uint256 requestId)',
'function withdrawRequests(address account, address vault) view returns (uint256 requestId, uint256 shares, address recipient, uint256 deadline)',
'function vaultConfig(address vault) view returns (bool whitelisted, uint256 minIntentAssets, uint256 maxIntentAssets)',
'function maxDeadlineDuration() view returns (uint256)',
])
const publicClient = createPublicClient({
chain: mainnet,
transport: http(),
})
const walletClient = createWalletClient({
chain: mainnet,
transport: custom(window.ethereum),
})
const [account] = await walletClient.getAddresses()
```
```ts [ethers]
import { BrowserProvider, Contract, parseUnits } from 'ethers'
const vault = '0x28B3a8fb53B741A8Fd78c0fb9A6B2393d896a43d'
const asset = '0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48'
const intents = '0x592B7DB9906E6f8924C4D74c2A0aB86CE44fDDDf'
const erc20Abi = [
'function approve(address spender, uint256 value) returns (bool)',
]
const vaultAbi = [
'function balanceOf(address account) view returns (uint256)',
'function assetsOf(address owner) view returns (uint256)',
'function convertToAssets(uint256 shares) view returns (uint256)',
'function approve(address spender, uint256 value) returns (bool)',
'function deposit(uint256 assets, address receiver) returns (uint256)',
'function withdraw(uint256 assets, address receiver, address owner) returns (uint256)',
'function redeem(uint256 shares, address receiver, address owner) returns (uint256)',
]
const intentsAbi = [
'function request(address vault, uint256 shares, address recipient, uint256 deadline) returns (uint256)',
'function cancel(address vault) returns (uint256)',
'function withdrawRequests(address account, address vault) view returns (uint256 requestId, uint256 shares, address recipient, uint256 deadline)',
'function vaultConfig(address vault) view returns (bool whitelisted, uint256 minIntentAssets, uint256 maxIntentAssets)',
'function maxDeadlineDuration() view returns (uint256)',
]
const provider = new BrowserProvider(window.ethereum)
const signer = await provider.getSigner()
const account = await signer.getAddress()
const assetContract = new Contract(asset, erc20Abi, signer)
const vaultContract = new Contract(vault, vaultAbi, signer)
const intentsContract = new Contract(intents, intentsAbi, signer)
```
```solidity [Solidity]
interface IERC20 {
function approve(address spender, uint256 value) external returns (bool);
}
interface ISparkVault {
function balanceOf(address account) external view returns (uint256 shares);
function assetsOf(address owner) external view returns (uint256 assets);
function convertToAssets(uint256 shares) external view returns (uint256 assets);
function deposit(uint256 assets, address receiver) external returns (uint256 shares);
function withdraw(uint256 assets, address receiver, address owner) external returns (uint256 shares);
function redeem(uint256 shares, address receiver, address owner) external returns (uint256 assets);
}
interface ISavingsVaultIntents {
function request(
address vault,
uint256 shares,
address recipient,
uint256 deadline
) external returns (uint256 requestId);
function cancel(address vault) external returns (uint256 requestId);
function withdrawRequests(address account, address vault)
external view returns (uint256 requestId, uint256 shares, address recipient, uint256 deadline);
function vaultConfig(address vault)
external view returns (bool whitelisted, uint256 minIntentAssets, uint256 maxIntentAssets);
function maxDeadlineDuration() external view returns (uint256);
}
```
:::
### Read Balance in Assets
:::code-group
```ts [viem]
const assets = await publicClient.readContract({
address: vault,
abi: vaultAbi,
functionName: 'assetsOf',
args: [account],
})
```
```ts [ethers]
const assets = await vaultContract.assetsOf(account)
```
```solidity [Solidity]
function assetBalanceOf(ISparkVault vault, address account) external view returns (uint256) {
return vault.assetsOf(account);
}
```
:::
### Deposit
:::code-group
```ts [viem]
const depositAssets = parseUnits('1000', 6)
const approveDepositHash = await walletClient.writeContract({
address: asset,
abi: erc20Abi,
functionName: 'approve',
args: [vault, depositAssets],
})
await publicClient.waitForTransactionReceipt({ hash: approveDepositHash })
const depositHash = await walletClient.writeContract({
address: vault,
abi: vaultAbi,
functionName: 'deposit',
args: [depositAssets, account],
})
await publicClient.waitForTransactionReceipt({ hash: depositHash })
```
```ts [ethers]
const depositAssets = parseUnits('1000', 6)
await (await assetContract.approve(vault, depositAssets)).wait()
await (await vaultContract.deposit(depositAssets, account)).wait()
```
```solidity [Solidity]
function deposit(ISparkVault vault, IERC20 asset, uint256 assets, address receiver) external {
asset.approve(address(vault), assets);
vault.deposit(assets, receiver);
}
```
:::
### Withdraw
:::code-group
```ts [viem]
const withdrawHash = await walletClient.writeContract({
address: vault,
abi: vaultAbi,
functionName: 'withdraw',
args: [parseUnits('100', 6), account, account],
})
await publicClient.waitForTransactionReceipt({ hash: withdrawHash })
```
```ts [ethers]
await (await vaultContract.withdraw(parseUnits('100', 6), account, account)).wait()
```
```solidity [Solidity]
function withdraw(ISparkVault vault, uint256 assets, address receiver, address owner) external {
vault.withdraw(assets, receiver, owner);
}
```
:::
### Withdraw Everything
:::code-group
```ts [viem]
const allShares = await publicClient.readContract({
address: vault,
abi: vaultAbi,
functionName: 'balanceOf',
args: [account],
})
const redeemHash = await walletClient.writeContract({
address: vault,
abi: vaultAbi,
functionName: 'redeem',
args: [allShares, account, account],
})
await publicClient.waitForTransactionReceipt({ hash: redeemHash })
```
```ts [ethers]
const allShares = await vaultContract.balanceOf(account)
await (await vaultContract.redeem(allShares, account, account)).wait()
```
```solidity [Solidity]
function withdrawEverything(ISparkVault vault, address receiver, address owner) external {
uint256 shares = vault.balanceOf(owner);
vault.redeem(shares, receiver, owner);
}
```
:::
### Submit Intent
:::code-group
```ts [viem]
const intentShares = parseUnits('1000000', 6)
const requestedDeadline = BigInt(Math.floor(Date.now() / 1000) + 7 * 24 * 60 * 60)
const maxDeadlineDuration = await publicClient.readContract({
address: intents,
abi: intentsAbi,
functionName: 'maxDeadlineDuration',
})
const maxDeadline = BigInt(Math.floor(Date.now() / 1000)) + maxDeadlineDuration
const deadline = requestedDeadline > maxDeadline ? maxDeadline : requestedDeadline
const [whitelisted, minIntentAssets, maxIntentAssets] = await publicClient.readContract({
address: intents,
abi: intentsAbi,
functionName: 'vaultConfig',
args: [vault],
})
const intentAssets = await publicClient.readContract({
address: vault,
abi: vaultAbi,
functionName: 'convertToAssets',
args: [intentShares],
})
if (!whitelisted) throw new Error('Vault is not supported for intents')
if (intentAssets < minIntentAssets) throw new Error('Intent amount is below minimum')
if (intentAssets > maxIntentAssets) throw new Error('Intent amount is above maximum')
const approveIntentHash = await walletClient.writeContract({
address: vault,
abi: erc20Abi,
functionName: 'approve',
args: [intents, intentShares],
})
await publicClient.waitForTransactionReceipt({ hash: approveIntentHash })
const requestHash = await walletClient.writeContract({
address: intents,
abi: intentsAbi,
functionName: 'request',
args: [vault, intentShares, account, deadline],
})
await publicClient.waitForTransactionReceipt({ hash: requestHash })
```
```ts [ethers]
const intentShares = parseUnits('1000000', 6)
const requestedDeadline = BigInt(Math.floor(Date.now() / 1000) + 7 * 24 * 60 * 60)
const maxDeadlineDuration = await intentsContract.maxDeadlineDuration()
const maxDeadline = BigInt(Math.floor(Date.now() / 1000)) + maxDeadlineDuration
const deadline = requestedDeadline > maxDeadline ? maxDeadline : requestedDeadline
const [whitelisted, minIntentAssets, maxIntentAssets] = await intentsContract.vaultConfig(vault)
const intentAssets = await vaultContract.convertToAssets(intentShares)
if (!whitelisted) throw new Error('Vault is not supported for intents')
if (intentAssets < minIntentAssets) throw new Error('Intent amount is below minimum')
if (intentAssets > maxIntentAssets) throw new Error('Intent amount is above maximum')
await (await vaultContract.approve(intents, intentShares)).wait()
await (await intentsContract.request(vault, intentShares, account, deadline)).wait()
```
```solidity [Solidity]
function submitIntent(
ISparkVault vault,
ISavingsVaultIntents intents,
uint256 shares,
address recipient,
uint256 deadline
) external {
uint256 maxDeadline = block.timestamp + intents.maxDeadlineDuration();
require(deadline <= maxDeadline, "deadline-too-far");
(bool whitelisted, uint256 minIntentAssets, uint256 maxIntentAssets) =
intents.vaultConfig(address(vault));
uint256 assets = vault.convertToAssets(shares);
require(whitelisted, "unsupported-vault");
require(assets >= minIntentAssets, "intent-below-min");
require(assets <= maxIntentAssets, "intent-above-max");
IERC20(address(vault)).approve(address(intents), shares);
intents.request(address(vault), shares, recipient, deadline);
}
```
:::
### Read or Cancel Intent
:::code-group
```ts [viem]
const pendingRequest = await publicClient.readContract({
address: intents,
abi: intentsAbi,
functionName: 'withdrawRequests',
args: [account, vault],
})
const cancelHash = await walletClient.writeContract({
address: intents,
abi: intentsAbi,
functionName: 'cancel',
args: [vault],
})
await publicClient.waitForTransactionReceipt({ hash: cancelHash })
```
```ts [ethers]
const pendingRequest = await intentsContract.withdrawRequests(account, vault)
await (await intentsContract.cancel(vault)).wait()
```
```solidity [Solidity]
function readIntent(ISavingsVaultIntents intents, address account, address vault)
external view returns (uint256 requestId, uint256 shares, address recipient, uint256 deadline)
{
return intents.withdrawRequests(account, vault);
}
function cancelIntent(ISavingsVaultIntents intents, address vault) external {
intents.cancel(vault);
}
```
:::
## Spark Vaults Smart Contracts Integration Guide
import { PublicDownloadLink } from '../../components/PublicDownloadLink'
This guide shows how to integrate the Spark Vaults smart contracts for common user flows: reading balances, depositing, withdrawing, withdrawing everything, and requesting large withdrawals through Savings Vault Intents.
For a full contract reference, supported functions, roles, and events, see [Spark Savings Vaults V2](/dev/savings/spark-vaults-v2). For the intent contract reference, see [Savings Vault Intents](/dev/savings/savings-vault-intents).
### Supported Mainnet Vaults
| Vault | Protocol | Underlying asset | Vault address |
| ------ | -------- | ---------------- | --------------------------------------------------------------------------------------------------------------------- |
| spUSDC | Spark | USDC | [0x28B3a8fb53B741A8Fd78c0fb9A6B2393d896a43d](https://etherscan.io/address/0x28B3a8fb53B741A8Fd78c0fb9A6B2393d896a43d) |
| spUSDT | Spark | USDT | [0xe2e7a17dFf93280dec073C995595155283e3C372](https://etherscan.io/address/0xe2e7a17dFf93280dec073C995595155283e3C372) |
| sUSDT | Sky | USDT | [0x74cb54e082411cfCAEADb00a0765625B10410DAa](https://etherscan.io/address/0x74cb54e082411cfCAEADb00a0765625B10410DAa) |
All Spark-related addresses are tracked in the [Spark Address Registry](https://github.com/sparkdotfi/spark-address-registry).
Download the SparkVault ABI to interact with Spark Vaults.
### Core Concepts
Spark Vaults are ERC-4626 vaults. A user deposits an underlying asset, such as USDC or USDT, and receives vault shares, such as spUSDC or spUSDT.
The user's share balance does not automatically increase. Instead, each share becomes redeemable for more underlying assets over time as the vault accrues yield. This means integrations usually show balances in underlying asset terms, not only in share terms.
For example, if a user holds spUSDC, the most useful display balance is their current USDC value:
```text
asset balance = assetsOf(user)
```
`assets` are denominated in the underlying token's decimals. For the mainnet USDC and USDT vaults above, that means 6-decimal units. `shares` are denominated in the vault token's decimals, which match the underlying asset for these vaults.
### Vault Functions
#### Read Balance in Assets
```text
balanceOf(address account) returns (uint256 shares)
assetsOf(address owner) returns (uint256 assets)
```
Use `assetsOf(owner)` to show a user's current balance in underlying asset terms.
#### Deposit
```text
deposit(uint256 assets, address receiver) returns (uint256 shares)
deposit(uint256 assets, address receiver, uint16 referral) returns (uint256 shares)
previewDeposit(uint256 assets) returns (uint256 shares)
maxDeposit(address receiver) returns (uint256 assets)
```
The user approves the vault to spend the underlying asset, then calls `deposit`. The vault transfers the underlying asset from the caller and issues vault shares to `receiver`.
Use `previewDeposit(assets)` when quoting expected shares, and `maxDeposit(receiver)` when checking remaining deposit capacity.
The `referral` overload is optional. Integrators can use it when Spark has assigned them a referral code for attribution or campaigns — see [Referral Codes](/integrators/referral-codes) for how to get one and what it enables. If you do not have a referral code, use the two-argument `deposit(assets, receiver)` function.
:::info
USDT has non-standard allowance behavior: changing an existing non-zero allowance directly to another non-zero allowance can revert. For USDT deposits, reset allowance to `0` before setting the new allowance, or use an approval helper that handles this pattern.
:::
#### Withdraw
```text
withdraw(uint256 assets, address receiver, address owner) returns (uint256 shares)
previewWithdraw(uint256 assets) returns (uint256 shares)
maxWithdraw(address owner) returns (uint256 assets)
```
Use `withdraw` when the user wants a specific amount of underlying assets back. The vault burns enough shares from `owner` and sends `assets` underlying tokens to `receiver`.
Withdrawals depend on the vault's current idle liquidity. The vault can deploy assets through the Spark Liquidity Layer, so `totalAssets()` can be higher than the underlying token balance currently held by the vault.
If `maxWithdraw(owner)` is smaller than the amount the user wants to withdraw, the user has two options:
* Withdraw in smaller chunks. Spark's offchain infrastructure normally refills vault idle liquidity shortly after withdrawals.
* Use [Savings Vault Intents](#savings-vault-intents) for a single request that will be fulfilled after liquidity is prepared.
#### Withdraw Everything
```text
balanceOf(address account) returns (uint256 shares)
maxRedeem(address owner) returns (uint256 shares)
redeem(uint256 shares, address receiver, address owner) returns (uint256 assets)
```
Use `redeem(balanceOf(owner), receiver, owner)` when the user wants to withdraw their full vault position.
Before showing a one-click "withdraw all" action, compare `balanceOf(owner)` with `maxRedeem(owner)`. If `maxRedeem(owner)` is lower than the user's full share balance, the vault does not currently have enough idle liquidity to withdraw everything immediately. In that case, the user can withdraw in chunks as liquidity is refilled, or submit a Savings Vault Intent.
### Savings Vault Intents
Savings Vault Intents is a separate mainnet contract for large withdrawals:
```text
SavingsVaultIntents: 0x592B7DB9906E6f8924C4D74c2A0aB86CE44fDDDf
```
[View the contract on Etherscan](https://etherscan.io/address/0x592B7DB9906E6f8924C4D74c2A0aB86CE44fDDDf).
Download the SavingsVaultIntents ABI to interact with the intents contract.
Use intents when a user wants to withdraw more than the vault can immediately satisfy from its current idle balance. The user creates an onchain withdrawal request for a vault and a share amount. Spark's offchain infrastructure monitors these requests, prepares liquidity for the target vault, and fulfills the request automatically by calling the intent contract.
The intent contract does not custody the user's shares when the request is created. The user keeps their vault shares until fulfillment. To allow fulfillment, the user must approve the intent contract to spend the requested vault shares.
When a request is fulfilled, the intent contract calls `redeem(shares, recipient, account)` on the vault. The underlying assets are sent directly to `recipient`, and the request emits `RequestFulfilled(account, vault, requestId)`.
Each user can have one active request per vault. Calling `request` again for the same `(user, vault)` replaces the previous request and returns a new `requestId`. A user can cancel their active request with `cancel(vault)`, which emits `RequestCancelled(account, vault, requestId)`.
If the deadline passes before fulfillment, the request is no longer fulfillable. The user's shares remain in their wallet because they were never escrowed. The user can cancel the expired request or submit a replacement request with a new deadline.
#### Intent Functions
```text
request(address vault, uint256 shares, address recipient, uint256 deadline) returns (uint256 requestId)
cancel(address vault) returns (uint256 requestId)
withdrawRequests(address account, address vault) returns (uint256 requestId, uint256 shares, address recipient, uint256 deadline)
vaultConfig(address vault) returns (bool whitelisted, uint256 minIntentAssets, uint256 maxIntentAssets)
maxDeadlineDuration() returns (uint256 seconds)
```
`request` creates or replaces the user's active request for a vault. `recipient` receives the underlying assets when the request is fulfilled. `deadline` is the latest timestamp at which the request can be fulfilled. The deadline cannot be more than `maxDeadlineDuration()` seconds in the future.
`withdrawRequests(account, vault)` returns the currently active request for an account and vault. Use it to show pending request status in an interface.
Only whitelisted vaults and request sizes within `minIntentAssets` and `maxIntentAssets` are supported. If the requested share amount converts to an asset amount below `minIntentAssets` or above `maxIntentAssets`, the transaction will be rejected.
### Examples
See [Spark Vaults Smart Contracts Examples](/integrators/spark-vaults-v2-examples) for viem, ethers, and Solidity recipes.
## How to Delegate or Vote
This guide will explain how you can participate in Spark Governance by delegating your voting power or voting directly.
### Voting Power
Your voting power is the sum of your SPK tokens and staked SPK tokens in your wallet.
### Delegation
**Note:** You can **only** delegate your voting power to **whitelisted delegates**. This means you cannot delegate to an arbitrary address. The Governance page at [app.spark.fi/spk/governance](http://app.spark.fi/spk/governance) will guide you through the process of delegating to a whitelisted delegate. If you delegate to another address through the Snapshot interface, the voting power is not counted. You might see non whitelisted delegates in the Snapshot UI, due to their global delegation, but they do not have any voting power beyond their own token holdings.
Delegating increases the Spark points you earn. You can find the campaign details here: [app.spark.fi/points](https://app.spark.fi/points).
### How to Delegate Your Voting Power
1. Navigate to [app.spark.fi/spk/governance](http://app.spark.fi/spk/governance) and connect your wallet, then click "Delegate".
*Delegate page view*
2. Select the delegate you wish to delegate to, and click “Delegate” in the Actions section of the window.
*Select the delegate you wish to delegate to*
3. That’s it, your SPK voting power has now been delegated!
### Changing delegation or undelegating
1. If you wish to change your existing delegation to another delegate you can simply click “Delegate” in the Voting power delegation section of the governance page.
*Change your delegation*
2. This will open the Delegation window, and select the delegate you wish to delegate to instead.
3. You also have the option to undelegate in this window, meaning not delegate your voting power to anyone. This window can also be opened by clicking the three dots next to your existing delegation. Undelegating will enable you to vote directly with your SPK.
4. Once you have decided on who to delegate to, or undelegate entirely, click “Delegate” in the Actions section.
5. Now your delegation should be updated.
### How to vote with your own holdings
If you do not delegate your SPK voting power, you can vote directly with your holdings on [https://snapshot.box/#/s\:sparkfi.eth](https://snapshot.box/#/s\:sparkfi.eth)
* Once you connect your wallet, Snapshot should display your voting power (sum of SPK and staked SPK in your wallet)
* Review the proposals, and vote!
## Spark Governance
### **Overview**
Spark's governance system defines how the Spark operates and evolves. The governance process centers around updating the Spark Agent artifact in the Sky Atlas, which controls key protocol parameters including budgets, risk settings, asset onboarding, protocol integrations in the Spark Liquidity Layer, and new chain deployments.
The governance process creates Atlas Root Edit Proposals to modify the Spark Agent artifact, ensuring all protocol changes are transparent and aligned with the Sky Atlas.
### **Key Participants**
#### **SPK Token Holders**
SPK token holders are the foundation of Spark governance. They can:
* Vote directly on proposals using their SPK tokens
* Delegate their voting power to trusted delegates
* Participate in all governance decisions affecting the protocol
#### **Delegates**
Delegates are trusted community members who:
* Vote on behalf of users who have delegated their SPK tokens
* Represent the interests of their delegators in governance decisions
* Must be whitelisted to receive delegated voting power
*Note: The delegate application process is currently not open as the system is in its bootstrapping phase. Users can choose from existing whitelisted delegates.*
#### **Spark Risk Council (SRC)**
The Spark Risk Council serves as the protocol's risk assessment body:
* **Purpose**: Identifies, assesses, and mitigates risks in governance proposals
* **Mandate**: Reviews proposals for potential risks and can prevent malicious or high-risk proposals from proceeding to community vote
* **Review Scope**:
* Security vulnerabilities and operational attack vectors
* Market and treasury risks
* Economic risks
* Alignment with the Sky Atlas and Spark governance framework
#### **Operational Facilitator**
The Operational Facilitator ensures smooth governance operations by:
* Verifying proposals align with the Sky Atlas
* Preparing and scheduling Snapshot polls for approved proposals
* Managing the weekly governance cycle timeline
### **Governance Process**
#### **1. Proposal Submission**
All governance proposals must be submitted as forum posts in the [Spark Prime section](https://forum.sky.money/c/spark-prime/) of the Sky forum. Only eligible proposers can submit proposals:
* Holders of 1% of total SPK supply (100 million SPK tokens)
* Nested contributors (such as Phoenix Labs)
#### **2. Weekly Governance Cycle**
Spark governance operates on a structured weekly cycle:
* **Cycle Start**: Every Monday
* **Submission Deadline**: Friday 8:00 AM UTC
* **Late Submissions**: After the deadline, inclusion in the current cycle is at the Operational Facilitator's discretion
#### **3. Review Process**
#### **Spark Risk Council Review**
* **Duration**: 1 week from the start of the governance cycle
* **Authority**: Can reject proposals that pose substantial risks or are malicious
* **Outcome**: Posts a forum review stating whether the proposal is rejected or can proceed to voting
#### **Operational Facilitator Review**
* **Focus**: Ensures proposals align with the Sky Atlas
* **Requirement**: Both SRC approval and Operational Facilitator approval needed to proceed to voting
#### **4. Community Voting**
Once approved by both reviewers, proposals proceed to Snapshot voting:
* **Platform**: Snapshot (off-chain voting)
* **Duration**: 3 days
* **Approval Threshold**: More than 50% of votes in favor (excluding abstentions)
* **Voting Options**: Vote directly with SPK tokens or through delegated voting power
### **How to Participate**
#### **Direct Voting**
1. Hold SPK tokens in your wallet
2. Connect to Snapshot when voting opens at [https://snapshot.box/#/s\:sparkfi.eth](https://snapshot.box/#/s\:sparkfi.eth)
3. Cast your vote directly on proposals
#### **Delegation**
1. Choose a whitelisted delegate who represents your interests. You can do this at [https://app.spark.fi/spk/governance](https://app.spark.fi/spk/governance) or on Snapshot at [https://snapshot.box/#/s\:sparkfi.eth/delegates](https://snapshot.box/#/s\:sparkfi.eth/delegates)
2. Delegate your SPK voting power to a specific delegate.
3. Your delegate will vote on your behalf in future proposals
*Important: Only delegation to whitelisted addresses counts toward voting power. Delegation to non-whitelisted addresses will not grant voting power.*
### **Implementation Process**
#### **Successful Proposals**
When a proposal passes community voting:
1. **Atlas Update**: The Sky Atlas is updated with the approved changes
2. **Code Implementation**: If technical changes are needed, a Spark Spell is created with the required modifications
3. **Execution**: The Spark Spell is executed through the established Sky Spell process
#### **Failed Proposals**
Proposals that do not meet the approval threshold are not implemented and do not proceed to Atlas updates.
### **Additional Resources**
* [Spark Artifact: Root Edit Proposal Submission (Spark Governance Process)](https://sky-atlas.powerhouse.io/A.AG1.2.2.P6.2.1.2.1.1_Root_Edit_Proposal_Submission/1c1f2ff0-8d73-81ec-937a-c3eb8477a3d2%7C7896ed3326389fe3185cc8b90e099bca837707bd83f7)
* [SPK Token Information](/governance/spk-token)
* [Spark Prime Forum](https://forum.sky.money/c/spark-prime/)
### **FAQ**
#### **Who can submit governance proposals?**
Only holders of 1% of the total SPK supply (100 million tokens) or nested contributors like Phoenix Labs can submit proposals. This threshold ensures proposers have significant stake in the protocol's success.
#### **How long does the governance process take?**
The complete process takes approximately 2-3 weeks:
* Proposal submission before cycle starts (up to 1 week)
* 1 week for reviews (SRC + Operational Facilitator)
* 3 days for community voting
* Additional time for implementation if the proposal passes
#### **Can I change my vote after submitting it?**
Yes, votes can be changed during the voting period before it closes.
#### **What happens if I delegate my tokens but disagree with my delegate's vote?**
You can revoke your delegation at any time and vote directly, or switch to a different delegate whose views better align with yours. However, your voting power for each proposal is determined by your SPK balance and delegation at the time the poll is created, not when you cast your vote.
#### **How do I become a delegate?**
The delegate application process is currently closed as the governance system is in its bootstrapping phase.
#### **What types of changes require governance approval?**
All significant protocol changes that impacts the risk profile of the protocol require governance approval, including:
* Risk parameter adjustments
* Onboarding new assets
* Protocol integrations
* New chain deployments
:::success
**The SPK token has been airdropped!**
**Important:** The only official place to claim SPK is at [app.spark.fi/spk/airdrop](https://app.spark.fi/spk/airdrop).
Do not trust any other websites or platforms claiming to offer SPK tokens or access to claims. Beware of scammers and false SPK tokens.
:::
## SPK Token
SPK is the native governance and staking token of Spark. Designed with a long-term vision for sustainability, decentralization, and ecosystem alignment, SPK enables protocol governance, protocol security via staking, and reward distribution to participants.
### Governance
SPK is the governance token of Spark. SPK is used for signaling and sentiment checks via Snapshot voting. For more information on Spark Governance, please see the [Spark Governance](/governance) page.
### Staking
SPK can be staked and, in the future, staked SPK may be used to validate and secure products and services in the Spark ecosystem. Staked SPK earns rewards in the form of Spark Points. Symbiotic is also rewarding SPK stakers with points through its protocol. [You can read more about staking here](/staking).
### SPK Farming
You can earn SPK by depositing USDS into the SPK Farm at [app.spark.fi/spk/farm](https://app.spark.fi/spk/farm). Learn more about SPK Farming in the [SPK Farming guide](/user-guides/farming-rewards/).
### Has SPK been airdropped yet?
Yes, the SPK token has been airdropped. The final claiming date for pre-farming airdrop, and airdrop was on December 17th, 2025. Do not trust any other websites or platforms claiming to offer SPK tokens or access to claims. Beware of scammers and false SPK tokens.
### Supported Networks and Token Addresses
For official SPK deployment addresses on each supported network, see the [SPK Developer Docs](/dev/spk/). Beware of scammers and false SPK tokens.
### How can I bridge SPK between networks?
You can bridge SPK between networks using [Stargate](https://stargate.finance/bridge?srcChain=ethereum\&srcToken=0xc20059e0317DE91738d13af027DfC4a50781b066\&dstChain=bsc\&dstToken=0xAfF2e841851700D1Fc101995Ee6b81Ae21Bb87D7). Confirm you are using the correct token addresses.
**Note:** The Stargate Bridge is only for Ethereum/BSC bridging.
### Audits
You can find security audits for the SPK token [here](https://github.com/makerdao/endgame-toolkit/tree/e6c3a783614748717b4cb8d671c907a1feb71121/audits).
### What will the total supply of SPK be?
10 billion SPK tokens were minted at genesis.\* 35% of the SPK tokens were allocated to the Spark ecosystem to support the growth of Spark. The Sky ecosystem will receive 65% of the genesis tokens, which Sky will distribute through a 10 year SPK farming campaign. More details on this below.
\*Sky retains the ability to mint additional SPK tokens under extreme circumstances. Learn more in the [Sky Atlas](https://sky-atlas.io/#A.2.9.2.2.2.2.6).
The SPK supply is allocated as follows:
| **Category** | **Allocation** | **Token Amount** | **Vesting Schedule** | **Addresses** |
| ------------------- | -------------- | ----------------- | --------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Sky Farming (Users) | 65% | 6,500,000,000 SPK | Distributed by Sky over 10 years | Sky Pause Proxy (controlled by the DAO): [0xBE8E3e3618f7474F8cB1d074A26afFef007E98FB](https://etherscan.io/address/0xBE8E3e3618f7474F8cB1d074A26afFef007E98FB) |
| Ecosystem | 23% | 2,300,000,000 SPK | 17% of the tokens available at TGE (mid-term Treasury and Airdrops-Legacy) 6% available one year after TGE (long-term Treasury). | Mid-term Treasury: [0x089693ed9d9a5ac907bd1a1565867646ffaabcd6](https://etherscan.io/address/0x089693ed9d9a5ac907bd1a1565867646ffaabcd6) Airdrops-Legacy: [0x6FE588FDCC6A34207485cc6e47673F59cCEDF92B](https://etherscan.io/address/0x6FE588FDCC6A34207485cc6e47673F59cCEDF92B) Long-term Treasury: [0x46dce51a3f4cbEa91F3A1BBD48Ca5079397d5847](https://etherscan.io/address/0x46dce51a3f4cbEa91F3A1BBD48Ca5079397d5847) |
| Team | 12% | 1,200,000,000 SPK | 12-month 25% cliff, then 3-year vesting of remaining 75% | subDAO proxy (controlled by the DAO): [0x3300f198988e4C9C63F75dF86De36421f06af8c4](https://etherscan.io/address/0x3300f198988e4C9C63F75dF86De36421f06af8c4) |
The chart below contains the distribution schedule for SPK:
**Distribution Schedule**
### SPK Allocation
#### Sky Farming (users)
SPK farming is offered by the Sky ecosystem. Through Sky’s token farms, users can stake USDS to farm SPK. The SPK distribution follows the rules set forth in the [Sky Atlas](https://sky-atlas.io/#A.2.9.2.2.2.1.2.2.2), which states that SPK will be distributed by Sky through these farms on the following schedule:
| | Yearly Amount of SPK (in millions) | Total Amount of SPK (in millions) |
| ------- | ---------------------------------- | --------------------------------- |
| Year 1 | 1625.00 | 1,625.00 |
| Year 2 | 1625.00 | 3,250.00 |
| Year 3 | 812.50 | 4,062.50 |
| Year 4 | 812.50 | 4,875.00 |
| Year 5 | 406.25 | 5,281.25 |
| Year 6 | 406.25 | 5,687.50 |
| Year 7 | 203.13 | 5,890.63 |
| Year 8 | 203.13 | 6,093.75 |
| Year 9 | 203.13 | 6,296.88 |
| Year 10 | 203.13 | 6,500.00 |
Below is a visual representation of the SPK distribution schedule from Sky.
#### Ecosystem
23% of the tokens are allocated to the Spark ecosystem to support its growth.
#### Team
The team allocation is designed to ensure long-term alignment with the core contributors building and supporting Spark.
### Additional Resources
Integrators can find technical documentation for SPK here:
* [SPK Developer Docs](/dev/spk/)
## Spark Developer Documentation
:::info
This section of the documentation is intended for developers looking to learn more about, build on top of, or develop tooling for Spark. For more general information, please go to [User Guides](/user-guides/getting-started).
:::
The Spark Developer portal is your resource for all developer documentation relating to Spark. Here you will find smart contract documentation, in-depth concepts and explanations, code audits and security processes.
#### Spark Products
**Spark** is on a mission to empower the USDS ecosystem, as part of the [Sky Ecosystem](https://sky.money).
Spark consists of three main product categories:
* **SparkLend**: The USDS and DAI centric money market protocol. Combining the best liquidity directly from Sky and vertically integrating with the best DeFi protocols.
* **Savings**: Earn savings on your stablecoin holdings.
* **Spark Liquidity Layer:** Direct liquidity provision into DeFi markets.
You will find documentation for all of these products in the following sections.
:::success
**The SPK token has been airdropped!**
**Important:** The only official place to claim SPK is at [app.spark.fi/spk/airdrop](https://app.spark.fi/spk/airdrop).
Do not trust any other websites or platforms claiming to offer SPK tokens or access to claims. Beware of scammers and false SPK tokens.
:::
## SPK Token
### Overview
SPK is the governance token of Spark. You can read more about the token [here](/governance/spk-token).
### Supported Networks and Token Addresses
| Network | Token | Address |
| -------- | ----- | --------------------------------------------------------------------------------------------------------------------- |
| Ethereum | SPK | [0xc20059e0317DE91738d13af027DfC4a50781b066](https://etherscan.io/address/0xc20059e0317DE91738d13af027DfC4a50781b066) |
| BSC | SPK | [0xAfF2e841851700D1Fc101995Ee6b81Ae21Bb87D7](https://bscscan.com/address/0xAfF2e841851700D1Fc101995Ee6b81Ae21Bb87D7) |
| Base | SPK | [0x692A07f2306a3bba739e5281A26A5a97C6D7A6cA](https://basescan.org/address/0x692A07f2306a3bba739e5281A26A5a97C6D7A6cA) |
### Contract Details
* Contract Name: SDAO.sol
* Contract Source: [SDAO Code Repository](https://github.com/makerdao/endgame-toolkit/blob/master/src/SDAO.sol)
#### Variables
* **`name`**: Spark
* **`symbol`**: SPK
* **`version`**: 1
* **`decimals`**: 18
* **`totalSupply`**: An unsigned integer representing the total supply of the token. It keeps track of the total number of tokens in circulation.
* **`balanceOf`**: A mapping that associates an address with its corresponding token balance. It allows for looking up the balance of a specific address.
* **`allowance`**: A nested mapping that associates an owner address with a spender address and their approved token allowance. It allows an owner to specify how many tokens a specific spender is allowed to transfer on their behalf.
* **`nonces`**: A mapping that associates an address with its corresponding permit nonce. It is used for the EIP712 permit functionality, allowing an address to sign permit messages with a unique nonce.
#### ERC20 token functionality
The contract implements the functions specified in the ERC-20 interface.
* **`transfer`**: Transfers a specified amount of tokens from the caller's address to the specified recipient's address. It returns a boolean value indicating the success of the transfer.
* **`transferFrom`**: Transfers a specified amount of tokens from the **`from`** address to the **`to`** address. The transfer must be allowed by the **`from`** address by calling the **`approve`** function or by setting an allowance. It returns a boolean value indicating the success of the transfer.
* **`approve`**: Sets an allowance for a specific spender to spend a certain amount of tokens on behalf of the caller. It returns a boolean value indicating the success of the approval.
* **`increaseAllowance`**: Increases the allowance granted to a specific spender by adding the **`addedValue`** to the current allowance. It returns a boolean value indicating the success of the operation.
* **`decreaseAllowance`**: Decreases the allowance granted to a specific spender by subtracting the **`subtractedValue`** from the current allowance. It returns a boolean value indicating the success of the operation.
* **`permit`**: This function allows the owner to approve a permit for the spender to spend a specific amount of tokens on their behalf, using a signature for authorization.
#### Upgradeability
The contract is not upgradeable.
#### Events emitted
* **`Approval`**: This event is emitted when an approval is set for a specific address. It indicates that the owner has approved the spender to spend a certain amount of tokens.
* **`Deposit`**: This event is emitted when a deposit is made into the Savings USDC contract. It indicates the sender, the owner of the deposited assets, the amount of assets deposited, and the corresponding shares minted.
* **`Transfer`**: This event is emitted when tokens are transferred from one address to another. It indicates the amount of tokens transferred and the addresses involved in the transfer.
* **`Withdraw`**: This event is emitted when a withdrawal is made from the Savings USDC contract. It indicates the sender, the receiver of the withdrawn assets, the owner of the withdrawn shares, the amount of assets withdrawn, and the corresponding shares burned.
### Additional resources
* [SPK User Guide](/governance/spk-token)
## DebtToken
Debt tokens are interest-accruing tokens that are minted and burned on `borrow` and `repay`, representing the debt owed by the token holder. There are 2 types of debt tokens:
* ***Stable Debt Tokens*****:** represent a debt to the protocol with stable interest rate.
* [Source Code](https://github.com/sparkdotfi/sparklend-v1-core/blob/master/contracts/protocol/tokenization/StableDebtToken.sol)
:::danger
Stable Debt Tokens are not currently being used in SparkLend, they are a legacy piece of technology that will be fully deprecated at some point in the future.
:::
* ***Variable Debt Tokens*****:** represent a debt to the protocol with variable interest rate.
* [Source Code](https://github.com/sparkdotfi/sparklend-v1-core/blob/master/contracts/protocol/tokenization/VariableDebtToken.sol)
:::info
Debt tokens are not transferable.
:::
The *s/vToken* value is pegged 1:1 to the value of underlying borrowed asset and represents the current total amount owed to the protocol i.e. principal debt + interest accrued.
### EIP20 Methods
Although debt tokens are modelled on the ERC20/EIP20 standard, they are non-transferrable. Therefore they do not implement any of the standard ERC20/EIP20 functions relating to `transfer()` and `allowance()`.
Following are the standard EIP20 methods that are implemented for the debt tokens:
#### balanceOf
`function balanceOf(address account)`
Returns the most up to date accumulated debt (principal+interest) of the user.
#### totalSupply
`function totalSupply()`
Returns the most up to date total debt accrued by all protocol users for that specific type *(stable or variable rate)* of debt token.
#### decimals
`function decimals()`
Returns decimals of the token contract.
#### symbol
`function symbol()`
Returns the symbol of the token contract.
#### name
`function name()`
Returns the name of the token contract.
### EIP712 Methods
#### DOMAIN\_SEPARATOR
`function DOMAIN_SEPARATOR()`
Get the domain separator for the token at current chain.
#### nonces
`function nonces(address owner)`
Returns the nonce value for address specified as parameter. This is the nonce used when calling `permit()`
```jsx
const token = new Contract(spTokenAddres, spToken.abi, provider);
await token.nonces(user);
```
### SparkLend Specific Methods
#### Shared View Methods
Below are the view methods available for both type, stable and variable, of debt tokens.
##### POOL
`function POOL()`
Returns the address of the associated Pool for the debt token.
##### borrowAllowance
`function borrowAllowance(address fromUser, address toUser)`
##### UNDERLYING\_ASSET\_ADDRESS
`function UNDERLYING_ASSET_ADDRESS()`
Returns the underlying asset of the debt token.
##### getIncentivesController
`function getIncentivesController()`
Returns the address of the Incentives Controller contract
#### Shared Write Methods
Below are the write methods available for both type, stable and variable, of debt tokens.
##### approveDelegation
`function approveDelegation(address delegatee, uint256 amount)`
Sets the `amount` of allowance for `delegatee` to borrow of a particular debt token.
##### delegationWithSig
`function delegationWithSig(address delegator, address delegatee, uint256 value, uint256 deadline, uint8 v, bytes32 r, bytes32 s)`
Sets the `value` of allowance for `delegatee` to borrow of a particular debt token via permit function.
##### setIncentivesController
`function setIncentivesController(ISparkIncentivesController controller)`
Sets a new Incentives Controller.
:::danger
Only Pool Admin can call this methods. To update Incentives Controller on main Spark market, Governance Proposal must be submitted.
:::
#### Stable Debt Token Methods
##### getAverageStableRate
`function getAverageStableRate()`
Returns the average stable rate across all the stable rate debt in the protocol as `uint256`.
##### getUserLastUpdated
`function getUserLastUpdated(address user)`
Returns the timestamp of the last action taken by `user` as `uint40`.
##### getUserStableRate
`function getUserStableRate(address user)`
Returns the stable rate of `user` as `uint256`.
##### getSupplyData
`function getSupplyData()`
Returns the principal, the total supply, the average stable rate and the timestamp for the last update.
Return Values
| Type | Description |
| ------- | --------------------------------------------------------------------------------- |
| uint256 | The principal stable debt issued |
| uint256 | The total stable debt for the reserve across all users. Based on avg stable rate. |
| uint256 | The average stable debt rate across all users. |
| uint40 | The timestamp of the last update on total supply of stable debt token. |
##### getTotalSupplyAndAvgRate
`function getTotalSupplyAndAvgRate()`
Returns the total supply and average stable rate of the token.
Return Values
| Type | Description |
| ------- | ------------------------------------------------------------------ |
| uint256 | total debt token supply. (includes principal + cumulated interest) |
| uint256 | average stable rate |
##### getTotalSupplyLastUpdated
`function getTotalSupplyLastUpdated()`
Returns the timestamp of the last update of the total supply in `uint40`.
##### principalBalanceOf
`function principalBalanceOf(address user)`
Returns the principal debt balance of the user since the last burn/mint action.
#### Variable Debt Token Methods
##### scaledBalanceOf
`function scaledBalanceOf(address user)`
Returns the scaled debt balance of `user`. The scaled balance is the sum of all the updated stored balance divided by the reserve's liquidity index at the moment of the update.
##### getScaledUserBalanceAndSupply
`function getScaledUserBalanceAndSupply(address user)`
Returns the scaled balance of the user and the scaled total supply.
##### scaledTotalSupply
`function scaledTotalSupply()`
Returns the scaled total supply of the debt token. Represents sum(debt/index)
##### getPreviousIndex
`function getPreviousIndex(address user)`
Returns last index interest that was accrued to the user's balance (expressed in ray).
## DelegationAwareSpToken
* [Source Code](https://github.com/sparkdotfi/sparklend-v1-core/blob/master/contracts/protocol/tokenization/DelegationAwareAToken.sol)
The special type of spToken that are minted and burned upon supply and withdraw of assets that has voting power associated *(which can be delegated)* with them. These *spTokens* are enabled to delegate voting power of the underlying asset to a different address.
*DelegationAwarespToken* enables/implements all the methods available for spTokens with additional `delegateUnderlyingTo` method.
Refer [*spToken*](/dev/sparklend/tokens/sptoken) docs for full list of contract API
#### delegateUnderlyingTo
`function delegateUnderlyingTo(address delegatee)`
Delegates voting power of the underlying asset to a `delegatee` address.
:::danger
This method can only be called by `POOL_ADMIN.`
:::
## spToken
* [Source Code](https://github.com/sparkdotfi/sparklend-v1-core/blob/master/contracts/protocol/tokenization/AToken.sol)
spTokens are tokens minted and burnt upon *supply* and *withdraw* of assets to a SparkLend market, which denote the amount of crypto assets supplied and the yield earned on those assets. The spTokens’ value is pegged to the value of the corresponding supplied asset at a 1:1 ratio and can be safely stored, transferred or traded. All yield collected by the spTokens' reserves are distributed to spToken holders directly by continuously increasing their wallet balance.
### EIP20 Methods
All standard EIP20 methods are implemented for spTokens, such as `balanceOf`, `transfer`, `transferFrom`, `approve`, `totalSupply` etc.
💡 \`balanceOf\` will always return the most up to date balance of the user, which includes their principal balance + the yield generated by the principal balance.
### EIP712 Methods
#### DOMAIN\_SEPARATOR
`function DOMAIN_SEPARATOR()`
Get the domain separator for the token at current chain.
#### nonces
`function nonces(address owner)`
Returns the nonce value for address specified as parameter. This is the nonce used when calling `permit()`
### SparkLend View Methods
#### scaledBalanceOf
`function scaledBalanceOf(address user)`
Returns the scaled supply balance of `user`. The scaled balance is the sum of all the updated stored balance divided by the reserve's liquidity index at the moment of the update.
#### getScaledUserBalanceAndSupply
`function getScaledUserBalanceAndSupply(address user)`
Returns the scaled balance of the user and the scaled total supply.
#### scaledTotalSupply
`function scaledTotalSupply()`
Returns the scaled total supply of the *spToken*.
#### getPreviousIndex
`function getPreviousIndex(address user)`
Returns last index interest that was accrued to the user's balance (expressed in ray).
#### getIncentivesController
`function getIncentivesController()`
Returns the address of the Incentives Controller contract
#### POOL
`function POOL()`
Returns the address of the associated Pool for the *spToken.*
#### UNDERLYING\_ASSET\_ADDRESS
`function UNDERLYING_ASSET_ADDRESS()`
Returns address of the underlying reserve asset.
#### RESERVE\_TREASURY\_ADDRESS
`function RESERVE_TREASURY_ADDRESS()`
Returns address of the Maker Treasury, controlled by governance, receiving the fee on this *spToken.*
### SparkLend Write Methods
#### setIncentivesController
`function setIncentivesController(ISparkIncentivesController controller)`
Sets a new Incentives Controller.
:::danger
Only Pool Admin can call this methods. To update Incentives Controller on main Spark market, Governance Proposal must be submitted.
:::
#### permit
Allows a user to permit another account (or contract) to use their funds using a signed message. This enables gas-less transactions and single approval/transfer transactions.
| Parameter | Type | Description |
| --------- | ------- | ------------------------------------------------------------------------------------ |
| owner | address | The owner of the funds |
| spender | address | The spender for the funds |
| value | uint256 | The amount the spender is permitted to use |
| deadline | uint256 | The deadline timestamp that the permit is valid. Use type(uint).max for no deadline. |
| v | uint8 | Signature parameter |
| r | bytes32 | Signature parameter |
| s | bytes32 | Signature parameter |
### FAQ
#### How does spTokens accrue yield?
[Pool](/dev/sparklend/core-contracts/pool) methods (deposit, withdraw, borrow, repay, liquidationCall) updates the state and cumulated liquidity index of the reserve once every block. SpToken's `balanceOf` method returns the balance computed based on `block.timestamp` and `liquidityIndex` of the underlying reserve and hence, returns the most up to date balance of account, which includes `principal + interest.`
#### Can I transfer spTokens?
Yes! But there's a few caveats to keep in mind:
* By transferring spTokens, you’re transferring your balance of the underlying asset. Only the account holding the spTokens can `withdraw` the supplied asset.
* spToken transfer will fail if the resulting Health Factor of `user` will end up being below 1.
#### If I transfer spToken does my pending liquidity rewards get transferred?
No, liquidity rewards earned prior to the transfer of spToken are accrued by the user/address holding the spTokens originally. Though, all future liquidity rewards will be earned by the new recipient.
## RewardsController
All rewards type enabled in SparkLend are managed by RewardsDistributor. This is the contract used to check rewards data, user’s rewards balance and for claiming the rewards.
### Source Code
* [RewardsController](https://github.com/sparkdotfi/aave-v3-periphery/blob/master/contracts/rewards/RewardsController.sol)
* [RewardsDistributor](https://github.com/sparkdotfi/aave-v3-periphery/blob/master/contracts/rewards/RewardsDistributor.sol)
### Structs
#### AssetData
| Name | Type |
| ---------------- | ----------------------------- |
| rewards | mapping(address ⇒ RewardData) |
| availableRewards | address |
| decimals | uint8 |
#### RewardsData
| Name | Type |
| ------------------- | --------------------------- |
| emissionPerSecond | uint88 |
| index | uint104 |
| lastUpdateTimestamp | uint32 |
| distributionEnd | uint32 |
| usersIndex | mapping(address => uint256) |
### View Methods
#### getRewardsData
`getRewardsData (asset, reward)`
Get the data of the reward emitted for the asset.
**Call Params**
| Name | Type | Description |
| ------ | ------- | ------------------------------------------------------------------------ |
| asset | address | address of the a/s/v Tokens for which incentive information is requested |
| reward | address | address of the reward token |
**Return Value**
| Type | Description |
| ------- | --------------------------------------------------------------- |
| uint104 | index of the reward token |
| uint88 | total reward tokens awarded per second for the given asset pool |
| uint32 | unix timestamp of last time the emissions were updated |
| uint32 | unix timestamp of when the emissions will end |
#### getRewardsByAsset
`getRewardsByAsset (asset)`
Get list of rewards activated for the asset
Call Params
| Name | Type | Description |
| ----- | ------- | ------------------------------------------------------------------------ |
| asset | address | address of the a/s/vTokens for which incentive rewards list is requested |
Return Value
| Type | Description |
| ---------- | ------------------------------------------------------------ |
| address\[] | list of reward token addresses activated for the given asset |
### Write Methods
#### claimRewards
`claimRewards (assets, amount, to, reward)`
Claims single reward type specified by `reward` for the list of assets. Rewards are received by `to` address.
Call Params
| Name | Type | Description |
| ------ | ---------- | ------------------------------------------------------------------------------------------ |
| assets | address\[] | address list of assets for which rewards are being claimed. Pass a/s/vToken addresses |
| amount | uint256 | amount to claim, expressed in wei. Pass MAX\_UINT to claim entire unclaimed reward balance |
| to | address | address which will receive the reward tokens |
| reward | address | address of the reward token being claimed. eg. stkSpark |
#### claimRewardsOnBehalf
`claimRewardsOnBehalfOf (assets, amount, user, to, reward)`
Claims single reward type specified by `reward` for the given list of assets on behalf of the `user`. Rewards are received by `to` address.
:::info
The `msg.sender` must be an authorised claimer set using `setClaimer()` method, via Governance Vote.
:::
Call Params
| Name | Type | Description |
| ------ | ---------- | ------------------------------------------------------------------------------------------ |
| assets | address\[] | address list of assets for which rewards are being claimed. Pass a/s/vToken addresses |
| amount | uint256 | amount to claim, expressed in wei. Pass MAX\_UINT to claim entire unclaimed reward balance |
| user | address | address of user who’s rewards are being claimed |
| to | address | address which will receive the reward tokens |
| reward | address | address of the reward token being claimed. eg. stkSpark |
#### claimRewardsToSelf
`claimRewardsToSelf (assets, amount, reward)`
Claims single reward type accrued by the `msg.sender` specified by `reward` for the given list of assets. Rewards are received by `msg.sender` .
Call Params
| Name | Type | Description |
| ------ | ---------- | ------------------------------------------------------------------------------------------ |
| assets | address\[] | address list of assets for which rewards are being claimed. Pass a/s/vToken addresses |
| amount | uint256 | amount to claim, expressed in wei. Pass MAX\_UINT to claim entire unclaimed reward balance |
| reward | address | address of the reward token being claimed. eg. stkSpark |
#### claimAllRewards
`claimAllRewards (assets, to)`
Claims all rewards for the list of assets. Rewards are received by `to` address.
Call Params
| Name | Type | Description |
| ------ | ---------- | ------------------------------------------------------------------------------------- |
| assets | address\[] | address list of assets for which rewards are being claimed. Pass a/s/vToken addresses |
| to | address | address which will receive the reward tokens |
#### claimAllRewardsOnBehalf
`claimAllRewardsOnBehalfOf (assets, user, to)`
Claims all rewards for the given list of assets on behalf of the `user`. Rewards are received by `to` address.
:::info
The `msg.sender` must be an authorised claimer set using `setClaimer()` method, via Governance Vote.
:::
Call Params
| Name | Type | Description |
| ------ | ---------- | ------------------------------------------------------------------------------------- |
| assets | address\[] | address list of assets for which rewards are being claimed. Pass a/s/vToken addresses |
| user | address | address of user who’s rewards are being claimed |
| reward | address | address of the reward token being claimed. eg. stkSpark |
#### claimAllRewardsToSelf
`claimAllRewardsToSelf (assets)`
Claims all rewards accrued by `msg.sender` for the given list of assets. Rewards are received by `msg.sender` .
Call Params
| Name | Type | Description |
| ------ | ---------- | ------------------------------------------------------------------------------------- |
| assets | address\[] | address list of assets for which rewards are being claimed. Pass a/s/vToken addresses |
## UiIncentiveDataProviderV3
* [Source Code](https://github.com/sparkdotfi/aave-v3-periphery/blob/master/contracts/misc/UiIncentiveDataProviderV3.sol)
Contract that returns an array of all reserve incentives or user claimable rewards within a particular market, used by the [SparkLend Interface](https://github.com/sparkdotfi/spark-interface/) to display incentives data.
The [SparkLend Utilities SDK](https://github.com/sparkdotfi/spark-utilities#data-formatting-methods) includes an interface to make calls to this contract, and functions to format the response for frontend use-cases.
### Data Structures
##### AggregatedReserveIncentiveData
| Name | Type | Description |
| --------------- | ------------- | -------------------------------------------------------------------------------------------------------------- |
| underlyingAsset | address | Address of the asset supplied/borrowed in Pool |
| aIncentiveData | IncentiveData | Details of rewards distributed for supplying to SparkLend Pool i.e. rewards for spToken holders. |
| vIncentiveData | IncentiveData | Details of rewards distributed for variable debt borrowed from SparkLend Pool i.e. rewards for vToken holders. |
| sIncentiveData | IncentiveData | Details of rewards distributed for stable debt borrowed from SparkLend Pool i.e. rewards for sToken holders. |
##### IncentiveData
| Name | Type | Description |
| -------------------------- | ------------- | ------------------------------------------------------------------------------ |
| tokenAddress | address | Address of corresponding a/s/vToken. |
| incentiveControllerAddress | address | Address of Rewards Controller |
| rewardsTokenInformation | RewardInfo\[] | Array of details for all reward tokens that are available for given a/s/vToken |
##### RewardInfo
| Name | Type | Description |
| ----------------------------- | ------- | ---------------------------------------------------------------------------------------------------- |
| rewardTokenSymbol | string | Symbol of Reward Token |
| rewardTokenAddress | address | Address of Reward Token |
| rewardOracleAddress | address | Price Oracle for Reward token |
| emissionPerSecond | uint256 | Reward Token emitted per second |
| incentivesLastUpdateTimestamp | uint256 | Unix timestamp of last update made on asset’s reward token. |
| tokenIncentivesIndex | uint256 | Latest distribution index of the reward token |
| emissionEndTimestamp | uint256 | Unix timestamp of when the Incentive emission of given reward token ends for the corresponding asset |
| rewardPriceFeed | int256 | Latest answer/price from reward token price oracle |
| rewardTokenDecimals | uint8 | Decimals of reward token |
| precision | uint8 | Decimals of asset token (a/s/vToken) |
| priceFeedDecimals | uint8 | Decimals of price provided by oracle |
##### UserReserveIncentiveData
| Name | Type | Description |
| ------------------------- | ----------------- | ------------------------------------------------------------------------------------------------------------ |
| underlyingAsset | address | Address of the asset supplied/borrowed in Pool |
| spTokenIncentivesUserData | UserIncentiveData | Details of user rewards received for supplying to SparkLend Pool i.e. rewards for spToken. |
| vTokenIncentivesUserData | UserIncentiveData | Details of user rewards received for borrowing at variable rate from SparkLend Pool i.e. rewards for vToken. |
| sTokenIncentivesUserData | UserIncentiveData | Details of user rewards received for borrowing at stable rate from SparkLend Pool i.e. rewards for sToken. |
##### UserIncentiveData
| Name | Type | Description |
| -------------------------- | ----------------- | ----------------------------------------------------------------------------------- |
| tokenAddress | address | Address of corresponding a/s/vToken. |
| incentiveControllerAddress | address | Address of Rewards Controller for reward claim tx |
| userRewardsInformation | UserRewardInfo\[] | Array of details for all reward tokens accrued/claimed by user for given a/s/vToken |
##### UserRewardInfo
| Name | Type | Description |
| ------------------------ | ------- | -------------------------------------------------- |
| rewardTokenSymbol | string | Symbol of Reward Token |
| rewardOracleAddress | address | Price Oracle for Reward token |
| rewardTokenAddress | address | Address of Reward Token |
| userUnclaimedRewards | uint256 | User’s unclaimed rewards |
| tokenIncentivesUserIndex | uint256 | Latest user distribution index |
| rewardPriceFeed | int256 | Latest answer/price from reward token price oracle |
| priceFeedDecimals | uint8 | Decimals of price provided by oracle |
| rewardTokenDecimals | uint8 | Decimals of reward token |
### Methods
##### getReservesIncentivesData
`function getReservesIncentivesData(IPoolAddressesProvider provider)`
Returns `AggregatedReserveIncentiveData[]` for the pool associated with given [`provider`](/dev/sparklend/core-contracts/pooladdressesprovider).
##### getUserReservesIncentivesData
`function getUserReservesIncentivesData(IPoolAddressesProvider provider, address user)`
Returns `UserReserveIncentiveData[]` for the given `user` for the pool associated with given .
##### getFullReservesIncentiveData
`function getFullReservesIncentiveData(IPoolAddressesProvider provider, address user)`
Returns both `AggregatedReserveIncentiveData[]` and `UserReserveIncentiveData[]` for the given `user` for the pool associated with given [`provider`](/dev/sparklend/core-contracts/pooladdressesprovider).
## UiPoolDataProviderV3
* [Source Code](https://github.com/sparkdotfi/aave-v3-periphery/blob/master/contracts/misc/UiPoolDataProviderV3.sol)
Contract that returns an array of all reserve or user data for a particular market, used by the [SparkLend Interface](https://github.com/sparkdotfi/spark-interface) to display Markets and Dashboard data.
The [SparkLend Utilities SDK](https://github.com/sparkdotfi/spark-utilities#data-formatting-methods) includes an interface to make calls to this contract, and functions to format the response for frontend use-cases.
### Data Structures
#### AggregatedReserveData
View fields of `AggregatedReserveData` defined at [Github](https://github.com/aave/aave-v3-periphery/blob/ed38b6719d4bbd9d17dfbd6b9849326a0bdeea2c/contracts/misc/interfaces/IUiPoolDataProviderV3.sol#L8).
#### UserReserveData
| Name | Type | Description |
| ------------------------------- | ------- | ------------------------------------------------------------------------------------------ |
| underlyingAsset | address | Address of the underlying asset supplied/borrowed |
| scaledSpTokenBalance | uint256 | Scaled spToken balance.
scaledBalance = balance / liquidityIndex |
| usageAsCollateralEnabledOnUser | bool | true if supplied asset is enabled to be used as collateral |
| stableBorrowRate | uint256 | Stable rate at which underlying asset is borrowed by the user. 0 ⇒ no debt |
| scaledVariableDebt | uint256 | Scaled variable debt balance.
scaledBalance = balance / liquidityIndex |
| principalStableDebt | uint256 | Principal amount borrowed at stable rate |
| stableBorrowLastUpdateTimestamp | uint256 | unix timestamp of last update on user’s stable borrow position. |
#### BaseCurrencyInfo
Info data struct for base currency of the SparkLend market.
| Name | Type | Description |
| --------------------------------- | ------- | --------------------------------------------------- |
| marketReferenceCurrencyUnit | uint256 | Reference aka base currency of the SparkLend market |
| marketReferenceCurrencyPriceInUsd | int256 | Price of reference aka base currency in USD |
| networkBaseTokenPriceInUsd | int256 | Price of native token of the network/chain in USD |
| networkBaseTokenPriceDecimals | uint8 | Decimals of native token of the network/chain |
### Methods
#### getReservesList
`function getReservesList(IPoolAddressesProvider provider)`
Returns the list of initialised reserves in the Pool associated with the given [`provider`](/dev/sparklend/core-contracts/pooladdressesprovider).
#### getReservesData
`function getReservesData(IPoolAddressesProvider provider)`
Returns `BaseCurrencyInfo` of the Pool and `AggregatedReserveData[]` for all the initialised reserves in the Pool associated with the given [`provider`](/dev/sparklend/core-contracts/pooladdressesprovider).
#### getUserReservesData
`function getUserReservesData(IPoolAddressesProvider provider, address user)`
Returns `UserReserveData[]` for all user reserves in the Pool associated with the given [`provider`](/dev/sparklend/core-contracts/pooladdressesprovider).
## WalletBalanceProvider
* [Source Code](https://github.com/sparkdotfi/aave-v3-periphery/blob/master/contracts/misc/WalletBalanceProvider.sol)
Implements a logic of getting multiple tokens balance for one user address.
:::info
For getting ETH (native chain token) balance use \`MOCK\_ETH\_ADDRESS = 0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE\`.
:::
### Methods
#### balanceOf
`function balanceOf(address user, address token)`
Returns the balance of the token for user (ETH included with `MOCK_ETH_ADDRESS`).
#### batchBalanceOf
`function batchBalanceOf(address[] calldata users, address[] calldata tokens)`
Returns balances for a list of `users` and `tokens` (ETH included with `MOCK_ETH_ADDRESS`).
#### getUserWalletBalances
`function getUserWalletBalances(address provider, address user)`
Provides balances of user wallet for all reserves available on the pool
## WETHGateway
* [Source Code](https://github.com/sparkdotfi/aave-v3-periphery/blob/master/contracts/misc/WrappedTokenGatewayV3.sol)
The WETH Gateway contract is a helper that wraps and unwraps ETH, or the chain's native token such as MATIC or AVAX, as needed when interacting with the protocol.
### Write Methods
#### depositETH
**`function depositETH(address pool, address onBehalfOf, uint16 referralCode)`**
Supplies the `msg.value` amount of ETH (or native chain token) into the SparkLend pool, minting the same amount of corresponding aWETH and transferring them to the `onBehalfOf` address.
:::info
Ensure that the `depositETH()` transaction also includes the amount of ETH you are supplying in the `msg.value`.
:::
Call Params
| Name | Type | Description |
| ------------ | ------- | ------------------------------------------------------------------------------------------------- |
| pool | address | Address of the targeted pool. |
| onBehalfOf | address | Address that will receive the aWETH. Use `msg.sender` if the tokens should be sent to the caller. |
| referralCode | uint16 | Unique code for third-party referral program integration. Use `0` if no referral applies. |
#### withdrawETH
**`function withdrawETH(address pool, uint256 amount, address to)`**
Withdraws `amount` of the WETH (or wrapped native chain token), unwraps it and transfers ETH (or native chain token) to the `to` address.
💡 Ensure you set the relevant \`spToken\` allowance, before calling this function, so the \`WETHGateway\` contract can transfer the associated aWETH.
Call Params
| Name | Type | Description |
| ------ | ------- | --------------------------------------------------------------------------------------------------- |
| pool | address | Address of the targeted pool. |
| amount | uint256 | Amount to withdraw, expressed in wei units. Use `type(uint256).max` to withdraw the entire balance. |
| to | address | Address that will receive the unwrapped ETH. |
#### repayETH
**`function repayETH(address pool, uint256 amount, uint256 rateMode, address onBehalfOf)`**
Repays `amount` of ETH debt for `onBehalfOf` using the specified `rateMode`.
:::info
Ensure that the `repayETH()` transaction also includes the amount of ETH you are repaying in the `msg.value`.
:::
| Parameter Name | Type | Description |
| -------------- | ------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| pool | address | Address of the targeted underlying lending pool. |
| amount | uint256 | Amount to repay, expressed in wei units. Use `uint(-1)` to repay the entire debt, but only when the repayment is not executed on behalf of a third party. When repaying on behalf of another user, it is recommended to send an *amount* slightly higher than the current borrowed amount. |
| rateMode | uint256 | Type of debt being repaid. Stable: 1, Variable: 2 |
| onBehalfOf | address | Address for which the debt is being repaid. Use `msg.sender` if not repaying on behalf of another user. |
#### borrowETH
**`function borrowETH(address pool, uint256 amount, uint256 interestRateMode, uint16 referralCode)`**
Borrows `amount` of WETH with `interestRateMode`, sending the `amount` of unwrapped WETH to `msg.sender`.
Call Params
| Name | Type | Description |
| ---------------- | ------- | ---------------------------------------------------------------------------------------------- |
| pool | address | Address of the targeted pool. |
| amount | uint256 | Amount to borrow, expressed in wei units. |
| interestRateMode | uint256 | Type of borrow debt. Stable: 1, Variable: 2 |
| referralCode | uint16 | Unique code for third-party referral program integration. Use `0` if no referral applies. |
#### withdrawETHWithPermit
`function withdrawETHWithPermit(address pool, uint256 amount, address to, uint256 deadline, uint8 permitV, bytes32 permitR, bytes32 permitS)`
Withdraws `amount` of the WETH (or wrapped native chain token) without a separate approval tx. The ETH (or native chain token) is sent to the `to` address.
Call Params
| Name | Type | Description |
| -------- | ------- | ------------------------------------------------------------------------------------------------------------------------------ |
| pool | address | address of the targeted pool |
| amount | uint256 | amount of aWETH (or spToken corresponding to native token of chain) that will be burnt to withdraw ETH (or native chain token) |
| to | address | address that will receive the ETH (or native chain token) |
| deadline | uint256 | unix timestamp till which the signature is valid |
| permitV | uint8 | Signature parameter v |
| permitR | bytes32 | Signature parameter r |
| permitS | bytes32 | Signature parameter s |
##### emergencyTokenTransfer
`function emergencyTokenTransfer(address Token, address to, uint256 amount)`
Method for ERC20 recovery in case of stuck tokens due direct transfers to the contract address.
:::info
Can be called only by the owner of the contract i.e. Maker Governance
:::
#### emergencyEtherTransfer
`function emergencyEtherTransfer(address to, uint256 amount)`
Method for ETH (or native chain token) recovery in case of stuck ETH due selfdestruct or transfer ether to pre-computated contract address before deployment.
:::info
Can be called only by the owner of the contract i.e. Maker Governance.
:::
#### View
#### getWETHAddress
**`function getWETHAddress()`**
Returns the WETH address used by the WETHGateway.
### ABI
WETHGateway ABI
```
[
{
"inputs": [
{
"internalType": "address",
"name": "weth",
"type": "address"
},
{
"internalType": "address",
"name": "owner",
"type": "address"
}
],
"stateMutability": "nonpayable",
"type": "constructor"
},
{
"anonymous": false,
"inputs": [
{
"indexed": true,
"internalType": "address",
"name": "previousOwner",
"type": "address"
},
{
"indexed": true,
"internalType": "address",
"name": "newOwner",
"type": "address"
}
],
"name": "OwnershipTransferred",
"type": "event"
},
{
"stateMutability": "payable",
"type": "fallback"
},
{
"inputs": [
{
"internalType": "address",
"name": "pool",
"type": "address"
}
],
"name": "authorizePool",
"outputs": [],
"stateMutability": "nonpayable",
"type": "function"
},
{
"inputs": [
{
"internalType": "address",
"name": "pool",
"type": "address"
},
{
"internalType": "uint256",
"name": "amount",
"type": "uint256"
},
{
"internalType": "uint256",
"name": "interesRateMode",
"type": "uint256"
},
{
"internalType": "uint16",
"name": "referralCode",
"type": "uint16"
}
],
"name": "borrowETH",
"outputs": [],
"stateMutability": "nonpayable",
"type": "function"
},
{
"inputs": [
{
"internalType": "address",
"name": "pool",
"type": "address"
},
{
"internalType": "address",
"name": "onBehalfOf",
"type": "address"
},
{
"internalType": "uint16",
"name": "referralCode",
"type": "uint16"
}
],
"name": "depositETH",
"outputs": [],
"stateMutability": "payable",
"type": "function"
},
{
"inputs": [
{
"internalType": "address",
"name": "to",
"type": "address"
},
{
"internalType": "uint256",
"name": "amount",
"type": "uint256"
}
],
"name": "emergencyEtherTransfer",
"outputs": [],
"stateMutability": "nonpayable",
"type": "function"
},
{
"inputs": [
{
"internalType": "address",
"name": "token",
"type": "address"
},
{
"internalType": "address",
"name": "to",
"type": "address"
},
{
"internalType": "uint256",
"name": "amount",
"type": "uint256"
}
],
"name": "emergencyTokenTransfer",
"outputs": [],
"stateMutability": "nonpayable",
"type": "function"
},
{
"inputs": [],
"name": "getWETHAddress",
"outputs": [
{
"internalType": "address",
"name": "",
"type": "address"
}
],
"stateMutability": "view",
"type": "function"
},
{
"inputs": [],
"name": "owner",
"outputs": [
{
"internalType": "address",
"name": "",
"type": "address"
}
],
"stateMutability": "view",
"type": "function"
},
{
"inputs": [],
"name": "renounceOwnership",
"outputs": [],
"stateMutability": "nonpayable",
"type": "function"
},
{
"inputs": [
{
"internalType": "address",
"name": "pool",
"type": "address"
},
{
"internalType": "uint256",
"name": "amount",
"type": "uint256"
},
{
"internalType": "uint256",
"name": "rateMode",
"type": "uint256"
},
{
"internalType": "address",
"name": "onBehalfOf",
"type": "address"
}
],
"name": "repayETH",
"outputs": [],
"stateMutability": "payable",
"type": "function"
},
{
"inputs": [
{
"internalType": "address",
"name": "newOwner",
"type": "address"
}
],
"name": "transferOwnership",
"outputs": [],
"stateMutability": "nonpayable",
"type": "function"
},
{
"inputs": [
{
"internalType": "address",
"name": "pool",
"type": "address"
},
{
"internalType": "uint256",
"name": "amount",
"type": "uint256"
},
{
"internalType": "address",
"name": "to",
"type": "address"
}
],
"name": "withdrawETH",
"outputs": [],
"stateMutability": "nonpayable",
"type": "function"
},
{
"inputs": [
{
"internalType": "address",
"name": "pool",
"type": "address"
},
{
"internalType": "uint256",
"name": "amount",
"type": "uint256"
},
{
"internalType": "address",
"name": "to",
"type": "address"
},
{
"internalType": "uint256",
"name": "deadline",
"type": "uint256"
},
{
"internalType": "uint8",
"name": "permitV",
"type": "uint8"
},
{
"internalType": "bytes32",
"name": "permitR",
"type": "bytes32"
},
{
"internalType": "bytes32",
"name": "permitS",
"type": "bytes32"
}
],
"name": "withdrawETHWithPermit",
"outputs": [],
"stateMutability": "nonpayable",
"type": "function"
},
{
"stateMutability": "payable",
"type": "receive"
}
]
```
## Credit Delegation
Credit delegation allows a supplier to supply funds in the protocol to earn interest, and delegate borrowing power (i.e. their credit) to other users. The enforcement of the loan and its terms are agreed upon between the supplier and borrowers, which can be either off-chain via legal agreements or on-chain via smart contracts.
This enables:
* The supplier (aka delegator) to earn extra yield on top of the yield they already earn from the protocol,
* The borrowers (aka delegatees) to access an uncollateralized loan.
:::warning
Borrow by *delegatee* must be consistent with *delegator* [eMode](/dev/sparklend/features/efficiency-mode-emode) category.\
For eg. if a delegator eMode category is `STABLECOINS`, then
* delegator can only borrow `STABLECOINS` eMode category asset.
* in case *delegator* approve credit to *delegatee* for non `STABLECOINS`category (for eg. weth), then borrow would revert.
:::
:::danger
The *delegatee* cannot abuse credit approval to liquidate *delegator* i.e. if the borrow puts *delegator's* position in HF \< `HEALTH_FACTOR_LIQUIDATION_THRESHOLD`, then borrow will fail.
:::
### Approving the delegation
The [`approveDelegation()`](/dev/sparklend/tokens/debttoken#approvedelegation) or [`delegationWithSig()`](/dev/sparklend/tokens/debttoken#delegationwithsig) must be called by the supplier (delegator), approving the borrower (delegatee) a certain amount.
This is done for each debt token that needs to be delegated.
:::info
The delegator does not need to already have supplied funds in the protocol to `approveDelegation()`. However, **before** the delegatee executes `borrow()`, there must be sufficient collateral supplied by delegator in the protocol.
:::
### Borrowing the credit
The borrower (delegatee) calls the [`borrow()`](/dev/sparklend/core-contracts/pool#borrow) method on the `Pool`, using the supplier's (delegator's) address in final parameter `onBehalfOf`.
The borrower's available credit is reduced by the borrowed amount.
### Repaying the credit
Anyone can repay the debt *OnBehalf* of the user, by calling one of the methods - [repay()](/dev/sparklend/core-contracts/pool#repay) or [repayWithPermit()](/dev/sparklend/core-contracts/pool#repaywithpermit). The supplier (aka creditor) can also use [repayWithSpTokens()](/dev/sparklend/core-contracts/pool#repaywithsptokens) method to repay debt with their *spTokens* of the underlying debt asset in the same pool.
## Efficiency Mode (eMode)
### Efficiency Mode (eMode)
The High Efficiency mode feature (or "eMode") is designed to maximise capital efficiency when collateral and borrowed assets are correlated in price.
The `RISK_ADMINS` and `POOL_ADMIN`, set by Maker Governace, can configure a maximum of 255 eMode categories, with each `EModeCategory` having following *risk management parameters*:
* LTV (Loan to value)
* Liquidation threshold
* Liquidation bonus
* A custom price oracle (optional)
:::info
💡 Category 0 is reserved as the default non-eMode category. All the assets listed on SparkLend, by default have category 0 (which indicates the standard operational mode).
:::
All Assets listed on SparkLend can be set to any of the pre-configured `eModeCategory` by the `RISK_ADMINS` or `POOL_ADMIN`.
:::info
The correct categorisation is not enforced on-chain and needs to be maintained by the `RISK_ADMINS` and `POOL_ADMINS` selected via the Maker Governace vote.
:::
eMode also offers the possibility of introducing a specific price oracle for a certain category.
### How it works?
If the user has supplied liquidity to the protocol, the user `eMode` category is set to 0 by default.
The protocol allows user to set the user eMode category to any of the `eModeCategories` configured by the `PoolConfigurator` given the following conditions holds true:
* all the borrowed assets of the user are in the chosen category.
* changing eMode doesn’t leave user position under-collateralised
## Flash Loans
Flash Loans are special transactions that allow the borrowing of an asset, as long as the borrowed amount (and a fee) is returned before the end of the transaction (also called One Block Borrows). These transactions do not require a user to supply collateral prior to engaging in the transaction. There is no real world analogy to Flash Loans, so it requires some basic understanding of how state is managed within blocks in blockchains.
:::info
Flash Loans are an advanced concept aimed at developers. You **must** have a good understanding of EVM, programming, and smart contracts to be able to use this feature.
:::
### Overview
Flash-loan allows users to access liquidity of the pool (only for reserves for which borrow is enabled) for one transaction as long as the amount taken plus fee is returned or (if allowed) debt position is opened by the end of the transaction.
SparkLend offers two options for flash loans:
* [`flashLoan`](/dev/sparklend/core-contracts/pool#flashloan): Allows borrower to access liquidity of ***multiple reserves*** in single *flashLoan* transaction. The borrower also has an option to open stable or variabled rate debt position backed by supplied collateral or credit delegation in this case.\
NOTE: *flash loan fee* is waived for approved `flashBorrowers` (managed by [ACLManager](/dev/sparklend/core-contracts/aclmanager))
* [`flashLoanSimple`](/dev/sparklend/core-contracts/pool#flashloansimple): Allows borrower to access liquidity of *single reserve* for the transaction. In this case flash loan fee is not waived nor can borrower open any debt position at the end of the transaction. This method is gas efficient for those trying take advantage of simple flash loan with single reserve asset.
#### Execution Flow
For developers, a helpful mental model to consider when developing your solution:
1. Your contract calls the `Pool` contract, requesting a Flash Loan of a certain `amount(s)` of `reserve(s)` using [`flashLoanSimple()`](/dev/sparklend/core-contracts/pool#flashloansimple) or [`flashLoan()`](/dev/sparklend/core-contracts/pool#flashloan).
2. After some sanity checks, the `Pool` transfers the requested `amounts` of the `reserves` to your contract, then calls `executeOperation()` on `receiver` contract .
3. Your contract, now holding the flash loaned `amount(s)`, executes any arbitrary operation in its code.
* If you are performing a **flashLoanSimple**, then when your code has finished, you approve Pool for flash loaned amount + fee.
* If you are performing **flashLoan,** then for all the reserves either depending on `interestRateMode` passed for the asset, either the Pool must be approved for flash loaned amount + fee or must or sufficient collateral or credit delegation should be available to open debt position.
* If the amount owing is not available (due to a lack of balance or approval or insufficient collateral for debt), then the transaction is reverted.
4. All of the above happens in 1 transaction (hence in a single ethereum block).
#### Applications of Flash Loans
SparkLend Flash Loans are already used with SparkLend for liquidity swap feature. Other examples in the wild include:
* Arbitrage between assets, without needing to have the principal amount to execute the arbitrage.
* Liquidating borrow positions, without having to repay the debt of the positions and using discounted collateral claimed to payoff flashLoan amount + fee.
#### Flash loan fee
The flash loan fee is initialized at deployment to 0.09% and can be updated via Governance Vote. Use [`FLASHLOAN_PREMIUM_TOTAL`](/dev/sparklend/core-contracts/pool#flashloan) to get current value.
Flashloan fee can be shared by the LPs (liquidity providers) and the protocol treasury. The `FLASHLOAN_PREMIUM_TOTAL` represents the total fee paid by the borrowers of which:
* Fee to LP: `FLASHLOAN_PREMIUM_TOTAL - FLASHLOAN_PREMIUM_TO_PROTOCOL`
* Fee to Protocol: `FLASHLOAN_PREMIUM_TO_PROTOCOL`
:::info
At initialization, `FLASHLOAN_PREMIUM_TO_PROTOCOL` is set to 0.
:::
### Step by step
#### 1. Setting Up
Your contract that receives the flash loaned amounts **must** conform to the [IFlashLoanSimpleReceiver.sol](https://github.com/aave/aave-v3-core/blob/master/contracts/flashloan/interfaces/IFlashLoanSimpleReceiver.sol) or [IFlashLoanReceiver.sol](https://github.com/aave/aave-v3-core/blob/master/contracts/flashloan/interfaces/IFlashLoanReceiver.sol) interface by implementing the relevant `executeOperation()` function.
Also note that since the owed amounts will be *pulled* from your contract, your contract must give allowance to the `Pool` to pull those funds to pay back the flash loan amount + premiums.
#### 2. Calling flashLoan() or flashLoanSimple()
To call either of the two flash loan methods on the Pool, we need to pass in the relevant parameters. There are 3 ways you can do this.
1. **From an EOA ('normal' ethereum account)**
To use an EOA, send a transaction to the relevant `Pool` calling the `flashLoan()` or `flashLoanSimple()` function. See [Pool api docs](/dev/sparklend/core-contracts/pool) for parameter details, ensuring you use your contract address from [step 1](#1-setting-up) for the `receiverAddress`.\\
2. **From a different contract**
Similar to sending a transaction from an EOA as above, ensure the `receiverAddress` is your contract address from [step 1](#1-setting-up).\\
3. **From the \_same**\_\*\* contract\*\*
If you want to use the same contract as in step 1, use `address(this)` for the `receiverAddress` parameter in the flash loan method.
:::danger
Never keep funds permanently on your `FlashLoanReceiverBase` contract as they could be exposed to a ['griefing' attack](https://ethereum.stackexchange.com/a/92457/19365), where the stored funds are used by an attacker.
:::
#### Completing the flash loan
Once you have performed your logic with the flash loaned assets (in your `executeOperation()` function), you will need to pay back the flash loaned amounts if you used `flashLoanSimple() or` `interestRateMode=0` in `flashLoan()`for any of the assets in `modes` parameter.
* **Paying back a flash loaned asset**
Ensure your contract has the relevant amount + premium to payback the borrowed asset. You can calculate this by taking the sum of the relevant entry in the `amounts` and `premiums` array passed into the `executeOperation()` function.\\
You **do not** need to transfer the owed amount back to the `Pool`. The funds will be automatically *pulled* at the conclusion of your operation.
* **Incurring a debt (i.e. not immediately paying back)**
If you initially used a `mode=1` or `mode=2` for any of the assets in the `modes` parameter, then the address passed in for `onBehalfOf` will incur the debt **if** the `onBehalfOf` address has previously approved the `msg.sender` to incur debts on their behalf.
This means that you can have some assets that are paid back immediately, while other assets incur a debt.
## Isolation Mode
Isolation mode allows new assets to be listed as ***Isolated***. These assets have a specific debt ceiling and can only be used to borrow stablecoins that have been permitted by Maker Governance to be borrowable in isolation mode.
:::info
Debt Ceiling for an \*Isolated Asset\* is represented as the maximum amount in USD that can be borrowed against the collateral with two decimals of precision.
:::
### Supply Isolated Asset
A user can supply an *Isolated Asset* just like any other asset using the `supply()` method in `Pool.sol`. The default behaviour depends on the following conditions:
| Use as Collateral | Condition |
| ----------------- | ---------------------------------------------------------------------------------------------------------------------- |
| Enabled | If the isolated asset is the first asset supplied by the user, or if no other supplied asset is enabled as collateral. |
| Disabled | If any other asset is currently enabled as collateral. |
:::info
If the user has other assets enabled as collateral, they can still supply an *Isolated Asset* to capture yield, but they will not be able to use it as collateral.
:::
### Borrow in Isolated Mode
Borrowers using an *Isolated Asset* as collateral can only use that particular asset as collateral and can only borrow assets that are *borrowable in isolation mode,* i.e. have `BORROWABLE_IN_ISOLATION_MASK` bit set in reserve configuration.
:::info
A borrower in Isolation Mode cannot enable any other assets, including other isolated assets, as collateral.
:::
### Exit Isolation Mode
Users can turn off isolation mode by disabling the isolated asset as collateral. This can only be done if the user has no outstanding debt. A user must use the `repay()` method in `Pool.sol` to pay off all debt before exiting Isolation Mode.
## Liquidations
The health of the SparkLend is dependent on the 'health' of the collateralised positions within the protocol, also known as the 'health factor'. When the 'health factor' of an account's total loans is below 1, anyone can make a `liquidationCall()` to the [`Pool`](/dev/sparklend/core-contracts/pool#liquidationcall) contract, pay back part of the debt owed and receive discounted collateral in return (also known as the liquidation bonus).
This incentivises third parties to participate in the health of the overall protocol, by acting in their own interest (to receive the discounted collateral) and as a result, ensure borrows are sufficiently collateralize.
There are multiple ways to participate in liquidations:
1. By calling the liquidationCall() directly in the [Pool](/dev/sparklend/core-contracts/pool#liquidationcall) contract.
2. By creating your own automated bot or system to liquidate loans.
:::warning
For liquidation calls to be profitable, you must take into account the gas cost involved in liquidating the loan. If a high gas price is used, then the liquidation may be unprofitable for you. See the [Calculating profitability](#calculating-profitability-vs-gas-cost) section for more details.
:::
:::info
SparkLend allows 100% of debt (i.e. `MAX_LIQUIDATION_CLOSE_FACTOR`) to be liquidated in single `liquidationCall()` if:\
`HF < CLOSE_FACTOR_HF_THRESHOLD = 0.95`
:::
### Prerequisites
When making a `liquidationCall()`, you must:
* Know the account (i.e. the ethreum address: `user`) whose health factor is below 1.
* Know the valid debt amount and asset (i.e. `debtToCover` & `debtAsset`)
* If the HF is above `CLOSE_FACTOR_HF_THRESHOLD = 0.95`, then only a maximum of 50% (i.e. `DEFAULT_LIQUIDATION_CLOSE_FACTOR`) of the debt can be liquidated per valid `liquidationCall()`
* If the HF is below `CLOSE_FACTOR_HF_THRESHOLD = 0.95`, then 100% (i.e. `MAX_LIQUIDATION_CLOSE_FACTOR`) of the debt can be liquidated in single valid `liquidationCall()`
* You can set the `debtToCover` to `uint(-1)` and the protocol will proceed with the highest possible liquidation allowed by the close factor.
* You must already have sufficient balance of the debt asset, which will be used by the `liquidationCall` to pay back the debt. You can use `flashLoan` for liquidations 😉
* Know the collateral asset `collateralAsset` you closing, i.e. the asset that the user has `backing` their outstanding loan that you will receive as a `bonus`.
* Whether you want to receive *spTokens* or the underlying asset after a successful `liquidationCall()` .
### Getting accounts to liquidate
:::warning
"User Account" in the SparkLend refer to a single ethereum address that has interacted with the protocol. This can be an externally owned account or contract.
:::
Only user accounts that have HF \< 1 can be liquidated. There are multiple ways you can get the health factor:
#### On Chain
1. To gather user account data from on-chain data, one way would be to monitor emitted events from the protocol and keep an up to date index of user data locally.
1. Events are emitted each time a user interacts with the protocol (supply, borrow, repay, withdraw etc.)
2. When you have the user's address, you can simply call [`getUserAccountData()`](/dev/sparklend/core-contracts/pool#getuseraccountdata), to read the user's current healthFactor. If the HF \< 1, then the account can be liquidated.
### Executing the liquidation call
Once you have the account(s) to liquidate, you will need to calculate the amount of collateral that can be liquidated:
1. Use [`getUserReserveData()`](/dev/sparklend/periphery-contracts/uipooldataproviderv3#getuserreservesdata)
2. Max debt that be cleared by single liquidation call is given by the `DEFAULT_LIQUIDATION_CLOSE_FACTOR`(when `CLOSE_FACTOR_HF_THRESHOLD = 0.95 < HF < 1`) or `MAX_LIQUIDATION_CLOSE_FACTOR` (when `HF < CLOSE_FACTOR_HF_THRESHOLD = 0.95`)
1. `debtToCover = (userStableDebt + userVariableDebt) * LiquidationCloseFactor`
2. You can pass `uint(-1)`, i.e. `MAX_UINT`, as the `debtToCover` to liquidate the maximum amount allowed.
3. Max amount of collateral that can be liquidated to cover debt is given by the current *liquidationBonus* for the reserves that have `usageAsCollateralEnabled` as true.
1. `maxAmountOfCollateralToLiquidate = (debtAssetPrice * debtToCover * liquidationBonus)/ collateralPrice`
### Calculating profitability vs gas cost
One way to calculate the profitability is the following:
1. Store and retrieve each collateral's relevant details such as address, decimals used and liquidation bonus.
2. Get the user's collateral balance (spTokenBalance).
3. Get the asset's price according to the SparkLend's oracle contract using [`getAssetPrice()`](/dev/sparklend/core-contracts/aaveoracle#getassetprice).
4. The maximum collateral bonus received on liquidation is given by the `maxAmountOfCollateralToLiquidate * (1 - liquidationBonus) * collateralAssetPriceEth`
5. The maximum cost of your transaction will be you gas price multiplied by the amount of gas used. You should be able to get a good estimation of the gas amount used by calling `estimateGas` via your web3 provider.
6. Your approximate profit will be the value of the collateral bonus (4) minus the cost of your transaction (5).
### Appendix
#### How is health factor calculated?
The health factor is calculated from the user's total collateral, i.e. all reserves for which `usageAsCollateral` is enabled, balance (in ETH) multiplied by the liquidation threshold percentage for all the user's outstanding assets, divided by the user's total borrow balance across all reserves (in ETH). This can be calculated both off-chain and on-chain, see [SparkLend-utilities](https://github.com/sparkdotfi/spark-utilities/blob/cdf8a8bf87c8848a2f0865c58defbd04e0871171/packages/math-utils/src/pool-math.ts#L169) and [GenericLogic Library](https://github.com/aave/aave-v3-core/blob/c8722965501b182f6ab380db23e52983eb87e406/contracts/protocol/libraries/logic/GenericLogic.sol#L183) respectively for reference.
#### How is liquidation bonus determined?
Liquidation bonuses for all the assets are evaluated and determined based on each asset's liquidity risk and updated via Maker Governance process.
## Repay With spTokens
Allows user to repay with *spTokens* in case the underlying borrowed asset is locked in the SparkLend liquidity pool.
*Example:* **User have stable DAI debt and also holds spDAI token**
The user in this case can use aDAI to repay DAI debt in single transaction without any approvals or having to withdraw their supplied liquidity to the pool using `repayWithSpTokens` feature.
```tsx
import { Contract, utils } from "ethers";
const poolAbi = require("./abis/pool.json");
const pool = new Contract(POOL_ADDRESS, poolAbi, signer);
// repay amount of DAI debt using spDAI tokens
pool.repayWithSpTokens(DAI.address, amount, 2);
// User must hold spDAI >= amount being repaid
```
## Siloed Borrowing
This feature allow assets with potentially manipulatable oracles (for example illiquid Uni V3 pairs) to be listed on SparkLend as single borrow asset i.e. if user borrows siloed asset, they cannot borrow any other asset. This helps mitigating the risk associated with such assets from impacting the overall solvency of the protocol.
:::info
[Risk or Pool admin](/dev/sparklend/core-contracts/aclmanager#roles), selected by Maker Governance, can call [`setSiloedBorrowing`](/dev/sparklend/core-contracts/poolconfigurator#setsiloedborrowing) to set an asset in *Siloed Borrowing* mode.
:::
### Supply Siloed Assets
A user can supply S\_iloed Asset\_ just like any other asset using [`supply()`](/dev/sparklend/core-contracts/pool#supply) method in `pool.sol`, though, the asset will not be enabled to use as collateral i.e. supplied amount will not add to total collateral balance of the user.
#### Borrow Siloed Assets
:::danger
User borrowing a *siloed asset* will \_ **not**\_ be allowed to \_\_ borrow \_\_ any other asset\_.\_
:::
User can borrow *Siloed Assets* using [`borrow()`](/dev/sparklend/core-contracts/pool#borrow) method in `pool.sol` , only if:
* It is first borrow onBehalf of the address
OR
* Existing user debt is of the same *siloed asset.*
To check if user is in Siloed Borrowing state, you can see if underlying asset borrowed by user is s\_iloed\_ using [`getSiloedBorrowing()`](dev/sparklend/core-contracts/aavedataprovider#getsiloedborrowing) method on AaveDataProvider.sol.
#### Check if Reserved for Siloed Borrowing
```solidity
import {AaveProtocolDataProvider} from '@aave/core-v3/contracts/misc/AaveProtocolDataProvider.sol';
AaveProtocolDataProvider poolDataProvider = AaveProtocolDataProvider(provider.getPoolDataProvider());
// address of the underlying asset
address asset = "0x...";
protocolDataProvider.getSiloedBorrowing(asset);
```
#### FAQ
##### How can user enter siloed borrowing state?
User automatically enters siloed borrowing state on their first successful borrow of siloed asset.
##### How does user exit siloed borrowing state?
User must repay all their debt to exist siloed borrowing state.
## Supply Borrow Caps
### Supply/Borrow Caps
Maker Governance can appoint `RISK_ADMIN` and `POOL_ADMIN` who have the ability to configure Borrow and Supply Caps of the individual reserves.
### **Borrow Caps**
Allow modulation of how much of each asset can be borrowed, which reduces insolvency risk.
By default borrow cap of an asset is 0, which signifies no cap. Anyone who has been granted `RISK_ADMIN` or `POOL_ADMIN` role via the ACLManager can call [`setBorrowCap` method in PoolConfigurator](/dev/sparklend/core-contracts/poolconfigurator#write-methods) to update the max total borrow (stable + variable) for the given reserve.
:::info
In case \*Borrow Cap\* of the reserve is set lower than the current \*totalDebt\* the existing borrowers are not effected but no more borrows (stable or variable) can be initiated for that reserve.
:::
### **Supply Caps**
Allow limiting how much of a certain asset is supplied to SparkLend. This helps reducing exposure to a certain asset and mitigate attacks like infinite minting or price oracle manipulation.
By default supply cap of an asset is 0, which signifies no cap. Anyone who has been granted `RISK_ADMIN` or `POOL_ADMIN` role via the ACLManager can call [`setSupplyCap` method in PoolConfigurator](/dev/sparklend/core-contracts/poolconfigurator#write-methods) to update the liquidity supply for the given reserve.
:::info
In case *Supply Cap* of the reserve is set lower than the current liquidity of the reserve, the existing suppliers are not effected but no more liquidity can be supplied to that reserve.
:::
## Testing Guide
* Test Markets
* Tenderly: Debugging from browser
* Tenderly Fork: Connect custom contracts to SparkLend Frontend
### Test Markets
:::warning
Goerli testnet is no longer supported. As of October 4th, new changes are not reflected Goerli, run a local fork of mainnet instead.
:::
The simplest way to interact with SparkLend in a test environment is to connect your wallet and use the app with fauceted funds on a test network. All test markets can be accessed from the [app](https://app.spark.fi) or from cloning/forking the [SparkLend frontend](https://github.com/sparkdotfi/spark-interface).
:::info
To interact with test markets make sure you toggle the **Testnet mode** *on*. The testnet option is available on [app](https://app.spark.fi) in top right ⚙️ drop-down-menu.
:::
First, you’ll need to add the test network to your wallet. You can directly add networks to your browser wallet with [Chainlist](https://chainlist.org).
Next, you’ll need to faucet some base currency for the test network to pay gas for transactions. You can find a list of different faucet tokens at [app.spark.fi/faucet](https://app.spark.fi/faucet/).
Each testnet market has a custom set of assets which can be fauceted from the SparkLend faucet. To access the faucet interface: switch to the market which you want to test, be sure your wallet is connected to the correct network and *testnet mode* is on. The faucet link is available at bottom of the supply column in *Dashboard* or you can manually update url to `https://app.spark.fi/faucet/`.
Once you have test assets, you can supply, borrow, repay, withdraw, and test the features:
#### E-Mode
E-Mode enables users to access a higher borrowing power when supplying and borrowing assets in the same category (stablecoins, ETH, etc.). E-Mode can be enabled and disabled from the Dashboard screen. Once in E-Mode, collateral and debt is limited to a single asset class and the LTV for supplying assets in this category is increased.
#### Isolation Mode
Isolation mode which allows the listing of assets with restricted borrowing capacity. Isolated assets are usually newly listed assets that you can only borrow up to a certain debt ceiling.
#### Supply and Repay With Permit
To enable Pool spending of user assets in the supply and repay functions in V2, an approval transaction was required. In V3, assets which implement EIP 2612 can be approved for spending with a signature which does not incur any gas cost.
#### Multi-Incentives
Each spToken or debtToken can support multiple incentives. After supplying or borrowing a supported asset, incentives can be viewed and claimed individually or all at once from the Dashboard.
### Tenderly
Tenderly is a tool for interacting and debugging smart contracts in a browser interface. It can be used to run simulations against live contracts or deploy/test contracts on a network fork with no coding experience required.
#### Simulation
To run simulations you will need two things, a contract address and contract abi.
The contract addresses for each official and testnet market of the SparkLend can be found here.
The abi for each contract can obtained from a block explorer or compiling contract code directly.
From a block explorer (etherscan, polygonscan, etc.), if the contract source code is verified you can find the abi by clicking Contract → Read As Proxy → Click the implementation address → Toward the bottom of the page will be an abi that can be copied. Most SparkLend contracts are deployed as a governance upgradeable proxy which is why the Read As Proxy step is required.
To compile the abi from contract code, from the deployed contracts page, click the link to source code on GitHub and take note of the repo and branch name. You will need to clone the protocol contracts repo and checkout the branch corresponding to the market deployment. Then run `npm i` and `npm run compile` to compile the contracts and generate abis in the `artifacts` folder.
#### Forks
A fork can be created from the Tenderly website which will allow you to deploy your own contracts to a fork of almost any EVM network.
#### Connect To SparkLend UI
A Tenderly fork can also be created with simplified steps for connecting to the SparkLend frontend by cloning this [repo](https://github.com/sakulstra/tenderly-fork). Once cloned, you can input your Tenderly API credentials and wallet address into the .env file, then run the commands from the `README` to start a fork on a specified network.
With the output from running the start command you can add fork network to your browser wallet with the chainId and rpc URL provided, then paste the three commands into the browser console of an open tab of the SparkLend Frontend. Once you reload the page, a new market will be created with an f indicator.
## Troubleshooting
### Error Codes
In order to reduce gas usage and code size, /spark-protocol contracts return numbered errors. If you are making calls to the protocol and receive numbered errors, you can use the reference below to know what is the error. Alternatively, you can also find what the numbers represent by checking the [`Errors.sol`](https://github.com/aave/aave-v3-core/blob/master/contracts/protocol/libraries/helpers/Errors.sol)
#### Reference Guide
Error codes are returned as string.
| ERROR CODE (string) | ERROR NAME | ERROR DESCRIPTION |
| ------------------- | --------------------------------------------------- | --------------------------------------------------------------------------------------------------------- |
| 1 | CALLER\_NOT\_POOL\_ADMIN | The caller of the function is not a pool admin |
| 2 | CALLER\_NOT\_EMERGENCY\_ADMIN | The caller of the function is not an emergency admin |
| 3 | CALLER\_NOT\_POOL\_OR\_EMERGENCY\_ADMIN | The caller of the function is not a pool or emergency admin |
| 4 | CALLER\_NOT\_RISK\_OR\_POOL\_ADMIN | The caller of the function is not a risk or pool admin |
| 5 | CALLER\_NOT\_ASSET\_LISTING\_OR\_POOL\_ADMIN | The caller of the function is not an asset listing or pool admin |
| 6 | CALLER\_NOT\_BRIDGE | The caller of the function is not a bridge |
| 7 | ADDRESSES\_PROVIDER\_NOT\_REGISTERED | Pool addresses provider is not registered |
| 8 | INVALID\_ADDRESSES\_PROVIDER\_ID | Invalid id for the pool addresses provider |
| 9 | NOT\_CONTRACT | Address is not a contract |
| 10 | CALLER\_NOT\_POOL\_CONFIGURATOR | The caller of the function is not the pool configurator |
| 11 | CALLER\_NOT\_ATOKEN | The caller of the function is not an SpToken |
| 12 | INVALID\_ADDRESSES\_PROVIDER | The address of the pool addresses provider is invalid |
| 13 | INVALID\_FLASHLOAN\_EXECUTOR\_RETURN | Invalid return value of the flashloan executor function |
| 14 | RESERVE\_ALREADY\_ADDED | Reserve has already been added to reserve list |
| 15 | NO\_MORE\_RESERVES\_ALLOWED | Maximum amount of reserves in the pool reached |
| 16 | EMODE\_CATEGORY\_RESERVED | Zero eMode category is reserved for volatile heterogeneous assets |
| 17 | INVALID\_EMODE\_CATEGORY\_ASSIGNMENT | Invalid eMode category assignment to asset |
| 18 | RESERVE\_LIQUIDITY\_NOT\_ZERO | The liquidity of the reserve needs to be 0 |
| 19 | FLASHLOAN\_PREMIUM\_INVALID | Invalid flashloan premium |
| 20 | INVALID\_RESERVE\_PARAMS | Invalid risk parameters for the reserve |
| 21 | INVALID\_EMODE\_CATEGORY\_PARAMS | Invalid risk parameters for the eMode category |
| 22 | BRIDGE\_PROTOCOL\_FEE\_INVALID | Invalid bridge protocol fee |
| 23 | CALLER\_MUST\_BE\_POOL | The caller of this function must be a pool |
| 24 | INVALID\_MINT\_AMOUNT | Invalid amount to mint |
| 25 | INVALID\_BURN\_AMOUNT | Invalid amount to burn |
| 26 | INVALID\_AMOUNT | Amount must be greater than 0 |
| 27 | RESERVE\_INACTIVE | Action requires an active reserve |
| 28 | RESERVE\_FROZEN | Action cannot be performed because the reserve is frozen |
| 29 | RESERVE\_PAUSED | Action cannot be performed because the reserve is paused |
| 30 | BORROWING\_NOT\_ENABLED | Borrowing is not enabled |
| 31 | STABLE\_BORROWING\_NOT\_ENABLED | Stable borrowing is not enabled |
| 32 | NOT\_ENOUGH\_AVAILABLE\_USER\_BALANCE | User cannot withdraw more than the available balance |
| 33 | INVALID\_INTEREST\_RATE\_MODE\_SELECTED | Invalid interest rate mode selected |
| 34 | COLLATERAL\_BALANCE\_IS\_ZERO | The collateral balance is 0 |
| 35 | HEALTH\_FACTOR\_LOWER\_THAN\_LIQUIDATION\_THRESHOLD | Health factor is lesser than the liquidation threshold |
| 36 | COLLATERAL\_CANNOT\_COVER\_NEW\_BORROW | There is not enough collateral to cover a new borrow |
| 37 | COLLATERAL\_SAME\_AS\_BORROWING\_CURRENCY | Collateral is (mostly) the same currency that is being borrowed |
| 38 | AMOUNT\_BIGGER\_THAN\_MAX\_LOAN\_SIZE\_STABLE | The requested amount is greater than the max loan size in stable rate mode |
| 39 | NO\_DEBT\_OF\_SELECTED\_TYPE | For repayment of a specific type of debt, the user needs to have debt that type |
| 40 | NO\_EXPLICIT\_AMOUNT\_TO\_REPAY\_ON\_BEHALF | To repay on behalf of a user an explicit amount to repay is needed |
| 41 | NO\_OUTSTANDING\_STABLE\_DEBT | User does not have outstanding stable rate debt on this reserve |
| 42 | NO\_OUTSTANDING\_VARIABLE\_DEBT | User does not have outstanding variable rate debt on this reserve |
| 43 | UNDERLYING\_BALANCE\_ZERO | The underlying balance needs to be greater than 0 |
| 44 | INTEREST\_RATE\_REBALANCE\_CONDITIONS\_NOT\_MET | Interest rate rebalance conditions were not met |
| 45 | HEALTH\_FACTOR\_NOT\_BELOW\_THRESHOLD | Health factor is not below the threshold |
| 46 | COLLATERAL\_CANNOT\_BE\_LIQUIDATED | The collateral chosen cannot be liquidated |
| 47 | SPECIFIED\_CURRENCY\_NOT\_BORROWED\_BY\_USER | User did not borrow the specified currency |
| 48 | SAME\_BLOCK\_BORROW\_REPAY | Borrow and repay in same block is not allowed |
| 49 | INCONSISTENT\_FLASHLOAN\_PARAMS | Inconsistent flashloan parameters |
| 50 | BORROW\_CAP\_EXCEEDED | Borrow cap is exceeded |
| 51 | SUPPLY\_CAP\_EXCEEDED | Supply cap is exceeded |
| 52 | UNBACKED\_MINT\_CAP\_EXCEEDED | Unbacked mint cap is exceeded |
| 53 | DEBT\_CEILING\_EXCEEDED | Debt ceiling is exceeded |
| 54 | ATOKEN\_SUPPLY\_NOT\_ZERO | SpToken supply is not zero |
| 55 | STABLE\_DEBT\_NOT\_ZERO | Stable debt supply is not zero |
| 56 | VARIABLE\_DEBT\_SUPPLY\_NOT\_ZERO | Variable debt supply is not zero |
| 57 | LTV\_VALIDATION\_FAILED | Ltv validation failed |
| 58 | INCONSISTENT\_EMODE\_CATEGORY | Inconsistent eMode category |
| 59 | PRICE\_ORACLE\_SENTINEL\_CHECK\_FAILED | Price oracle sentinel validation failed |
| 60 | ASSET\_NOT\_BORROWABLE\_IN\_ISOLATION | Asset is not borrowable in isolation mode |
| 61 | RESERVE\_ALREADY\_INITIALIZED | Reserve has already been initialized |
| 62 | USER\_IN\_ISOLATION\_MODE | User is in isolation mode |
| 63 | INVALID\_LTV | Invalid ltv parameter for the reserve |
| 64 | INVALID\_LIQ\_THRESHOLD | Invalid liquidity threshold parameter for the reserve |
| 65 | INVALID\_LIQ\_BONUS | Invalid liquidity bonus parameter for the reserve |
| 66 | INVALID\_DECIMALS | Invalid decimals parameter of the underlying asset of the reserve |
| 67 | INVALID\_RESERVE\_FACTOR | Invalid reserve factor parameter for the reserve |
| 68 | INVALID\_BORROW\_CAP | Invalid borrow cap for the reserve |
| 69 | INVALID\_SUPPLY\_CAP | Invalid supply cap for the reserve |
| 70 | INVALID\_LIQUIDATION\_PROTOCOL\_FEE | Invalid liquidation protocol fee for the reserve |
| 71 | INVALID\_EMODE\_CATEGORY | Invalid eMode category for the reserve |
| 72 | INVALID\_UNBACKED\_MINT\_CAP | Invalid unbacked mint cap for the reserve |
| 73 | INVALID\_DEBT\_CEILING | Invalid debt ceiling for the reserve |
| 74 | INVALID\_RESERVE\_INDEX | Invalid reserve index |
| 75 | ACL\_ADMIN\_CANNOT\_BE\_ZERO | ACL admin cannot be set to the zero address |
| 76 | INCONSISTENT\_PARAMS\_LENGTH | Array parameters that should be equal length are not |
| 77 | ZERO\_ADDRESS\_NOT\_VALID | Zero address not valid |
| 78 | INVALID\_EXPIRATION | Invalid expiration |
| 79 | INVALID\_SIGNATURE | Invalid signature |
| 80 | OPERATION\_NOT\_SUPPORTED | Operation not supported |
| 81 | DEBT\_CEILING\_NOT\_ZERO | Debt ceiling is not zero |
| 82 | ASSET\_NOT\_LISTED | Asset is not listed |
| 83 | INVALID\_OPTIMAL\_USAGE\_RATIO | Invalid optimal usage ratio |
| 84 | INVALID\_OPTIMAL\_STABLE\_TO\_TOTAL\_DEBT\_RATIO | Invalid optimal stable to total debt ratio |
| 85 | UNDERLYING\_CANNOT\_BE\_RESCUED | The underlying asset cannot be rescued |
| 86 | ADDRESSES\_PROVIDER\_ALREADY\_ADDED | Reserve has already been added to reserve list |
| 87 | POOL\_ADDRESSES\_DO\_NOT\_MATCH | The token implementation pool address and the pool address provided by the initializing pool do not match |
| 88 | STABLE\_BORROWING\_ENABLED | Stable borrowing is enabled |
| 89 | SILOED\_BORROWING\_VIOLATION | User is trying to borrow multiple assets including a siloed one |
| 90 | RESERVE\_DEBT\_NOT\_ZERO | // the total debt of the reserve needs to be 0 |
## AaveProtocolDataProvider
* [Source Code](https://github.com/sparkdotfi/sparklend-v1-core/blob/master/contracts/misc/AaveProtocolDataProvider.sol)
Peripheral contract to collect and pre-process information from the Pool.
#### Constructor
```solidity
constructor(IPoolAddressesProvider addressesProvider)
```
Initializes the contract with the PoolAddressesProvider.
#### Methods
##### getAllReservesTokens
`function getAllReservesTokens() external view returns (TokenData[] memory)`
Returns list of the existing reserves in the pool.
Return Value
| Type | Description |
| --------- | ------------------------------------------- |
| `string` | The symbol of the underlying reserve asset |
| `address` | The address of the underlying reserve asset |
##### getAllSpTokens
`function getAllSpTokens() external view returns (TokenData[] memory)`
Returns list of the existing SpTokens in the pool.
Return Value
| Type | Description |
| --------- | ------------------------------------- |
| `string` | The symbol of spToken of the reserve |
| `address` | The address of spToken of the reserve |
##### getReserveConfigurationData
`function getReserveConfigurationData(address asset) external view returns (....)`
Returns the configuration data of the reserve as described below:
Call Params
| Name | Type | Description |
| ----- | --------- | -------------------------------------------------- |
| asset | `address` | The address of the underlying asset of the reserve |
Return Value
| Type | Description |
| --------- | ----------------------------------------------------------- |
| `uint256` | The number of decimals of the reserve |
| `uint256` | The ltv of the reserve (in basis points, 1 = 0.01%) |
| `uint256` | The liquidationThreshold of the reserve (in basis points) |
| `uint256` | The liquidationBonus of the reserve (in basis points) |
| `uint256` | The reserveFactor of the reserve (in basis points) |
| `bool` | True if the usage as collateral is enabled, false otherwise |
| `bool` | True if borrowing is enabled, false otherwise |
| `bool` | True if stable rate borrowing is enabled, false otherwise |
| `bool` | True if reserve is active, false otherwise |
| `bool` | True if reserve is frozen, false otherwise |
##### getReserveEModeCategory
`function getReserveEModeCategory(address asset) external view returns (uint256)`
Returns reserve's efficiency mode category.
Call Params
| Name | Type | Description |
| ----- | --------- | -------------------------------------------------- |
| asset | `address` | The address of the underlying asset of the reserve |
Return Value
| Type | Description |
| --------- | ------------------------------- |
| `uint256` | The efficiency mode category ID |
##### getReserveCaps
`function getReserveCaps(address asset) external view returns (uint256 borrowCap, uint256 supplyCap)`
Returns the caps parameters of the reserve
Call Params
| Name | Type | Description |
| ----- | --------- | -------------------------------------------------- |
| asset | `address` | The address of the underlying asset of the reserve |
Return Value
| Type | Description |
| --------- | ----------------------------- |
| `uint256` | The borrow cap of the reserve |
| `uint256` | The supply cap of the reserve |
##### getPaused
`function getPaused(address asset) external view returns (bool isPaused)`
Returns true if the pool is paused.
Call Params
| Name | Type | Description |
| ----- | --------- | -------------------------------------------------- |
| asset | `address` | The address of the underlying asset of the reserve |
Return Value
| Type | Description |
| ------ | -------------------------- |
| `bool` | True if the pool is paused |
##### getSiloedBorrowing
`function getSiloedBorrowing(address asset) external view returns (bool)`
Returns true if the asset is ***siloed for borrowing***.
Call Params
| Name | Type | Description |
| ----- | --------- | -------------------------------------------------- |
| asset | `address` | The address of the underlying asset of the reserve |
Return Value
| Type | Description |
| ------ | ----------------------------------------- |
| `bool` | True if the asset is siloed for borrowing |
##### getLiquidationProtocolFee
`function getLiquidationProtocolFee(address asset) external view returns (uint256)`
Returns the protocol fee on the liquidation bonus.
Call Params
| Name | Type | Description |
| ----- | --------- | -------------------------------------------------- |
| asset | `address` | The address of the underlying asset of the reserve |
Return Value
| Type | Description |
| --------- | ------------------------------- |
| `uint256` | The protocol fee on liquidation |
##### getUnbackedMintCap
`function getUnbackedMintCap(address asset) external view returns (uint256)`
Returns the unbacked mint cap of the reserve
Call Params
| Name | Type | Description |
| ----- | --------- | -------------------------------------------------- |
| asset | `address` | The address of the underlying asset of the reserve |
Return Value
| Type | Description |
| --------- | ------------------------------------ |
| `uint256` | The unbacked mint cap of the reserve |
##### getDebtCeiling
`function getDebtCeiling(address asset) external view returns (uint256)`
Returns the debt ceiling of the reserve
Call Params
| Name | Type | Description |
| ----- | --------- | -------------------------------------------------- |
| asset | `address` | The address of the underlying asset of the reserve |
Return Value
| Type | Description |
| --------- | ------------------------------- |
| `uint256` | The debt ceiling of the reserve |
##### getDebtCeilingDecimals
`function getDebtCeilingDecimals() external pure returns (uint256)`
Returns the debt ceiling decimals
Return Value
| Type | Description |
| --------- | ------------------------- |
| `uint256` | The debt ceiling decimals |
##### getReserveData
`function getReserveData(address asset) external view override returns(....)`
Returns the following reserve data 👇🏻
Call Params
| Name | Type | Description |
| ----- | --------- | -------------------------------------------------- |
| asset | `address` | The address of the underlying asset of the reserve |
Return Value
| Type | Description |
| --------- | -------------------------------------------------------------------- |
| `uint256` | The amount of unbacked aTokens of the reserve |
| `uint256` | The scaled amount of tokens accrued to treasury that is to be minted |
| `uint256` | The total supply of the aToken |
| `uint256` | The total stable debt of the reserve |
| `uint256` | The total variable debt of the reserve |
| `uint256` | The liquidity rate of the reserve |
| `uint256` | The variable borrow rate of the reserve |
| `uint256` | The stable borrow rate of the reserve |
| `uint256` | The average stable borrow rate of the reserve |
| `uint256` | The liquidity index of the reserve |
| `uint256` | The variable borrow index of the reserve |
| `uint40` | The timestamp of the last update of the reserve |
##### getSpTokenTotalSupply
`function getSpTokenTotalSupply(address asset) external view override returns (uint256)`
Returns the total supply of spTokens for a given asset
Call Params
| Name | Type | Description |
| ----- | --------- | -------------------------------------------------- |
| asset | `address` | The address of the underlying asset of the reserve |
Return Value
| Type | Description |
| --------- | ------------------------------- |
| `uint256` | The total supply of the spToken |
##### getTotalDebt
`function getTotalDebt(address asset) external view override returns (uint256)`
Returns the total debt for a given asset
Call Params
| Name | Type | Description |
| ----- | --------- | -------------------------------------------------- |
| asset | `address` | The address of the underlying asset of the reserve |
Return Value
| Type | Description |
| --------- | ----------------------------------------------- |
| `uint256` | The total debt (stable + variable) for an asset |
##### getUserReserveData
`function getUserReserveData(address asset, address user) external view returns (...)`
Returns the following user reserve data
Call Params
| Name | Type | Description |
| ----- | --------- | -------------------------------------------------- |
| asset | `address` | The address of the underlying asset of the reserve |
| user | `address` | The address of the user |
Return Value
| Type | Description |
| --------- | ------------------------------------------------------------- |
| `uint256` | The current aToken balance of the user |
| `uint256` | The current stable debt of the user |
| `uint256` | The current variable debt of the user |
| `uint256` | The principal stable debt of the user |
| `uint256` | The scaled variable debt of the user |
| `uint256` | The stable borrow rate of the user |
| `uint256` | The liquidity rate of the reserve |
| `uint40` | The timestamp of the last update of the user stable rate |
| `bool` | True if the user is using the asset as collateral, else false |
##### getReserveTokensAddresses
`function getReserveTokensAddresses(address asset) external view returns (address aTokenAddress, address stableDebtTokenAddress, address variableDebtTokenAddress)`
Returns the addresses of aToken, stableDebtToken and variableDebtToken of the reserve
Call Params
| Name | Type | Description |
| ----- | --------- | -------------------------------------------------- |
| asset | `address` | The address of the underlying asset of the reserve |
Return Value
| Type | Description |
| --------- | -------------------------------------------- |
| `address` | The aToken address of the reserve |
| `address` | The StableDebtToken address of the reserve |
| `address` | The VariableDebtToken address of the reserve |
##### getInterestRateStrategyAddress
`function getInterestRateStrategyAddress(address asset) external view returns (address irStrategyAddress)`
Returns the address of the Interest Rate strategy
Call Params
| Name | Type | Description |
| ----- | --------- | -------------------------------------------------- |
| asset | `address` | The address of the underlying asset of the reserve |
Return Value
| Type | Description |
| --------- | ----------------------------------------- |
| `address` | The address of the Interest Rate strategy |
##### getAllATokens
`function getAllATokens() external view returns (TokenData[] memory)`
Returns list of the existing aTokens in the pool.
Return Value
| Type | Description |
| --------- | ------------------------------------ |
| `string` | The symbol of aToken of the reserve |
| `address` | The address of aToken of the reserve |
##### getATokenTotalSupply
`function getATokenTotalSupply(address asset) external view returns (uint256)`
Returns the total supply of aTokens for a given asset
Call Params
| Name | Type | Description |
| ----- | --------- | -------------------------------------------------- |
| asset | `address` | The address of the underlying asset of the reserve |
Return Value
| Type | Description |
| --------- | ------------------------------ |
| `uint256` | The total supply of the aToken |
##### getFlashLoanEnabled
`function getFlashLoanEnabled(address asset) external view returns (bool)`
Returns whether flash loan is enabled for the reserve.
Call Params
| Name | Type | Description |
| ----- | --------- | -------------------------------------------------- |
| asset | `address` | The address of the underlying asset of the reserve |
Return Value
| Type | Description |
| ------ | ---------------------------------------------- |
| `bool` | True if flash loan is enabled, false otherwise |
## AaveOracle
* [Source Code](https://github.com/sparkdotfi/sparklend-v1-core/blob/master/contracts/misc/AaveOracle.sol)
Contract to get asset prices, manage price sources and update the fallback oracle.
SparkLend utilizes a redundant oracle aggregator (Aggor) that leverages price feeds from Chronicle, Chainlink and Redstone for its lending markets.
The oracle uses Chainlink Aggregators as the first source of price. If the returned price by a Chainlink aggregator is `<= 0`, the call is forwarded to a fallback oracle. If the asset is the `BASE_CURRENCY`, it returns `BASE_CURRENCY_UNIT` directly.
#### State Variables
| Name | Type | Description |
| -------------------- | ------- | ------------------------------------------------------------------------------ |
| `BASE_CURRENCY` | address | The base currency used for price quotes (if USD is used, base currency is 0x0) |
| `BASE_CURRENCY_UNIT` | uint256 | The unit of the base currency |
#### Constructor
```solidity
constructor(
IPoolAddressesProvider provider,
address[] memory assets,
address[] memory sources,
address fallbackOracle,
address baseCurrency,
uint256 baseCurrencyUnit
)
```
Initializes the oracle with:
* PoolAddressesProvider
* Initial list of assets and their price sources
* Fallback oracle address
* Base currency and its unit
### Methods
#### View
##### getAssetPrice
`function getAssetPrice(address asset)`
Returns the price of the supported `asset` in `BASE_CURRENCY` of SparkLend Market in wei.
* If the asset is BASE\_CURRENCY, returns BASE\_CURRENCY\_UNIT
* Otherwise, tries to get price from price oracle (Aggor).
Return Value
| Type | Description |
| ------- | --------------------------------------------------- |
| uint256 | Price in BASE\_CURRENCY of the Spark market in wei. |
##### getAssetsPrices
`function getAssetsPrices(address[] calldata assets)`
Returns the prices of the supported `assets` in `BASE_CURRENCY` of the Spark Market. All prices are in wei.
Call Params
| Name | Type | Description |
| ------ | ---------- | ------------------------------------------------------------- |
| assets | address\[] | The addresses of the assets for which price is being queried. |
Return Value
| Type | Description |
| ---------- | ---------------------------------------------------- |
| uint256\[] | Prices in BASE\_CURRENCY of the Spark market in wei. |
##### getSourceOfAsset
`function getSourceOfAsset(address asset)`
Returns the address of the price source for `asset`.
##### getFallbackOracle
`function getFallbackOracle()`
Returns the address of the fallback oracle.
#### Write
##### setAssetSources
`function setAssetSources(address[] calldata assets, address[] calldata sources)`
Sets the price source for given list of assets.
:::danger
This method can be called only by `POOL_ADMIN` or `ASSET_LISTING_ADMIN`. Check [ACLManager](/dev/sparklend/core-contracts/aclmanager) for details on system roles.
:::
Call Params
| Name | Type | Description |
| ------- | ---------- | ------------------------------------------------------------------------------------------- |
| assets | address\[] | The addresses of the assets for which source is being set. |
| sources | address\[] | The address of the source of each asset. Length of assets and sources array should be same. |
##### setFallbackOracle
`function setFallbackOracle(address fallbackOracle)`
Sets/updates the fallback oracle.
:::danger
This method can be called only by `POOL_ADMIN`or`ASSET_LISTING_ADMIN`. Check [ACLManager](/dev/sparklend/core-contracts/aclmanager) for details on system roles.
:::
Call Params
| Name | Type | Description |
| -------------- | ------- | ----------------------------------- |
| fallbackOracle | address | The address of the fallback oracle. |
## ACLManager
* [Source Code](https://github.com/sparkdotfi/sparklend-v1-core/blob/master/contracts/protocol/configuration/ACLManager.sol)
### Overview
The *Access Control List Manager* (ACLManager) is the main registry of system roles and permissions. It inherits from OpenZeppelin's `AccessControl` contract and implements the `IACLManager` interface.
ACLManager allows a ***Role Admin*** to manage roles. ***Role Admin*** is itself a role that is managed by the `DEFAULT_ADMIN_ROLE`.
`DEFAULT_ADMIN_ROLE` is held by the *ACLAdmin,* which is initialized in `PoolAddressesProvider`. The ACL admin must be set in the PoolAddressesProvider before deploying the ACLManager.
:::info
On Ethereum chain `PoolAddressesProvider`, is owned by Sky Governance. In networks other than Ethereum, either the *Crosschain Governance Bridges* or *Community Multisigs* are used to manage the `PoolAddressesProvider`.
:::
#### Constructor
```solidity
constructor(IPoolAddressesProvider provider)
```
Initializes the ACLManager with the PoolAddressesProvider. The ACL admin must be set in the provider beforehand and cannot be the zero address.
#### Role Constants
All role constants are keccak256 hashes of their respective role names:
* `POOL_ADMIN_ROLE = keccak256('POOL_ADMIN')`
* `EMERGENCY_ADMIN_ROLE = keccak256('EMERGENCY_ADMIN')`
* `RISK_ADMIN_ROLE = keccak256('RISK_ADMIN')`
* `FLASH_BORROWER_ROLE = keccak256('FLASH_BORROWER')`
* `BRIDGE_ROLE = keccak256('BRIDGE')`
* `ASSET_LISTING_ADMIN_ROLE = keccak256('ASSET_LISTING_ADMIN')`
### Roles
Below we outline the powers/responsibilities of the roles and the specific methods that are only accessible to the holders of these roles.
| Role | Responsibilities / Powers | Methods Accessible |
| --------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `FLASH_BORROWER` | Flash loan premium is waived for the holders of this role.⛔️ Does not include flashLoanSimple | `flashLoan` |
| `BRIDGE` | Can leverage the Portal feature | mintUnbacked backUnbacked |
| `ASSET_LISTING_ADMIN` | Can update asset oracle sources fallback oracle add new assets to the Spark market | setAssetSources setFallbackOracle initReserves |
| `RISK_ADMIN` | Can update grace period of Oracle Sentinels reserve params unbacked mint cap liquidation protocol fee existing eMode categories and create new. (not category 0) add/remove asset in silo mode | setGracePeriod setReserveBorrowing configureReserveAsCollateral setReserveStableRateBorrowing setReserveFreeze setBorrowableInIsolation setReserveFactor setDebtCeiling setBorrowCap setSupplyCap setLiquidationProtocolFee setEModeCategory setAssetEModeCategory setUnbackedMintCap setReserveInterestRateStrategyAddress setSiloedBorrowing |
| `ACL_ADMIN` | Manage the role admins in the ACLManager | setRoleAdmin addPoolAdmin removePoolAdmin addEmergencyAdmin removeEmergencyAdmin addRiskAdmin removeRiskAdmin addFlashBorrower removeFlashBorrower addBridge removeBridge addAssetListingAdmin removeAssetListingAdmin |
| `EMERGENCY_ADMIN` | Can pause/unpause the pool or individual reserve | setPoolPause |
| `POOL_ADMIN` | Can update token implementations drop reserves pause/unpause reserves activate/deactivate reserves update premiums do all the things available to RISK\_ADMIN ASSET\_LISTING\_ADMIN | all methods available to RISK\_ADMIN all methods available to ASSET\_LISTING\_ADMIN dropReserve updateSpToken updateStableDebtToken updateVariableDebtToken setReserveActive updateBridgeProtocolFee updateFlashloanPremiumTotal updateFlashloanPremiumToProtocol |
### View Methods
#### isPoolAdmin
`function isPoolAdmin(address admin)`
Returns `true` if the address has `POOL_ADMIN` role.
#### isEmergencyAdmin
`function isEmergencyAdmin(address admin)`
Returns `true` if the address has `EMERGENCY_ADMIN` role.
#### isRiskAdmin
`function isRiskAdmin(address admin)`
Returns `true` if the address has `RISK_ADMIN` role.
#### isFlashBorrower
`function isFlashBorrower(address borrower)`
Returns `true` if the address has `FLASH_BORROWER` role.
#### isBridge
`function isBridge(address bridge)`
Returns `true` if the address has `BRIDGE` role.
#### isAssetListingAdmin
`function isAssetListingAdmin(address admin)`
Returns `true` if the address has `ASSET_LISTING_ADMIN` role.
### Write Methods
#### setRoleAdmin
`setRoleAdmin(bytes32 role, bytes32 adminRole)`
Setup admin to manage Roles. This method can only be called by an address with `DEFAULT_ADMIN_ROLE`.
:::info
This method can only be called by address with `DEFAULT_ADMIN_ROLE`.
:::
Call Params
| Name | Type | Description |
| --------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| role | bytes32 | One of the role constants: POOL\_ADMIN\_ROLE, EMERGENCY\_ADMIN\_ROLE, RISK\_ADMIN\_ROLE, FLASH\_BORROWER\_ROLE, BRIDGE\_ROLE, or ASSET\_LISTING\_ADMIN\_ROLE |
| adminRole | bytes32 | The role that will be able to grant/revoke the specified role. 0x00 is reserved for DEFAULT\_ADMIN\_ROLE |
#### addPoolAdmin
`addPoolAdmin(address admin)`
Add address to the list of members in `POOL_ADMIN` role. Holders of this role can update token implementations, drop, (un)pause and (de)activate reserves, update premiums and do everything the `ASSET_LISTING_ADMIN` and `RISK_ADMIN` can do.
:::info
Can be called only by *Role Admin*, specified by *Maker Governance*, responsible for managing `POOL_ADMIN` role.
:::
Call Params
| Name | Type | Description |
| ----- | ------- | ----------------------------------------------- |
| admin | address | address which will be granted POOL\_ADMIN role. |
#### removePoolAdmin
`removePoolAdmin(address admin)`
Remove given address from the list of members in `POOL_ADMIN` role.
:::info
Can be called only by *Role Admin*, specified by *Maker Governance*, responsible for managing `POOL_ADMIN` role.
:::
Call Params
| Name | Type | Description |
| ----- | ------- | --------------------------------------------------------------- |
| admin | address | address for which POOL\_ADMIN role permissions must be revoked. |
#### addEmergencyAdmin
`addEmergencyAdmin(address admin)`
Add address to the list of members in `EMERGENCY_ADMIN` role. Holders of this role can pause and unpause the pool or an individual reserve.
:::info
Can be called only by *Role Admin*, specified by *Maker Governance*, responsible for managing`EMERGENCY_ADMIN` role.
:::
| Name | Type | Description |
| ----- | ------- | ---------------------------------------------------- |
| admin | address | address which will be granted EMERGENCY\_ADMIN role. |
#### removeEmergencyAdmin
`function removeEmergencyAdmin(address admin)`
Remove given address from the list of members in `EMERGENCY_ADMIN` role.
:::info
Can be called only by *Role Admin*, specified by *Maker Governance*, responsible for managing `EMERGENCY_ADMIN` role.
:::
| Name | Type | Description |
| ----- | ------- | -------------------------------------------------------------------- |
| admin | address | address for which EMERGENCY\_ADMIN role permissions must be revoked. |
#### addRiskAdmin
`function addRiskAdmin(address admin)`
Add address to the list of members in `RISK_ADMIN` role. Holders of this role can update grace period of Oracle Sentinels, reserve params, unbacked mint cap, liquidation fee and eMode categories.
| Name | Type | Description |
| ----- | ------- | ----------------------------------------------- |
| admin | address | address which will be granted RISK\_ADMIN role. |
#### removeRiskAdmin
Remove given address from the list of members in `RISK_ADMIN` role.
| Name | Type | Description |
| ----- | ------- | --------------------------------------------------------------- |
| admin | address | address for which RISK\_ADMIN role permissions must be revoked. |
#### addFlashBorrower
`function addFlashBorrower(address borrower)`
Add address to the list of members in `FLASH_BORROWER` role. Holders of this role do not pay premium for flash loan (Does not apply to `flashLonaSimple`).
#### removeFlashBorrower
`function removeFlashBorrower(address borrower)`
Remove given address from the list of members in `FLASH_BORROWER` role.
| Name | Type | Description |
| ----- | ------- | ------------------------------------------------------------------- |
| admin | address | address for which FLASH\_BORROWER role permissions must be revoked. |
#### addBridge
`addBridge(address bridge)`
Add contract address to the list of ***bridges***. Holders of this role can leverage the Portal feature to seamlessly move supplied assets across Spark Lend markets on different networks.
:::info
Can be called only by *Role Admin*, specified by *Maker Governance*, responsible for managing `BRIDGE` role.
:::
| Name | Type | Description |
| ------ | ------- | ------------------------------------------ |
| bridge | address | address which will be granted BRIDGE role. |
#### removeBridge
`removeBridge(address bridge)`
Remove contract address from the list of ***bridges***.
:::info
Can be called only by *Role Admin*, specified by *Maker Governance*, responsible for managing `BRIDGE` role.
:::
| Name | Type | Description |
| ------ | ------- | ---------------------------------------------------------- |
| bridge | address | address for which BRIDGE role permissions must be revoked. |
#### addAssetListingAdmin
`function addAssetListingAdmin(address admin)`
Add address to the list of member in `ASSET_LISTING_ADMIN` role. Holder of this role can update oracles & add new asset to the Spark market.
| Name | Type | Description |
| ----- | ------- | --------------------------------------------------------- |
| admin | address | address which will be granted ASSET\_LISTING\_ADMIN role. |
#### removeAssetListingAdmin
`function removeAssetListingAdmin(address admin)`
Remove address from the list of members in `ASSET_LISTING_ADMIN` role.
| Name | Type | Description |
| ----- | ------- | ------------------------------------------------------------------------- |
| admin | address | address for which ASSET\_LISTING\_ADMIN role permissions must be revoked. |
## Pool
* [Source Code](https://github.com/sparkdotfi/sparklend-v1-core/blob/master/contracts/protocol/pool/Pool.sol)
### Overview
The Pool contract is the core contract of the SparkLend Protocol, serving as the main entry point for all lending and borrowing operations. It manages the entire lifecycle of assets in the protocol, from supply and borrowing to liquidation and flash loans.
Key responsibilities include:
1. **Asset Management**
* Enables users to supply assets to the protocol and earn interest
* Manages the minting and burning of aTokens (interest-bearing tokens)
* Tracks total supply, borrow rates, and liquidity indexes for each asset
2. **Borrowing System**
* Allows users to borrow assets against supplied collateral
* Supports both stable and variable interest rate modes
* Implements health factor calculations to ensure protocol solvency
* Manages debt positions and interest accrual
3. **Collateral Management**
* Enables users to use supplied assets as collateral
* Implements Loan-to-Value (LTV) and liquidation threshold parameters
* Supports efficiency mode (E-mode) for optimized collateral usage
* Manages isolation mode for riskier assets
4. **Liquidation System**
* Allows liquidators to repay unhealthy positions
* Implements liquidation bonuses and protocol fees
* Manages the liquidation process to maintain protocol health
5. **Flash Loans**
* Enables uncollateralized flash loans
* Manages flash loan fees and premiums
* Supports both single-asset and multi-asset flash loans
The contract is designed to be upgradeable through a proxy pattern and is managed by the PoolAddressesProvider. It uses a modular architecture with separate logic libraries for different operations, making it maintainable and extensible.
### Architecture
The Pool contract uses a modular architecture with separate logic libraries for different operations:
* `SupplyLogic`: Handles supply and withdraw operations
* `BorrowLogic`: Manages borrow and repay operations
* `FlashLoanLogic`: Implements flash loan functionality
* `LiquidationLogic`: Handles liquidation of unhealthy positions
* `EModeLogic`: Manages efficiency mode operations
* `BridgeLogic`: Handles bridge operations
* `PoolLogic`: Contains general pool operations
### Access Control
The contract has three main access control modifiers:
* `onlyPoolConfigurator`: Functions that can only be called by the PoolConfigurator contract
* `onlyPoolAdmin`: Functions that can only be called by pool admins
* `onlyBridge`: Functions that can only be called by bridge contracts
### Constructor and Initialization
```solidity
constructor(IPoolAddressesProvider provider)
```
Initializes the Pool with the address of the PoolAddressesProvider contract.
```solidity
function initialize(IPoolAddressesProvider provider) external virtual initializer
```
Initializes the Pool when it's added to the PoolAddressesProvider. This function:
* Verifies the provider address
* Sets the maximum stable rate borrow size percent to 25%
### Core Operations
The Pool contract enables users to:
1. Supply assets to the protocol
2. Withdraw supplied assets
3. Borrow assets against supplied collateral
4. Repay borrowed assets
5. Swap between stable and variable rate loans
6. Enable/disable assets as collateral
7. Rebalance stable rate positions
8. Liquidate unhealthy positions
9. Execute flash loans
10. Use efficiency mode (E-mode) for optimized collateral usage
### Write Methods
#### supply
**`function supply(address asset, uint256 amount, address onBehalfOf, uint16 referralCode)`**
The `referralCode` is emitted in Supply event and can be for third party referral integrations. To activate referral feature and obtain a unique referral code, integrators need to submit proposal to Maker Governance.
:::warning
When supplying, the `Pool` contract must have `allowance()` to spend funds on behalf of `msg.sender` for at least `amount` of the `asset` being supplied. This can be done via the standard ERC20 `approve()` method on the underlying token contract.
:::
:::info
Referral supply is currently inactive, so you can pass `0` as `referralCode`. This program may be activated in the future through a Maker Governance proposal.
:::
| Param Name | Type | Description |
| ------------ | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- |
| asset | address | Address of the asset being supplied to the pool. |
| amount | uint256 | Amount of the asset being supplied. |
| onBehalfOf | address | Address that will receive the corresponding spTokens.
Only the `onBehalfOf` address will be able to withdraw the supplied asset from the pool. |
| referralCode | uint16 | Unique code for third-party referral program integration. Use `0` if no referral applies. |
#### supplyWithPermit
`function supplyWithPermit(address asset, uint256 amount, address onBehalfOf, uint16 referralCode, uint256 deadline, uint8 permitV, permitR, bytes32 permitS)`
Supply with transfer approval of supplied asset via permit function. This method removes the need for separate approval tx before supplying asset to the pool.
:::info
Permit signature must be signed by `msg.sender` with spender as Pool address.
:::
:::info
Referral program is currently inactive, so you can pass `0` as `referralCode`. This program may be activated in the future through a Maker Governance proposal.
:::
Call Params
| Name | Type | Description |
| ------------ | ------- | -------------------------------------------------------------------------------------------------------- |
| asset | address | Address of the underlying asset being supplied. Same asset as used in permit `s`, `v`, `r`. |
| amount | uint256 | Amount of the asset being supplied and approved via permit. Same amount as used in permit `s`, `v`, `r`. |
| onBehalfOf | address | Address that will receive the spTokens. |
| referralCode | uint16 | Unique code for third-party referral program integration.
Use `0` if no referral applies. |
| deadline | uint256 | Unix timestamp until which the signature is valid. |
| permitV | uint8 | Signature parameter v |
| permitR | bytes32 | Signature parameter r |
| permitS | bytes32 | Signature parameter s |
#### withdraw
**`function withdraw(address asset, uint256 amount, address to)`**
Withdraws `amount` of the underlying `asset`, i.e. redeems the underlying token and burns the spTokens.
If the user has any existing debt backed by the underlying token, the maximum *amount* available to withdraw is the amount that will not leave the user's health factor below 1 after withdrawal.
:::info
When withdrawing `to` another address, `msg.sender` should hold the `spToken` that will be burned by the `Pool`.
:::
Call Params
| Name | Type | Description |
| ------ | ------- | --------------------------------------------------------------------------------------------- |
| asset | address | address of the underlying asset, not the spToken |
| amount | uint256 | amount supplied, expressed in wei units. Use `type(uint).max` to withdraw the entire balance. |
| to | address | address that will receive the `asset` |
#### borrow
**`function borrow(address asset, uint256 amount, uint256 interestRateMode, uint16 referralCode, address onBehalfOf)`**
Borrows `amount` of `asset` with `interestRateMode`, sending the `amount` to `msg.sender`, with the debt being incurred by `onBehalfOf`.
:::info
Note: If `onBehalfOf` is not same as `msg.sender`, then `onBehalfOf` must have supplied enough collateral via `supply()` and have delegated credit to `msg.sender` via `approveDelegation()`.
:::
:::info
Referral program is currently inactive, so you can pass `0` as `referralCode`. This program may be activated in the future through a Maker Governance proposal.
:::
Call Params
| Name | Type | Description |
| ---------------- | ------- | -------------------------------------------------------------------------------------------------------------------- |
| asset | address | Address of the underlying asset. |
| amount | uint256 | Amount to borrow, expressed in wei units. |
| interestRateMode | uint256 | Type of borrow debt.
Stable: 1, Variable: 2 |
| referralCode | uint16 | Referral code for the referral program. Use `0` if no referral applies. |
| onBehalfOf | address | Address of the user who will incur the debt.
Use `msg.sender` if not borrowing on behalf of another user. |
#### repay
**`function repay(address asset, uint256 amount, uint256 rateMode, address onBehalfOf)`**
Repays `onBehalfOf`'s debt `amount` of `asset` which has a `rateMode`.
:::warning
When repaying, the `Pool` contract must have `allowance()` to spend funds on behalf of `msg.sender` for at least `amount` of the `asset` being repaid. This can be done via the standard ERC20 `approve()` method on the underlying token contract.
:::
:::info
Referral program is currently inactive, so you can pass `0` as `referralCode`. This program may be activated in the future through a Maker Governance proposal.
:::
Call Params
| Name | Type | Description |
| ---------- | ------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| asset | address | Address of the underlying asset. |
| amount | uint256 | Amount of the underlying asset being repaid. Use `uint(-1)` to repay the entire debt, but only when the repayment is not executed on behalf of a third party. When repaying on behalf of another user, it is recommended to send an *amount* slightly higher than the current borrowed amount. |
| rateMode | uint256 | Type of debt being repaid. Stable: 1, Variable: 2 |
| onBehalfOf | address | Address for which the debt is being repaid. Use `msg.sender` if not repaying on behalf of another user. |
#### repayWithPermit
`function repayWithPermit(address asset, uint256 amount, uint256 interestRateMode, address onBehalfOf, uint256 deadline, uint8 permitV, permitR, bytes32 permitS)`
Repay with transfer approval of borrowed asset via permit function. This method removes the need for separate approval tx before repaying asset to the pool.
:::info
Permit signature must be signed by `msg.sender` with spender value as `Pool` address.
:::
Call Params
| Name | Type | Description |
| ---------------- | ------- | ------------------------------------------------------------------------------------------------------ |
| asset | address | Address of the underlying asset being repaid. Same asset as used in permit `s`, `v`, `r`. |
| amount | uint256 | Amount of the asset being repaid and approved via permit. Same amount as used in permit `s`, `v`, `r`. |
| interestRateMode | uint256 | Type of debt being repaid. Stable: 1, Variable: 2 |
| onBehalfOf | address | Address for which the debt is being repaid. |
| deadline | uint256 | Unix timestamp until which the signature is valid. |
| permitV | uint8 | Signature parameter v |
| permitR | bytes32 | Signature parameter r |
| permitS | bytes32 | Signature parameter s |
#### repayWithSpTokens
`function repayWithSpTokens(address asset,uint256 amount,uint256 interestRateMode)`
Allows user to repay with *spTokens* of the underlying debt asset without any approvals eg. Pay DAI debt using aDAI tokens.
Call Params
| Param Name | Type | Description |
| ---------------- | ------- | ---------------------------------------------------------------------------------------------------------- |
| asset | address | Address of the underlying asset to be repaid. |
| amount | uint256 | Amount of the underlying asset being repaid. Use `uint256(-1)` to repay without leaving spToken dust. |
| interestRateMode | uint256 | Interest rate mode of the debt position. 1: stable 2: variable |
#### swapBorrowRateMode
**`function swapBorrowRateMode(address asset, uint256 rateMode)`**
Swaps `msg.sender`'s borrow rate mode between stable and variable.
Call Params
| Name | Type | Description |
| -------- | ------- | ---------------------------------------------------------- |
| asset | address | Address of the underlying asset. |
| rateMode | uint256 | Rate mode being switched from. Stable: 1, Variable: 2 |
#### rebalanceStableBorrowRate
`function rebalanceStableBorrowRate(address asset, address user)`
Rebalances stable borrow rate of the `user` for given `asset`. In case of liquidity crunches on the protocol, stable rate borrows might need to be rebalanced to bring back equilibrium between the borrow and supply rates.
Call Params
| Name | Type | Description |
| ----- | ------- | -------------------------------------------------------------------------------------------------- |
| asset | address | Address of the underlying token that has been borrowed for which the position is being rebalanced. |
| user | address | Address of the user being rebalanced. |
#### setUserUseReserveAsCollateral
**`function setUserUseReserveAsCollateral(address asset, bool useAsCollateral)`**
Sets the `asset` of `msg.sender` to be used as collateral or not.
:::info
An asset in [Isolation Mode](/dev/sparklend/features/isolation-mode) can be enabled to use as collateral only if no other asset is already enabled to use as collateral.
:::
:::info
User won't be able to disable an asset as collateral if they have an outstanding debt position which could be left with HF \< `HEALTH_FACTOR_LIQUIDATION_THRESHOLD` on disabling the given asset as collateral.
:::
Call Params
| Name | Type | Description |
| --------------- | ------- | -------------------------------------------------------- |
| asset | address | address of the underlying asset to be used as collateral |
| useAsCollateral | bool | true if the asset should be used as collateral |
#### liquidationCall
**`function liquidationCall(address collateral, address debt, address user, uint256 debtToCover, bool receiveSpToken)`**
Liquidate positions with a **health factor** below 1.
When the health factor of a position is below 1, liquidators repay part or all of the outstanding borrowed amount on behalf of the borrower, while **receiving a discounted amount of collateral** in return (also known as a liquidation 'bonus"). Liquidators can decide if they want to receive an equivalent amount of collateral *spTokens* instead of the underlying asset. When the liquidation is completed successfully, the health factor of the position is increased, bringing the health factor above 1.
Liquidators can only close a certain amount of collateral defined by a close factor. Currently the **close factor is 0.5**. In other words, liquidators can only liquidate a maximum of 50% of the amount pending to be repaid in a position. The liquidation discount applies to this amount.
:::info
Liquidators must \`approve()\` the \`Pool\` contract to use \`debtToCover\` of the underlying ERC20 of the\`asset\` used for the liquidation.
:::
**NOTES**
* *In most scenarios*, profitable liquidators will choose to liquidate as much as they can (50% of the `user` position).
* `debtToCover` parameter can be set to `uint(-1)` and the protocol will proceed with the highest possible liquidation allowed by the close factor.
* To check a user's health factor, use [`getUserAccountData()`.](#getuseraccountdata)
Call Params
| Name | Type | Description |
| -------------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------ |
| collateral | address | address of the collateral reserve |
| debt | address | address of the debt reserve |
| user | address | address of the borrower |
| debtToCover | uint256 | amount of asset debt that the liquidator will repay |
| receiveSpToken | bool | if true, the user receives the spTokens equivalent of the purchased collateral. If false, the user receives the underlying asset directly. |
#### flashLoan
`function flashLoan( address receiverAddress, address[] calldata assets, uint256[] calldata amounts, uint256[] interestRateModes, address onBehalfOf, bytes calldata params, uint16 referralCode)`
Allows users to access liquidity of the pool for given *list of assets for one transaction* as long as the amount taken plus fee is returned or debt position is opened by the end of transaction.
:::info
If no debt position is opened, receiver must approve the *Pool* contract for at least the *amount borrowed + fee*, else transaction will revert.
:::
:::info
Flash loan fee is waived for the approved *flashBorrowers*
:::
:::info
Referral program is currently inactive, so you can pass `0` as `referralCode`. This program may be activated in the future through a Maker Governance proposal.
:::
Call Params
| Name | Type | Description |
| --------------- | ---------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| receiverAddress | address | Address of the contract that will receive the flash-borrowed funds. Must implement the `IFlashLoanReceiver` interface. |
| assets | address\[] | Addresses of the underlying assets that will be flash borrowed. |
| amounts | uint256\[] | Amounts of assets requested for the flash loan. Must contain the same number of entries as `assets`. |
| modes | uint256\[] | Types of debt positions to open if the flash loan is not returned. 0: no debt is opened, so `amount + fee` must be paid or the call reverts. 1: stable mode debt 2: variable mode debt |
| onBehalfOf | address | If the associated mode is not `0`, the incurred debt will be assigned to the `onBehalfOf` address. Note: `onBehalfOf` must already have approved sufficient borrow allowance for the associated asset to `msg.sender`. |
| params | bytes | Arbitrary bytes-encoded parameters passed to the receiver contract's `executeOperation()` method. |
| referralCode | uint16 | Referral code used for third-party integrations. A unique referral ID can be requested through governance. |
#### flashLoanSimple
`function flashLoanSimple( address receiverAddress, address asset, uint256 amount, bytes calldata params, uint16 referralCode)`
Allows users to access liquidity of *one reserve or one transaction* as long as the amount taken plus fee is returned.
:::info
Receiver must approve the *Pool* contract for at least the *amount borrowed + fee,* else transaction will revert.
:::
:::info
Does not waive the fee for approved *flashBorrowers* or allow opening a debt position instead of repaying.
:::
:::info
Referral program is currently inactive, so you can pass `0` as `referralCode`. This program may be activated in the future through a Maker Governance proposal.
:::
Call Params
| Name | Type | Description |
| --------------- | ------- | --------------------------------------------------------------------------------------------------------------------------- |
| receiverAddress | address | Address of the contract that will receive the flash-borrowed funds. Must implement the `IFlashLoanReceiver` interface. |
| asset | address | Address of the underlying asset that will be flash borrowed. |
| amount | uint256 | Amount of the asset requested for the flash loan. |
| params | bytes | Arbitrary bytes-encoded parameters passed to the receiver contract's `executeOperation()` method. |
| referralCode | uint16 | Referral code used for third-party integrations. A unique referral ID can be requested through governance. |
#### mintToTreasury
`function mintToTreasury(address[] calldata assets)`
Mints reserve income accrued to treasury (as per the reserve factor) for the given list of assets.
Call Params
| Name | Type | Description |
| ------ | ---------- | ------------------------------------------------- |
| assets | address\[] | List of assets for which accrued income is minted |
#### setUserEMode
`function setUserEMode(uint8 categoryId)`
Updates the user efficiency mode category. The category id must be a valid id already defined by *Pool or Risk Admins*
:::info
Will revert if user is borrowing non-compatible asset or change will drop HF \< `HEALTH_FACTOR_LIQUIDATION_THRESHOLD`
:::
Call Params
| Name | Type | Description |
| ---------- | ----- | ------------------------------------------------------------------------------------------------------------- |
| categoryId | uint8 | eMode category id (0 - 255) defined by Risk or Pool Admins. `categoryId == 0` means non E-mode category. |
#### mintUnbacked
`mintUnbacked (asset, amount, onBehalfOf, referralCode)`
Allows contracts, with `BRIDGE` role permission, to mint unbacked *spTokens* to the `onBehalfOf` address.
:::info
Only available to the addresses with`BRIDGE`role. Bridge addresses can be whitelisted by the governance.
:::
| Param | Type | Description |
| ------------ | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| asset | address | address of the underlying asset token |
| amount | uint256 | the amount to be minted |
| onBehalfOf | address | the address which will receive the spTokens |
| referralCode | uint16 | Code used to register the integrator originating the operation, for potential rewards.
0 if the action is executed directly by the user, without any middle-man. |
#### backUnbacked
`backUnbacked (asset, amount, fee)`
Allows contracts, with `BRIDGE` role permission, to back the currently unbacked spTokens with `amount` of underlying asset and pay `fee`.
:::info
Only available to the addresses with`BRIDGE`role. Bridge addresses can be whitelisted by the governance.
:::
| Param | Type | Description |
| ------ | ------- | ---------------------------------------------------- |
| asset | address | address of the underlying asset to repay |
| amount | uint256 | amount of asset supplied to back the unbacked tokens |
| fee | uint256 | amount paid in fee |
#### rescueTokens
`function rescueTokens(address token, address to, uint256 amount)`
Rescue and transfer tokens locked in this contract`.`
:::danger
Only available to`POOL_ADMIN`role. Pool admin is selected by the governance.
:::
#### deposit
`function deposit(address asset, uint256 amount, address onBehalfOf, uint16 referralCode)`
:::warning
This method is deprecated and maintained for compatibility purposes. Use `supply()` instead.
:::
Alias for `supply()`. See supply documentation for details.
#### finalizeTransfer
`function finalizeTransfer(address asset, address from, address to, uint256 amount, uint256 balanceFromBefore, uint256 balanceToBefore)`
Internal function called by aTokens to finalize transfers. This function should not be called directly.
:::danger
This function can only be called by the aToken contract of the specified asset.
:::
### View Methods
#### getReserveData
**`function getReserveData(address asset)`**
Returns the state and configuration of the reserve.
Call Params
| Name | Type | Description |
| ----- | ------- | ---------------------------------------- |
| asset | address | address of the underlying reserve asset. |
Return Values
| Name | Type | Description |
| --------------------------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| configuration | uint256 | Reserve configuration. bit 0-15: LTV bit 16-31: Liquidation threshold bit 32-47: Liquidation bonus bit 48-55: Decimals bit 56: reserve is active bit 57: reserve is frozen bit 58: borrowing is enabled bit 59: stable rate borrowing enabled bit 60: asset is paused bit 61: borrowing in isolation mode is enabled bit 62-63: reserved bit 64-79: reserve factor bit 80-115: borrow cap in whole tokens, 0 means no cap bit 116-151: supply cap in whole tokens, 0 means no cap bit 152-167: liquidation protocol fee bit 168-175: eMode category bit 176-211: unbacked mint cap in whole tokens, 0 means no cap bit 212-251: debt ceiling for isolation mode with decimals bit 252-255: unused |
| liquidityIndex | uint128 | yield generated by reserve during time interval since lastUpdatedTimestamp. Expressed in ray |
| currentLiquidityRate | uint128 | current supply rate. Expressed in ray (1e27) |
| variableBorrowIndex | uint128 | yield accrued by reserve during time interval since lastUpdatedTimestamp. Expressed in ray |
| currentVariableBorrowRate | uint128 | current variable borrow rate. Expressed in ray (1e27) |
| currentStableBorrowRate | uint128 | current stable borrow rate. Expressed in ray (1e27) |
| lastUpdateTimestamp | uint40 | timestamp of when reserve data was last updated. Used for yield calculation. |
| id | uint16 | reserve's position in the list of active reserves. |
| aTokenAddress | address | address of associated aToken |
| stableDebtTokenAddress | address | address of associated stable debt token |
| variableDebtTokenAddress | address | address of associated variable debt token |
| interestRateStrategyAddress | address | address of interest rate strategy. |
| accruedToTreasury | uint128 | the current treasury balance (scaled) |
| unbacked | uint128 | the outstanding unbacked aTokens minted through the bridging feature |
| isolationModeTotalDebt | uint128 | the outstanding debt borrowed against this asset in isolation mode |
#### getUserAccountData
**`function getUserAccountData(address user)`**
Returns the user account data across all the reserves. All values are expressed in the market's base currency.
Call params
| Name | Type | Description |
| ---- | ------- | ------------------- |
| user | address | address of the user |
Return Values
| Name | Type | Description |
| --------------------------- | ------- | ----------------------------------------------------------- |
| totalCollateralBase | uint256 | total collateral of the user, in market's base currency |
| totalDebtBase | uint256 | total debt of the user, in market's base currency |
| availableBorrowsBase | uint256 | borrowing power left of the user, in market's base currency |
| currentLiquidationThreshold | uint256 | liquidation threshold of the user |
| ltv | uint256 | Loan To Value of the user |
| healthFactor | uint256 | current health factor of the user |
#### getConfiguration
**`function getConfiguration(address asset)`**
Returns the configuration of the reserve.
Call Params
| Name | Type | Description |
| ----- | ------- | ---------------------------------------- |
| asset | address | address of the underlying reserve asset. |
Return Values
| Name | Type | Description |
| ------------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| configuration | uint256 | Reserve configuration. bit 0-15: LTV bit 16-31: Liquidation threshold bit 32-47: Liquidation bonus bit 48-55: Decimals bit 56: reserve is active bit 57: reserve is frozen bit 58: borrowing is enabled bit 59: stable rate borrowing enabled bit 60: asset is paused bit 61: borrowing in isolation mode is enabled bit 62-63: reserved bit 64-79: reserve factor bit 80-115: borrow cap in whole tokens, 0 means no cap bit 116-151: supply cap in whole tokens, 0 means no cap bit 152-167: liquidation protocol fee bit 168-175: eMode category bit 176-211: unbacked mint cap in whole tokens, 0 means no cap bit 212-251: debt ceiling for isolation mode with decimals bit 252-255: unused |
#### getUserConfiguration
**`function getUserConfiguration(address user)`**
Returns the configuration of the user across all the reserves.
Call Params
| Name | Type | Description |
| ---- | ------- | ------------------- |
| user | address | address of the user |
Return Values
| Type | Description |
| ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| uint256 | Bitmap of the user's collaterals and borrows. It is divided into pairs of bits, one pair for each asset. The first bit of the pair indicates if it is being used as collateral by the user, and the second bit indicates if it is being borrowed. The corresponding assets are in the same position as `getReservesList()`. For example, if the hex value returned is `0x40020`, which represents a decimal value of `262176`, then in binary it is `1000000000000100000`. If we format the binary value into pairs, starting from the right, we get `1 00 00 00 00 00 00 10 00 00`. If we start from the right and move left in the above binary pairs, the third pair is `10`. Therefore, the `1` indicates that the third asset from the reserve list is used as collateral, and the `0` indicates it has not been borrowed by this user. |
#### getReserveNormalizedIncome
`function getReserveNormalizedIncome(address asset)`
Returns the ongoing normalized income for the reserve. A value of 1e27 means there is no income. As time passes, the yield is accrued. A value of 2\*1e27 means for each unit of asset one unit of income has been accrued.
Return Value
| Type | Description |
| ------- | ------------------------------------------ |
| uint256 | Normalized income, expressed in ray (1e27) |
#### getReserveNormalizedDebt
`function getReserveNormalizedVariableDebt(address asset)`
Returns the ongoing normalized variable debt for the reserve. A value of 1e27 means there is no debt. As time passes, the debt is accrued. A value of 2\*1e27 means that for each unit of debt, one unit worth of interest has been accumulated.
Return Value
| Type | Description |
| ------- | ---------------------------------------- |
| uint256 | Normalized debt, expressed in ray (1e27) |
#### getReservesList
`function getReservesList()`
Returns the list of initialized reserves.
#### getEModeCategoryData
`function getEModeCategoryData(uint8 id)`
Returns category data for the given eModeCategory id.
Return Values
| Type | Description |
| ------- | --------------------------------------------------- |
| uint16 | loan to value (ltv) for the given eModeCategory id |
| uint16 | liquidationThreshold for the given eModeCategory id |
| uint16 | liquidationBonus for the given eModeCategory id |
| address | custom price source for the eMode category |
| string | custom label describing the eMode category |
#### getUserEMode
`function getUserEMode(address user)`
Returns eModeCategory Id of the user's eMode. 0 ⇒ no eMode.
#### FLASHLOAN\_PREMIUM\_TOTAL
`function FLASHLOAN_PREMIUM_TOTAL() public view returns (uint128)`
Returns the percent of total flashloan premium paid by the borrower.\
A part of this premium is added to reserve's liquidity index i.e. paid to the liquidity provider and the other part is paid to the protocol i.e. accrued to the treasury.
#### FLASHLOAN\_PREMIUM\_TO\_PROTOCOL
`function FLASHLOAN_PREMIUM_TO_PROTOCOL() public view returns (uint128)`
Returns the percent of flashloan premium that is accrued to the treasury.
### Error Codes
Common error codes and their meanings:
* `CALLER_NOT_POOL_CONFIGURATOR`: Only PoolConfigurator can call this function
* `CALLER_NOT_POOL_ADMIN`: Only PoolAdmin can call this function
* `CALLER_NOT_BRIDGE`: Only Bridge can call this function
* `INVALID_ADDRESSES_PROVIDER`: Invalid PoolAddressesProvider address
* `ASSET_NOT_LISTED`: Asset is not listed in the protocol
* `HEALTH_FACTOR_LOWER_THAN_LIQUIDATION_THRESHOLD`: Operation would result in health factor below liquidation threshold
* `COLLATERAL_CANNOT_COVER_NEW_BORROW`: Not enough collateral to cover new borrow
* `COLLATERAL_SAME_AS_BORROWING_CURRENCY`: Cannot use same asset as collateral and borrowing
* `AMOUNT_BIGGER_THAN_MAX_LOAN_SIZE_STABLE`: Amount exceeds max stable rate loan size
* `NO_DEBT_OF_SELECTED_TYPE`: No debt of selected type to repay
* `NO_EXPLICIT_AMOUNT_TO_REPAY_ON_BEHALF`: No explicit amount to repay on behalf
* `NO_MORE_RESERVES_ALLOWED`: Maximum number of reserves reached
* `ZERO_ADDRESS_NOT_VALID`: Zero address not valid
* `EMODE_CATEGORY_RESERVED`: E-mode category 0 is reserved
* `CALLER_NOT_ATOKEN`: Only aToken can call this function
:::info
The contract uses aTokens (not spTokens) as the representation of supplied assets. Each supplied asset has a corresponding aToken that accrues interest.
:::
## PoolAddressesProvider
* [Source Code](https://github.com/sparkdotfi/sparklend-v1-core/blob/master/contracts/protocol/configuration/PoolAddressesProvider.sol)
### Overview
The PoolAddressesProvider is a central registry contract that serves as the single source of truth for all protocol contract addresses and configurations. It plays several critical roles in the SparkLend Protocol:
1. **Address Registry**
* Maintains a mapping of all protocol contract addresses
* Stores addresses for core components like Pool, PoolConfigurator, Price Oracle, and ACL Manager
* Provides a standardized way to fetch contract addresses across the protocol
2. **Proxy Factory & Admin**
* Acts as a factory for creating proxy contracts
* Manages proxy implementations for upgradeable contracts
* Handles proxy upgrades through implementation updates
* Initializes new proxy contracts with their implementations
3. **Market Configuration**
* Stores the market identifier for the protocol
* Manages market-specific configurations
* Allows for market parameter updates through governance
4. **Access Control**
* Owned by Aave Governance on Ethereum mainnet
* On other networks, owned by either Crosschain Governance Bridges or Community Multisigs
* Controls who can update protocol addresses and configurations
The contract is designed to be immutable (except for the owner) and serves as the foundation for the protocol's upgradeability and configuration management. It's the recommended way to fetch any protocol contract address, ensuring that integrations always use the latest deployed versions.
This contract inherits from OpenZeppelin's `Ownable` and implements `IPoolAddressesProvider`. It acts as a factory of proxies and admin of those, with the right to change their implementations.
:::info
Whenever the `Pool` contract is needed, we recommended you fetch the correct address from the `PoolAddressesProvider` smart contract.
:::
#### Constructor
```solidity
constructor(string memory marketId, address owner)
```
Initializes the PoolAddressesProvider with:
* `marketId`: The identifier of the market
* `owner`: The address that will own the contract
#### Contract Identifiers
The contract uses the following constant identifiers to store addresses:
* `POOL`: The main Pool contract
* `POOL_CONFIGURATOR`: The PoolConfigurator contract
* `PRICE_ORACLE`: The Price Oracle contract
* `ACL_MANAGER`: The ACL Manager contract
* `ACL_ADMIN`: The ACL Admin address
* `PRICE_ORACLE_SENTINEL`: The Price Oracle Sentinel contract
* `DATA_PROVIDER`: The Pool Data Provider contract
#### Events
The contract emits the following events:
* `AddressSet(bytes32 indexed id, address indexed oldAddress, address indexed newAddress)`: Emitted when an address is set
* `AddressSetAsProxy(bytes32 indexed id, address indexed proxyAddress, address indexed oldImplementationAddress, address newImplementationAddress)`: Emitted when a proxy implementation is updated
* `PoolUpdated(address indexed oldAddress, address indexed newAddress)`: Emitted when the Pool implementation is updated
* `PoolConfiguratorUpdated(address indexed oldAddress, address indexed newAddress)`: Emitted when the PoolConfigurator implementation is updated
* `PriceOracleUpdated(address indexed oldAddress, address indexed newAddress)`: Emitted when the Price Oracle is updated
* `ACLManagerUpdated(address indexed oldAddress, address indexed newAddress)`: Emitted when the ACL Manager is updated
* `ACLAdminUpdated(address indexed oldAddress, address indexed newAddress)`: Emitted when the ACL Admin is updated
* `PriceOracleSentinelUpdated(address indexed oldAddress, address indexed newAddress)`: Emitted when the Price Oracle Sentinel is updated
* `PoolDataProviderUpdated(address indexed oldAddress, address indexed newAddress)`: Emitted when the Pool Data Provider is updated
* `MarketIdSet(string indexed oldMarketId, string indexed newMarketId)`: Emitted when the market ID is updated
* `ProxyCreated(bytes32 indexed id, address indexed proxyAddress, address indexed implementationAddress)`: Emitted when a new proxy is created
### View Methods
#### getMarketId
`function getMarketId() external view override returns (string memory)`
Fetch the market id of the associated Spark market.
Return Values
| Type | Description |
| ------ | ------------------------------------- |
| string | A string representation of the market |
#### getAddress
`function getAddress(bytes32 id) public view override returns (address)`
Fetch the address of protocol contract stored at given id.
Call Params
| Name | Type | Description |
| ---- | ------- | --------------------------------------------------- |
| id | bytes32 | id. Example, the Protocol Data Provider uses id 0x1 |
Return Values
| Type | Description |
| ------- | ------------------------------------------------- |
| address | The address associated with the bytes32 id passed |
```tsx
// Get address of incentive controller
import { utils } from '@ethers/lib/utils';
const id = utils.keccak256(utils.toUtf8Bytes("INCENTIVES_CONTROLLER"));
const address = poolAddressProvider.getAddress(id);
```
#### getPool
`function getPool() external view override returns (address)`
Fetch the contract of latest pool
Return Values
| Type | Description |
| ------- | ---------------------------------- |
| address | The address of the associated Pool |
#### getPoolConfigurator
`function getPoolConfigurator() external view override returns (address)`
Fetch the `PoolConfigurator` is used for configuration methods, like init reserves or update token implementation etc, of the market.
Return Value
| Type | Description |
| ------- | --------------------------------------------------- |
| address | The address of associated market's PoolConfigurator |
#### getPriceOracle
`function getPriceOracle() external view override returns (address)`
Fetch Price Oracle used by the market.
Return Value
| Type | Description |
| ------- | ---------------------------------------------------------- |
| address | The address of the price oracle used by associated market. |
#### getACLManager
`function getACLManager() external view override returns (address)`
Fetch ACLManger that manages the system role of the market
Return Value
| Type | Description |
| ------- | ---------------------------------------------------------------------------------------- |
| address | The address of the ACLManger contract managing the system role of the associated market. |
#### getACLAdmin
`function getACLAdmin() external view override returns (address)`
Fetch ACLAdmin of the market which holds the `DEFAULT_ADMIN_ROLE` in ACLManager.
Return Value
| Type | Description |
| ------- | ---------------------------------------------------------------------- |
| address | The address of the access control list admin of the associated market. |
#### getPriceOracleSentinel
`function getPriceOracleSentinel() external view override returns (address)`
Return Value
| Type | Description |
| ------- | ------------------------------------------------------------------ |
| address | The address of the Price oracle sentinel of the associated market. |
#### getPoolDataProvider
`function getPoolDataProvider() external view override returns (address)` Fetch address of latest pool data provider.
Return Value
| Type | Description |
| ------- | --------------------------------------------------------------- |
| address | The address of the pool data provider of the associated market. |
### Write Methods
#### setMarketId
`function setMarketId(string memory newMarketId) external override onlyOwner`
Updates the identifier of the Spark market
Call Params
| Name | Type | Description |
| ----------- | -------- | ------------------------ |
| newMarketId | `string` | The new id of the market |
#### setAddress
`function setAddress(bytes32 id, address newAddress) external override onlyOwner`
Sets the address of protocol contract stored at given id.
Eg. `utils.keccak256(utils.toUtf8Bytes("INCENTIVES_CONTROLLER"))` is set to address of `INCENTIVES_CONTROLLER`
Call Params
| Name | Type | Description |
| ---------- | --------- | -------------------------------------------------------- |
| id | `bytes32` | keccak256 hash of UTF8Bytes string representing Contract |
| newAddress | `address` | The new address to be set corresponding to the `id` |
#### setAddressAsProxy
`function setAddressAsProxy(bytes32 id, address newImplementationAddress) external override onlyOwner`
Sets/updates the implementation address of a specific proxied protocol contract. If there is no proxy registered with the given identifier, it creates a new proxy with `newImplementationAddress` as implementation and calls its `initialize()` function. If a proxy already exists, it updates the implementation and calls `initialize()` via `upgradeToAndCall()`.
:::info
This function creates a new `InitializableImmutableAdminUpgradeabilityProxy` if one doesn't exist for the given id.
:::
Call Params
| Name | Type | Description |
| ------------------------ | --------- | --------------------------------------------------------------------- |
| id | `bytes32` | id of Proxy contract |
| newImplementationAddress | `address` | The address of new implementation contract corresponding to the proxy |
#### setPoolImpl
`function setPoolImpl(address newPoolImpl) external override onlyOwner`
Sets/update the implementation of the POOL proxy contract.
Call Params
| Name | Type | Description |
| ----------- | --------- | ----------------------------------------------- |
| newPoolImpl | `address` | The address of new Pool implementation contract |
#### setPoolConfiguratorImp
`function setPoolConfiguratorImpl(address newPoolConfiguratorImpl) external override onlyOwner`
Sets/updates the implementation of the POOL\_CONFIGURATOR proxy contract.
Call Params
| Name | Type | Description |
| ----------------------- | --------- | ----------------------------------------------------------- |
| newPoolConfiguratorImpl | `address` | The address of new PoolConfigurator implementation contract |
#### setPriceOracle
`function setPriceOracle(address newPriceOracle) external override onlyOwner`
Sets/updates address of the PriceOracle contract.
Call Params
| Name | Type | Description |
| -------------- | --------- | --------------------------------------- |
| newPriceOracle | `address` | The address of new PriceOracle contract |
#### setACLAdmin
`function setACLAdmin(address newAclAdmin) external override onlyOwner`
Sets/updates address of the AclAdmin.
Call Params
| Name | Type | Description |
| ----------- | --------- | ---------------------------- |
| newAclAdmin | `address` | The address of new AclAdming |
#### setPriceOracleSentinel
`function setPriceOracleSentinel(address newPriceOracleSentinel) external override onlyOwner`
Sets/updates address of the Price oracle sentinel.
Call Params
| Name | Type | Description |
| ---------------------- | --------- | -------------------------------------- |
| newPriceOracleSentinel | `address` | The address of new PriceOracleSentinel |
#### setPoolDataProvider
`function setPoolDataProvider(address newDataProvider) external override onlyOwner`
Sets/updates address of PoolDataProvider.
Call Params
| Name | Type | Description |
| --------------- | --------- | ----------------------------------- |
| newDataProvider | `address` | The address of new PoolDataProvider |
## PoolAddressesProviderRegistry
* [Source Code](https://github.com/sparkdotfi/sparklend-v1-core/blob/master/contracts/protocol/configuration/PoolAddressesProviderRegistry.sol)
A register of the active [PoolAddressesProvider](/dev/sparklend/core-contracts/pooladdressesprovider) contracts, covering all markets. This contract is immutable and the address will never change.
For example, the Pool address for the main market is different from the Pool address for the AMM market.
### View Methods
#### getAddressesProviderList
`function getAddressesProvidersList()`
Returns a list of active [`PoolAddressesProvider`](/dev/sparklend/core-contracts/pooladdressesprovider) contracts for the registered SparkLend markets.
Returns Values
| Type | Description |
| ---------- | ------------------------------------ |
| address\[] | List of active PoolAddressesProvider |
#### getAddressesProviderIdByAddress
`function getAddressesProviderIdByAddress(address addressesProvider)`
Returns Id of `PoolAddressesProvider` .
Call Params
| Name | Type | Description |
| ----------------- | ------- | ------------------------------------ |
| addressesProvider | address | Address of the PoolAddressesProvider |
Return Values
| Type | Description |
| ------- | ------------------------------------------------------------------------------------------------- |
| uint256 | Id of the associated PoolAddressesProvider. 0 indicates not a valid PoolAddressesProvider address |
## PoolConfigurator
* [Source Code](https://github.com/sparkdotfi/sparklend-v1-core/blob/master/contracts/protocol/pool/PoolConfigurator.sol)
### Methods
#### Risk or Pool Admins
#### setSiloedBorrowing
`function setSiloedBorrowing(address asset, bool newSiloed) external`
Call Params
| Name | Type | Description |
| --------- | --------- | ------------------------------------------------ |
| asset | `address` | address of reserve's underlying asset. |
| newSiloed | `bool` | Enable/Disable SIloed Borrowing for the reserve. |
* enableBorrowingOnReserve
* disableBorrowingOnReserve
* configureReserveAsCollateral
* enableReserveStableRate
* disableReserveStableRate
* freezeReserve
* unfreezeReserve
* setBorrowableInIsolation
* setReserveFactor
* setDebtCeiling
* setSiloedBorrowing
* setBorrowCap
Allows `RISK_ADMIN` and `POOL_ADMIN` to add/update cap on the total borrow that can be borrowed from the reserve. Once the borrow cap is reached, no more borrow (variable or stable) for the given reserve asset can be initiated.
| Param Name | Type | Description |
| ------------ | ------- | ------------------------------------------------------ |
| asset | address | Address of the underlying asset. |
| newBorrowCap | uint256 | Borrow cap in whole tokens. `borrowCap == 0` => no cap |
* setSupplyCap
Allows `RISK_ADMIN` and `POOL_ADMIN` to add/update liquidity supply cap on the reserve. Once the supply cap is reached, no more liquidity for the given reserve asset can be supplied to the pool.
| Param Name | Type | Description |
| ------------ | ------- | ------------------------------------------------------ |
| asset | address | Address of the underlying asset. |
| newSupplyCap | uint256 | Supply cap in whole tokens. `supplyCap == 0` => no cap |
* setLiquidationProtocolFee
* setEModeCategory
Allows `RISK_ADMIN` and `POOL_ADMINS` to configure existing or add new `eModeCategory`
| Param | Type | Description |
| -------------------- | ------- | --------------------------------------------------------------------------------- |
| categoryId | uint8 | Category id ≠ 0. NOTE: category 0 is reserved for default category i.e. non-eMode |
| ltv | uint16 | Loan to value for given eMode categoryId. Must be ≤ liquidationThreshold |
| liquidationThreshold | uint16 | Liquidation threshold for given eMode categoryId. |
| liquidationBonus | uint16 | Liquidation bonus for given eMode categoryId |
| oracle | address | Address of custom price oracle for category |
| label | string | Custom label for the category |
* setAssetEModeCategory
Allows `RISK_ADMIN` and `POOL_ADMINS` to configure `eModeCategory` of an asset.
| Param Name | Type | Description |
| ---------- | ------- | ----------------------------------------------------------------------------------- |
| asset | address | Address of the reserve asset being configured |
| categoryId | uint8 | ≠ 0 one of the already defined eModeCategory = 0 for default aka non-eMode category |
* setUnbackedMintCap
* setReserveInterestRateStrategyAddress
#### Asset Listing or Pool Admins
* initReserves
#### Only Pool Admin
* dropReserve
* updateSpToken
* updateStableDebtToken
* updateVariableDebtToken
* activateReserve
* deactivateReserve
* updateBridgeProtocolFee
* updateFlashloanPremiumTotal
* updateFlashloanPremiumToProtocol
## PriceOracleSentinel
* [Source Code](https://github.com/sparkdotfi/sparklend-v1-core/blob/master/contracts/protocol/configuration/PriceOracleSentinel.sol)
This contract validates if the operations are allowed depending on the PriceOracle health.
The `PriceOracle` is considered healthy once its completely up and the grace period has passed.
### View Methods
#### isBorrowAllowed
`function isBorrowAllowed()`
Return Value
| Type | Description |
| ---- | ------------------------------------------------------------- |
| bool | Returns true if PriceOracle is up and grace period has passed |
#### isLiquidationAllowed
`function isLiquidationAllowed()`
Return Value
| Type | Description |
| ---- | ------------------------------------------------------------- |
| bool | Returns true if PriceOracle is up and grace period has passed |
#### getSequencerOracle
`function getSequencerOracle()`
Return Value
| Type | Description |
| ------- | ------------------------------- |
| address | Address of the SequencerOracle. |
#### getGracePeriod
`function getGracePeriod()`
Return Value
| Type | Description |
| ------- | -------------------------------------------- |
| uint256 | The duration of the grace period in seconds. |
### Write Methods
#### setSequencerOracle
`function setSequencerOracle(address newSequencerOracle)`
:::warning
Can be called only by PoolAdmin.
:::
Call Params
| Name | Type | Description |
| ------------------ | ------- | -------------------------------------------- |
| newSequencerOracle | address | address of the new SequecerOracle to be set. |
#### setGracePeriod
`function setGracePeriod(uint256 newGracePeriod`
:::warning
Can be called only by PoolAdmin or RiskAdmin.
:::
Call Params
| Name | Type | Description |
| -------------- | ------- | ---------------------------------------- |
| newGracePeriod | uint256 | duration of new grace period in seconds. |
## Spark ALM Controller
### Overview
**Source code:** [Github Repository](https://github.com/sparkdotfi/spark-alm-controller)
The Spark ALM Controller contains the onchain components of the Spark Liquidity Layer:
* `ALMProxy`: The proxy contract that holds custody of all funds. This contract routes calls to external contracts according to logic within a specified `controller` contract. This pattern was used to allow for future iterations in logic, as a new controller can be onboarded and can route calls through the proxy with new logic. This contract is stateless except for the ACL logic contained within the inherited OpenZeppelin `AccessControl` contract.
* `ForeignController`: This controller contract is intended to be used on "foreign" domains. The term "foreign" is used to describe a domain that is not the Ethereum mainnet.
* `MainnetController`: This controller contract is intended to be used on the Ethereum mainnet.
* `RateLimits`: This contract is used to enforce and update rate limits on logic in the `ForeignController` and `MainnetController` contracts. This contract is stateful and is used to store the rate limit data.
### Architecture
The general structure of calls is shown in the diagram below. The `controller` contract is the entry point for all calls. The `controller` contract checks the rate limits if necessary and executes the relevant logic. The `controller` can perform multiple calls to the `ALMProxy` contract atomically with specified calldata.
The diagram below provides and example of calling to mint USDS using the Sky allocation system. Note that the funds are always held custody in the `ALMProxy` as a result of the calls made.
### Permissions
All contracts in this repo inherit and implement the AccessControl contract from OpenZeppelin to manage permissions. The following roles are defined:
* `DEFAULT_ADMIN_ROLE`: The admin role is the role that can grant and revoke roles. Also used for general admin functions in all contracts.
* `RELAYER`: Used for the ALM Planner offchain system. This address can call functions on `controller` contracts to perform actions on behalf of the `ALMProxy` contract.
* `FREEZER`: Allows an address with this role to freeze all actions on the `controller` contracts. This role is intended to be used in emergency situations.
* `CONTROLLER`: Used for the `ALMProxy` contract. Only contracts with this role can call the `call` functions on the `ALMProxy` contract. Also used in the RateLimits contract, only this role can update rate limits.
### Controller Functionality
All functions below change the balance of funds in the ALMProxy contract and are only callable by the `RELAYER` role.
* `ForeignController`: This contract currently implements logic to:
* Deposit and withdraw on EVM compliant L2 PSM3 contracts (see [spark-psm](https://github.com/sparkdotfi/spark-psm) for implementation).
* Initiate a transfer of USDC to other domains using CCTP.
* Deposit, withdraw, and redeem from ERC4626 contracts.
* Deposit and withdraw from AAVE.
* `MainnetController`: This contract currently implements logic to:
* Mint and burn USDS.
* Deposit, withdraw, redeem from ERC4626 contracts.
* Deposit and withdraw from AAVE.
* Mint and burn USDe.
* Cooldown and unstake from sUSDe.
* Swap USDS to USDC and vice versa using the mainnet PSM.
* Transfer USDC to other domains using CCTP.
### Rate Limits
The `RateLimits` contract is used to enforce rate limits on the `controller` contracts. The rate limits are defined using `keccak256` hashes to identify which function to apply the rate limit to. This was done to allow flexibility in future function signatures for the same desired high-level functionality. The rate limits are stored in a mapping with the `keccak256` hash as the key and a struct containing the rate limit data:
* `maxAmount`: Maximum allowed amount at any time.
* `slope`: The slope of the rate limit, used to calculate the new limit based on time passed. \[tokens / second]
* `lastAmount`: The amount left available at the last update.
* `lastUpdated`: The timestamp when the rate limit was last updated.
The rate limit is calculated as follows:
`currentRateLimit = min(slope * (block.timestamp - lastUpdated) + lastAmount, maxAmount)`
This is a linear rate limit that increases over time with a maximum limit. This rate limit is derived from these values which can be set by and admin OR updated by the `CONTROLLER` role. The `CONTROLLER` updates these values to increase/decrease the rate limit based on the functionality within the contract (e.g., decrease the rate limit after minting USDS by the minted amount by decrementing `lastAmount` and setting `lastUpdated` to `block.timestamp`).
### Trust Assumptions and Attack Mitigation
Below are all stated trust assumptions for using this contract in production:
* The `DEFAULT_ADMIN_ROLE` is fully trusted, to be run by governance.
* The `RELAYER` role is assumed to be able to be fully compromised by a malicious actor. **This should be a major consideration during auditing engagements.**
* The logic in the smart contracts must prevent the movement of value anywhere outside of the ALM system of contracts.
* Any action must be limited to "reasonable" slippage/losses/opportunity cost by rate limits.
* The `FREEZER` must be able to stop the compromised `RELAYER` from performing more harmful actions within the max rate limits by using the `freeze()` function.
* A compromised `RELAYER` can DOS Ethena unstaking, but this can be mitigated by freezing the Controller and reassigning the `RELAYER`. This is outlined in a test `test_compromisedRelayer_lockingFundsInEthenaSilo`.
* Ethena USDe Mint/Burn is trusted to not honor requests with over 50bps slippage from a delegated signer.
### Operational Requirements
* All ERC-4626 vaults that are onboarded MUST have an initial burned shares amount that prevents rounding-based frontrunning attacks. These shares have to be unrecoverable so that they cannot be removed at a later date.
* All ERC-20 tokens are to be non-rebasing with sufficiently high decimal precision.
* Rate limits must be configured for specific ERC-4626 vaults and AAVE aTokens (vaults without rate limits set will revert). Unlimited rate limits can be used as an onboarding tool.
* Rate limits must take into account:
* Risk tolerance for a given protocol
* Griefing attacks (e.g., repetitive transactions with high slippage by malicious relayer).
## Bug Bounty Program
Spark has an active bug bounty program managed by Immunefi with bounty rewards of up to $5,000,000. Please submit any bugs or potential issues through the Immunefi plartform. Learn more about the bug bounty program below:
* [Immunefi SparkLend Bug Bounty Program](https://immunefi.com/bug-bounty/sparklend/information/)
## Security Audits
### SparkLend
SparkLend is based on the Aave v3 codebase, including the 3.0.1 and 3.0.2 upgrades, which have been extensively audited. [You can find the audits of Aave v3 here.](https://aave.com/security)
Notable code differences include:
* The DAI market has a custom interest rate strategy due to its relation with Sky.
* A custom oracle had to be made for the Savings DAI market.
* The `RewardsController` was not set up through the `PoolAddressProvider`.
#### SparkLend Core Updates
Spark-specific core audits covering changes made on top of the base Aave v3 codebase, including protocol-level core updates and related deployment changes.
[Audits repository](https://github.com/sparkdotfi/sparklend-v1-core/tree/master/audits)
#### SparkLend Advanced
SparkLend Advanced covers additional infrastructure around the core market, including oracle and governance automation features used alongside SparkLend.
[Audits repository](https://github.com/sparkdotfi/sparklend-advanced/tree/master/audits)
#### SparkLend Cap Automator
Cap Automator manages supply and borrow cap updates for SparkLend assets according to governance-set parameters, cooldowns, and limits.
[Audits repository](https://github.com/sparkdotfi/sparklend-cap-automator/tree/master/audits)
### Spark Liquidity Layer
#### Spark ALM Controller
Spark ALM Controller is the onchain control layer of the Spark Liquidity Layer. It manages liquidity flows between Ethereum mainnet and L2s and integrates with the DSS Allocator and external protocols.
[Audits repository](https://github.com/sparkdotfi/spark-alm-controller/tree/master/audits)
### Cross-chain Infrastructure
#### XChain Helpers
XChain Helpers is a library of cross-chain messaging helper contracts used between Ethereum mainnet and L2s, including forwarders and receivers for bridge-specific message passing.
[Audits repository](https://github.com/sparkdotfi/xchain-helpers/tree/master/audits)
#### XChain SSR Oracle
XChain SSR Oracle reports Sky Savings Rate values from Ethereum mainnet to supported chains so integrators can derive the current sUSDS to USDS conversion rate off-mainnet.
[Audits repository](https://github.com/sparkdotfi/xchain-ssr-oracle/tree/master/audits)
### Governance Infrastructure
#### Spark Gov Relay
Spark Gov Relay contains the infrastructure needed to process the cross-chain execution of governance proposals on bridged protocol instances.
[Audits repository](https://github.com/sparkdotfi/spark-gov-relay/tree/master/audits)
### Savings
#### Spark PSM
Spark PSM is a Peg Stability Module for swapping, depositing, and withdrawing USDC, USDS, and sUSDS. It extends Sky PSM liquidity to supported non-mainnet domains.
[Audits repository](https://github.com/sparkdotfi/spark-psm/tree/master/audits)
#### Spark Vaults V2
Spark Vaults V2 is an ERC-4626 vault system that lets Spark savings vaults deploy idle liquidity into approved strategies while continuously accruing yield to depositors.
[Audits repository](https://github.com/sparkdotfi/spark-vaults-v2/tree/dev/audits)
#### Savings Vault Intents
Savings Vault Intents is a large-withdrawal request system for Spark Vaults V2. It lets users create redemption intents that are fulfilled later by the Spark ALM Planner once vault liquidity has been prepared.
[Audit repository](https://github.com/sparkdotfi/spark-savings-intents/tree/master/audits)
#### Savings USDS (sUSDS)
sUSDS is an ERC-4626 wrapper around USDS in the Sky Savings Rate module, allowing holders to earn the savings rate while keeping the token transferable and composable.
[Audits repository](https://github.com/sky-ecosystem/sdai/tree/susds/audit)
#### Savings DAI (sDAI)
sDAI is an ERC-4626 wrapper around DAI in the Dai Savings Rate module, allowing depositors to earn the savings rate while retaining standard token utility.
[Audits repository](https://github.com/sky-ecosystem/sdai/tree/master/audits)
### Lockstake
#### Staked USDS (stUSDS)
stUSDS is an ERC-4626 token that provides capital for SKY-backed borrowing through the Lockstake system and isolates that risk from standard savings products.
[Audits repository](https://github.com/sky-ecosystem/stusds/tree/master/audit)
## Cross-chain Savings Rate Oracle
### Overview
The Cross-chain SSR Oracle reports the Sky Savings Rate (SSR) values across various bridges. This is primarily used to provide integrators the sUSDS/USDS conversion rate (the value of 1 sUSDS in USDS) as sUSDS is an accumulating token that increases in value against USDS over time. This oracle is used by the [Spark PSM](/dev/savings/spark-psm), to enable swapping between USDS and sUSDS at the current conversion rate. Another example use case is decentralized exchanges leveraging the oracle to make liquidity management more capital efficient, by automatically moving sUSDS/USDS order book liquidity according to the conversion rate.
The oracle provides three sUSDS values in sync:
* `ssr`: The per second Sky Savings Rate (compounding rate)
* `chi`: The rate accumulator
* `rho`: The last time chi was updated
These three values enables integrators to extrapolate an exact sUSDS/USDS conversion rate to any point in the future as long as the `ssr` value is not updated on Mainnet. Because this oracle does not need to be synced unless the `ssr` value changes, it uses canonical bridges for maximum security.
The oracle provides convenience functions to fetch the conversion rate at various levels of precision trading off gas efficiency. The specific details are covered in the Functions section below.
### Deployments
#### Base
| Contract | Address |
| ----------------------- | --------------------------------------------------------------------------------------------------------------------- |
| AuthOracle | [0x65d946e533748A998B1f0E430803e39A6388f7a1](https://basescan.org/address/0x65d946e533748A998B1f0E430803e39A6388f7a1) |
| Chainlink Rate Provider | [0x026a5B6114431d8F3eF2fA0E1B2EDdDccA9c540E](https://basescan.org/address/0x026a5B6114431d8F3eF2fA0E1B2EDdDccA9c540E) |
| Balancer Rate Provider | [0x49aF4eE75Ae62C2229bb2486a59Aa1a999f050f0](https://basescan.org/address/0x49aF4eE75Ae62C2229bb2486a59Aa1a999f050f0) |
| Forwarder (Ethereum) | [0xB2833392527f41262eB0E3C7b47AFbe030ef188E](https://etherscan.io/address/0xB2833392527f41262eB0E3C7b47AFbe030ef188E) |
| Receiver (Base) | [0x212871A1C235892F86cAB30E937e18c94AEd8474](https://basescan.org/address/0x212871A1C235892F86cAB30E937e18c94AEd8474) |
#### Arbitrum
| Contract | Address |
| ----------------------- | --------------------------------------------------------------------------------------------------------------------- |
| AuthOracle | [0xEE2816c1E1eed14d444552654Ed3027abC033A36](https://arbiscan.io/address/0xEE2816c1E1eed14d444552654Ed3027abC033A36) |
| Chainlink Rate Provider | [0x84AB0c8C158A1cD0d215BE2746cCa668B79cc287](https://arbiscan.io/address/0x84AB0c8C158A1cD0d215BE2746cCa668B79cc287) |
| Balancer Rate Provider | [0xc0737f29b964e6fC8025F16B30f2eA4C2e2d6f22](https://arbiscan.io/address/0xc0737f29b964e6fC8025F16B30f2eA4C2e2d6f22) |
| Forwarder (Ethereum) | [0x1A229AdbAC83A948226783F2A3257B52006247D5](https://etherscan.io/address/0x1A229AdbAC83A948226783F2A3257B52006247D5) |
| Receiver (Base) | [0x567214Dc57a2385Abc4a756f523ddF0275305Cbc](https://arbiscan.io/address/0x567214Dc57a2385Abc4a756f523ddF0275305Cbc) |
Check the Spark Address Registry for the most up to date resource for contract deployments:
* [Spark Address Registry](/dev/deployments#spark-address-registry)
### Contracts
* Contract Source: [Github](https://github.com/sparkdotfi/xchain-ssr-oracle/)
#### SSROracleBase
Contains common functionality shared between the Ethereum mainnet and cross-chain instances of the oracle. Contains convenience functions to fetch the conversion rate at various levels of precision trading off gas efficiency. sUSDS data is compressed into a single word to save SLOAD gas cost.
#### SSRAuthOracle
Ensures the oracle receives data from an authorized data provider. This is intended to be one or more bridges which publish data to the oracle. Application-level sanity checks are included when new data is proposed to minimize damage in the event of a bridge being compromised. These sanity checks also enforce event ordering in case messages are relayed out of order. `maxSSR` is used as an upper bound for sanity checks to prevent malicious data from being proposed.
#### Rate Providers
Rate Provider contracts take data from the AuthOracle and formats it for specific purposes and integrations. For example The Chainlink Rate Provider provides an up-to-date SSR conversion price in Chainlink format, enabling existing integrators of Chainlink oracles to easily consume this data.
#### Forwarders & Receivers
Forwarders and Receivers are bridge-specific messaging contracts. Forwarders permissionlessly relay `sUSDS` data. Receivers decode this message and forward it to the `SSRAuthOracle`. Please note that receivers are generic and part of the [`xchain-helpers` repository](https://github.com/sparkdotfi/xchain-helpers).
#### Functions
##### **Conversion Functions**
* **`getConversionRate()`**: Returns the current exact conversion rate for sUSDS/USDS with maximum precision as a 27 decimal number.
* **`getConversionRate(uint256 timestamp)`**: Returns the exact conversion rate for sUSDS/USDS for a specific `timestamp` as a 27 decimal number. Can be used to fetch future or conversion rates.
* **`getConversionRateBinomialApprox()`**: Returns a binominal approximation of the current conversion rate for sUSDS/USDS as a 27 decimal number. This approximation is more gas efficient than `getConversionRate`, but it does not give you the exact number.
* **`getConversionRateBinomialApprox(uint256 timestamp)`**: Returns a binominal approximation of the conversion rate for sUSDS/USDS for a specific `timestamp` in the future as a 27 decimal number. Can be used to approximate future conversion rates. This approximation is more gas efficient than `getConversionRate`, but it does not give you the exact number.
* **`getConversionRateLinearApprox()`**: Returns a linear approximation of the current conversion rate for sUSDS/USDS as a 27 decimal number. This approximation is more gas efficient than `getConversionRate`, but it does not give you the exact number.
* **`getConversionRateLinearApprox(uint256 timestamp)`**: Returns a linear approximation of the conversion rate for sUSDS/USDS for a specific `timestamp` in the future as a 27 decimal number. Can be used to approximate future conversion rates. This approximation is more gas efficient than `getConversionRate`, but it does not give you the exact number.
### Gotchas / Integration Concerns
#### Future Conversions
Using the conversion functions for a future rate will only be correct if the Sky Savings Rate (ssr) is not changed in the interim. This rate can be changed by Sky Governance through a governance vote. This fact should be taken into consideration when using the future conversions. You cannot use this function to get past conversion rates.
#### Gas and Precision Tradeoffs
The oracle contains three functions to provide the conversion rate, where one is a perfectly precise function, and the two others are approximations that in return are cheaper in gas. Depending on your use case, and if gas savings are critical you can elect to use an approximation instead of the exact value. Below is an overview of precision vs gas cost.
* `getConversionRate()`: exact value, highest gas cost
* `getConversionRateBinomialApprox():` higher precision, medium gas cost
* `getConversionRateLinearApprox():` lower precision, lowest gas cost
#### Rate Compounding
The Sky Savings Rate is a compounding rate that is stored in the rate accumulator `chi`. Using this value, the last time it was updated (`rho`), and the per second Sky Savings Rate (`ssr`), you can calculate the exact conversion rate for the current time using standard rate compounding calculations. If you are new to how Sky's rate mechanism works, you can find more information here: [Sky Savings Rate Mechanism](https://github.com/makerdao/developerguides/blob/master/mcd/intro-rate-mechanism/intro-rate-mechanism.md#dai-savings-rate).
### Additional resources
* [Cross-chain USDS & sUSDS](/dev/savings/cross-chain-tokens)
* [Spark PSM](/dev/savings/spark-psm)
* [Sky Savings Rate Mechanism](https://github.com/makerdao/developerguides/blob/master/mcd/intro-rate-mechanism/intro-rate-mechanism.md#dai-savings-rate)
## Cross-chain Tokens
:::info
If you are looking to integrate Ethereum mainnet sUSDS or sUSDC, you should review [this documentation instead for sUSDS](/dev/savings/susds-token) or [this documentation for sUSDC](/dev/savings/susdc-token).
:::
### Overview
The Spark Liquidity Layer enables cross-chain liquidity of USDS, sUSDS and sUSDC. Integrators on these networks can tap into this liquidity by integrating these cross-chain tokens, and the [Spark PSM](/dev/savings/spark-psm).
The crosschain USDS and sUSDS tokens use the same simple ERC20 token implementation. The only difference between them is that sUSDS will increase in value over time according to the Sky Savings Rate. Converting between them on other networks can be done at no slippage or fees beyond gas using the Spark PSM. The crosschain sUSDS token does not contain any ERC4626 functionality - this is only available on Ethereum mainnet.
sUSDC does contain ERC4626 functionality, and can be used to deposit into the [Spark Savings Vault](/dev/savings/susdc-token).
### Contract Details
#### USDS
* Type/Category: Token
* Contract Source: [Github](https://github.com/makerdao/usds/blob/master/src/Usds.sol)
#### sUSDS
* Type/Category: Token
* Contract Source: [Github](https://github.com/makerdao/usds/blob/master/src/Usds.sol)
#### sUSDC
* Type/Category: Token
* Contract Source: [Github](https://github.com/makerdao/usds/blob/master/src/Usds.sol)
#### Deployment Addresses
| Network | Token | Address |
| -------- | ----- | -------------------------------------------------------------------------------------------------------------------------------- |
| Base | USDS | [0x820C137fa70C8691f0e44Dc420a5e53c168921Dc](https://basescan.org/address/0x820C137fa70C8691f0e44Dc420a5e53c168921Dc) |
| Base | sUSDS | [0x5875eEE11Cf8398102FdAd704C9E96607675467a](https://basescan.org/address/0x5875eEE11Cf8398102FdAd704C9E96607675467a) |
| Base | sUSDC | [0x3128a0F7f0ea68E7B7c9B00AFa7E41045828e858](https://basescan.org/address/0x3128a0F7f0ea68E7B7c9B00AFa7E41045828e858) |
| Arbitrum | USDS | [0x6491c05A82219b8D1479057361ff1654749b876b](https://arbiscan.io/address/0x6491c05A82219b8D1479057361ff1654749b876b) |
| Arbitrum | sUSDS | [0xdDb46999F8891663a8F2828d25298f70416d7610](https://arbiscan.io/address/0xdDb46999F8891663a8F2828d25298f70416d7610) |
| Arbitrum | sUSDC | [0x940098b108fB7D0a7E374f6eDED7760787464609](https://arbiscan.io/address/0x940098b108fB7D0a7E374f6eDED7760787464609) |
| Optimism | USDS | [0x4F13a96EC5C4Cf34e442b46Bbd98a0791F20edC3](https://optimistic.etherscan.io/address/0x4F13a96EC5C4Cf34e442b46Bbd98a0791F20edC3) |
| Optimism | sUSDS | [0xb5B2dc7fd34C249F4be7fB1fCea07950784229e0](https://optimistic.etherscan.io/address/0xb5B2dc7fd34C249F4be7fB1fCea07950784229e0) |
| Optimism | sUSDC | [0xCF9326e24EBfFBEF22ce1050007A43A3c0B6DB55](https://optimistic.etherscan.io/address/0xCF9326e24EBfFBEF22ce1050007A43A3c0B6DB55) |
| Unichain | USDS | [0x7E10036Acc4B56d4dFCa3b77810356CE52313F9C](https://uniscan.xyz/address/0x7E10036Acc4B56d4dFCa3b77810356CE52313F9C) |
| Unichain | sUSDS | [0xA06b10Db9F390990364A3984C04FaDf1c13691b5](https://uniscan.xyz/address/0xA06b10Db9F390990364A3984C04FaDf1c13691b5) |
| Unichain | sUSDC | [0x14d9143BEcC348920b68D123687045db49a016C6](https://uniscan.xyz/address/0x14d9143BEcC348920b68D123687045db49a016C6) |
#### ERC20 token functionality
The contract implements the functions specified in the ERC-20 interface.
* **`transfer`**: Transfers a specified amount of tokens from the caller's address to the specified recipient's address. It returns a boolean value indicating the success of the transfer.
* **`transferFrom`**: Transfers a specified amount of tokens from the **`from`** address to the **`to`** address. The transfer must be allowed by the **`from`** address by calling the **`approve`** function or by setting an allowance. It returns a boolean value indicating the success of the transfer.
* **`approve`**: Sets an allowance for a specific spender to spend a certain amount of tokens on behalf of the caller. It returns a boolean value indicating the success of the approval.
#### ERC4626 token functionality (only crosschain sUSDC)
The contract implements the functions specified in the ERC-4626 interface.
* **`deposit`**: Deposits a specified amount of tokens into the vault. It returns the amount of shares minted to the caller.
* **`mint`**: Mints a specified amount of shares to the caller. It returns the amount of shares minted to the caller.
* **`redeem`**: Redeems a specified amount of shares from the vault. It returns the amount of tokens redeemed to the caller.
* **`withdraw`**: Withdraws a specified amount of tokens from the vault. It returns the amount of tokens withdrawn from the caller.
#### Upgradeability
The contract uses the ERC-1822 UUPS pattern for upgradeability and the ERC-1967 proxy storage slots standard. It is important that the `SUsdsDeploy` library sequence be used for deploying.
#### Events emitted
* **`Approval`**: This event is emitted when an approval is set for a specific address. It indicates that the owner has approved the spender to spend a certain amount of tokens.
* **`Transfer`**: This event is emitted when tokens are transferred from one address to another. It indicates the amount of tokens transferred and the addresses involved in the transfer.
### Additional resources
* [Spark Liquidity Layer](/products/spark-liquidity-layer)
* [Spark PSM](/dev/savings/spark-psm)
* [sUSDS (Mainnet)](/dev/savings/susds-token)
* [sUSDC (Mainnet)](/dev/savings/susdc-token)
* [Overview of Sky Savings Rate](/products/spark-savings#sky-stablecoin-vaults)
* [EIP-4626](https://eips.ethereum.org/EIPS/eip-4626)
* [ERC-4626 Tokenized Vault Standard](https://ethereum.org/en/developers/docs/standards/tokens/erc-4626/)
## Savings Vault Intents
### Overview
Savings Vault Intents is a request-based withdrawal contract for [Spark Savings Vaults V2](/dev/savings/spark-vaults-v2). It is designed for large redemptions where the vault may not hold enough idle liquidity to satisfy an immediate `redeem()` call.
Instead of redeeming directly from the vault, a user creates an onchain withdrawal request that specifies the vault, the number of shares to redeem, the recipient of the underlying assets, and an expiry deadline. The Spark ALM Planner monitors these requests offchain, prepares liquidity for the target vault, and then fulfills the request atomically.
The contract never takes custody of user shares or redeemed assets. On fulfillment it calls `vault.redeem(shares, recipient, account)` so the underlying assets are sent directly to the designated recipient.
### Supported Networks and Contract Addresses
| Network | Contract | Address |
| -------- | ------------------- | --------------------------------------------------------------------------------------------------------------------- |
| Ethereum | SavingsVaultIntents | [0x592B7DB9906E6f8924C4D74c2A0aB86CE44fDDDf](https://etherscan.io/address/0x592B7DB9906E6f8924C4D74c2A0aB86CE44fDDDf) |
### Contract Details
* Contract Name: `SavingsVaultIntents.sol`
* Contract Source: [Spark Savings Intents code repository](https://github.com/sparkdotfi/spark-savings-intents)
* Ethereum Deployment: [0x592B7DB9906E6f8924C4D74c2A0aB86CE44fDDDf](https://etherscan.io/address/0x592B7DB9906E6f8924C4D74c2A0aB86CE44fDDDf)
* Initial `maxDeadlineDuration`: `604800` seconds (7 days)
### Roles and Access Control
The contract uses OpenZeppelin `AccessControlEnumerable` and defines two roles:
* **`DEFAULT_ADMIN_ROLE`**: Can update the max request deadline window and manage per-vault configuration.
* **`RELAYER`**: Can fulfill pending requests after liquidity has been prepared offchain by the Spark ALM Planner.
### Core State
* **`RELAYER`**: Role identifier used for fulfillment permissions.
* **`maxDeadlineDuration`**: Maximum time window a request deadline can be set into the future.
* **`vaultConfig`**: Mapping of vault address to whitelist status and min/max asset thresholds.
* **`vaultRequestCount`**: Per-vault request counter used to assign monotonically increasing request IDs.
* **`withdrawRequests`**: Mapping of `account => vault => WithdrawRequest` for the currently active request.
### Vault Configuration
Each supported vault has a `VaultConfig`:
* **`whitelisted`**: Whether requests can be created for the vault.
* **`minIntentAssets`**: Minimum underlying asset value allowed per request.
* **`maxIntentAssets`**: Maximum underlying asset value allowed per request.
The mainnet production deployment was initialized for the following Spark Vaults V2 markets:
| Vault | Address | Min Intent Assets | Max Intent Assets |
| ------- | --------------------------------------------------------------------------------------------------------------------- | ----------------- | ----------------- |
| spUSDC | [0x28B3a8fb53B741A8Fd78c0fb9A6B2393d896a43d](https://etherscan.io/address/0x28B3a8fb53B741A8Fd78c0fb9A6B2393d896a43d) | 5,000,000 USDC | 500,000,000 USDC |
| spETH | [0xfE6eb3b609a7C8352A241f7F3A21CEA4e9209B8f](https://etherscan.io/address/0xfE6eb3b609a7C8352A241f7F3A21CEA4e9209B8f) | 1,250 ETH | 250,000 ETH |
| spPYUSD | [0x80128DbB9f07b93DDE62A6daeadb69ED14a7D354](https://etherscan.io/address/0x80128DbB9f07b93DDE62A6daeadb69ED14a7D354) | 5,000,000 PYUSD | 500,000,000 PYUSD |
| spUSDT | [0xe2e7a17dFf93280dec073C995595155283e3C372](https://etherscan.io/address/0xe2e7a17dFf93280dec073C995595155283e3C372) | 5,000,000 USDT | 500,000,000 USDT |
:::info
These thresholds and whitelist settings are governance-controlled and can change over time. Integrators should query `vaultConfig(vault)` and `maxDeadlineDuration()` onchain instead of hardcoding them.
:::
### Request Lifecycle
1. The user approves the Savings Vault Intents contract to spend their Spark Vault shares.
2. The user calls `request(vault, shares, recipient, deadline)`.
3. The contract validates the vault configuration, the deadline, and the caller's balance and allowance.
4. A `RequestCreated` event is emitted for the ALM Planner to pick up offchain.
5. The ALM Planner prepares liquidity for the target Spark Vault.
6. An address with the `RELAYER` role calls `fulfill(account, vault, requestId)`.
7. The contract deletes the stored request and calls `vault.redeem(shares, recipient, account)`.
Fulfillment is atomic. The request is either redeemed in full or the transaction reverts.
### Functions
#### Admin Functions
* **`setMaxDeadlineDuration(uint256 maxDeadlineDuration_)`**: Updates the maximum allowed request deadline window. The value cannot be zero.
* **`updateVaultConfig(address vault, bool whitelisted_, uint256 minIntentAssets_, uint256 maxIntentAssets_)`**: Updates whitelist status and the min/max intent bounds for a vault. `minIntentAssets_` must be strictly less than `maxIntentAssets_`.
#### User Functions
* **`request(address vault, uint256 shares, address recipient, uint256 deadline)`**: Creates or overwrites the caller's pending request for a vault and returns a new `requestId`.
* **`cancel(address vault)`**: Cancels the caller's active request for a vault and returns the cancelled `requestId`.
#### Relayer Function
* **`fulfill(address account, address vault, uint256 requestId)`**: Fulfills a pending request by redeeming the user's shares from the vault and sending assets to the configured recipient. Only callable by the `RELAYER` role.
#### View Functions
* **`maxDeadlineDuration()`**: Returns the maximum deadline offset in seconds.
* **`vaultConfig(address vault)`**: Returns the current whitelist flag and min/max thresholds for a vault.
* **`vaultRequestCount(address vault)`**: Returns the total number of requests ever created for a vault.
* **`withdrawRequests(address account, address vault)`**: Returns the currently active request for a given user and vault.
* **`RELAYER()`**: Returns the role hash for the relayer role.
### Request Validation
`request()` enforces the following preconditions:
* The vault must be whitelisted.
* The recipient must not be the zero address.
* `convertToAssets(shares)` must be within the vault's configured min/max bounds.
* The deadline must be strictly in the future and no greater than `block.timestamp + maxDeadlineDuration`.
* The caller must hold at least `shares` vault shares.
* The caller must have approved at least `shares` to the Savings Vault Intents contract.
### Events Emitted
* **`RequestCreated(address indexed account, address indexed vault, uint256 indexed requestId, uint256 shares, address recipient, uint256 deadline)`**: Emitted when a request is created or overwritten.
* **`RequestCancelled(address indexed account, address indexed vault, uint256 indexed requestId)`**: Emitted when a request is cancelled.
* **`RequestFulfilled(address indexed account, address indexed vault, uint256 indexed requestId)`**: Emitted when a request is fulfilled.
* **`VaultConfigUpdated(address indexed vault, bool indexed whitelisted, uint256 minIntentAssets, uint256 maxIntentAssets)`**: Emitted when admin updates a vault's configuration.
* **`MaxDeadlineDurationUpdated(uint256 indexed maxDeadlineDuration)`**: Emitted when admin updates the maximum deadline window.
### Custom Errors
* **`VaultNotWhitelisted`**: The vault is not enabled for the intent flow.
* **`InvalidRecipientAddress`**: The recipient is the zero address.
* **`IntentAssetsBelowMin`**: The requested redemption is below the configured minimum.
* **`IntentAssetsAboveMax`**: The requested redemption exceeds the configured maximum.
* **`InvalidDeadline`**: The request deadline is invalid or exceeds the allowed window.
* **`InsufficientShares`**: The caller does not hold enough vault shares.
* **`InsufficientAllowance`**: The contract does not have enough share allowance.
* **`RequestNotFound`**: No matching pending request exists for the account and vault.
* **`DeadlineExceeded`**: The relayer attempted to fulfill a request after expiry.
* **`InvalidAdminAddress`**, **`InvalidRelayerAddress`**, **`InvalidVaultAddress`**, **`InvalidMaxDeadlineDuration`**, **`InvalidIntentAmountBounds`**: Configuration errors.
### Gotchas / Integration Concerns
#### One Active Request Per Vault
Each user can have only one active request per vault. Creating a new request for the same vault overwrites the existing one and assigns a new `requestId`.
#### Overwrites Do Not Emit a Cancel Event
Replacing an existing request via `request()` silently removes the old request. Integrators should treat the latest `RequestCreated` event for a given `(account, vault)` pair as authoritative.
#### No Partial Fills
`fulfill()` redeems the full requested share amount or reverts. The contract does not support partial fulfillment.
#### Balance and Allowance Can Change After Request Creation
Users can revoke allowance or move shares away after creating a request. In that case fulfillment will revert when the relayer eventually calls `redeem()`.
#### Request IDs Protect Against Stale Fulfills
`fulfill()` requires the expected `requestId`, preventing a relayer from accidentally fulfilling a request that has since been cancelled or overwritten.
### Additional Resources
* [Spark Savings Intents GitHub Repository](https://github.com/sparkdotfi/spark-savings-intents)
* [Spark Vaults V2](/dev/savings/spark-vaults-v2)
* [Spark Liquidity Layer: Spark ALM Controller](/dev/spark-liquidity-layer/spark-alm-controller)
## sDAI Token
### Overview
Savings Dai (sDAI) is an ERC-4626 representation/wrapper of DAI in the Dai Savings Rate module (DSR). sDAI allows users to deposit DAI to receive the yield generated by the Sky Protocol while still being able to transfer, stake, lend and any other use cases.
:::info
Savings Dai and the Dai Savings Rate are non-custodial and permissionless smart contracts offered by [Sky](https://sky.money), and is not issued by Spark. Spark does not have any control over the Sky Savings Rate or the sDAI token.
:::
### Contract Details
* Contract Name: SavingsDai.sol
* Contract Source: [sDAI code repository](https://github.com/makerdao/sdai)
* Ethereum Contract Address: [0x83f20f44975d03b1b09e64809b757c47f942beea](https://etherscan.io/address/0x83f20f44975d03b1b09e64809b757c47f942beea)
#### Variables
* **`name`**: Savings Dai
* **`symbol`**: sDAI
* **`version`**: 1
* **`decimals`**: 18
* **`totalSupply`**: An unsigned integer representing the total supply of the token. It keeps track of the total number of tokens in circulation.
* **`balanceOf`**: A mapping that associates an address with its corresponding token balance. It allows for looking up the balance of a specific address.
* **`allowance`**: A nested mapping that associates an owner address with a spender address and their approved token allowance. It allows an owner to specify how many tokens a specific spender is allowed to transfer on their behalf.
* **`nonces`**: A mapping that associates an address with its corresponding permit nonce. It is used for the EIP712 permit functionality, allowing an address to sign permit messages with a unique nonce.
#### ERC20 token functionality
The contract implements the functions specified in the ERC-20 interface.
* **`transfer`**: Transfers a specified amount of tokens from the caller's address to the specified recipient's address. It returns a boolean value indicating the success of the transfer.
* **`transferFrom`**: Transfers a specified amount of tokens from the **`from`** address to the **`to`** address. The transfer must be allowed by the **`from`** address by calling the **`approve`** function or by setting an allowance. It returns a boolean value indicating the success of the transfer.
:::warning
sDAI does not emit a **`Transfer`** event during minting/burning, instead it emits the **`Deposit`**/**`Withdraw`** event which contains more information.
Currently, most dapps only look for **`Transfer`** events from the null address which leads to sDAI tokens not correctly accounted for.
:::
* **`approve`**: Sets an allowance for a specific spender to spend a certain amount of tokens on behalf of the caller. It returns a boolean value indicating the success of the approval.
* **`increaseAllowance`**: Increases the allowance granted to a specific spender by adding the **`addedValue`** to the current allowance. It returns a boolean value indicating the success of the operation.
* **`decreaseAllowance`**: Decreases the allowance granted to a specific spender by subtracting the **`subtractedValue`** from the current allowance. It returns a boolean value indicating the success of the operation.
#### **ERC4626 token functionality**
:::info
**Note:** In the following the term *asset* refers to DAI and the term *share* refers to sDAI.
:::
The contract implements the functions specified in the ERC-4626 interface.
* **`asset`**: This function returns the address of the underlying asset (DAI) associated with the Savings DAI token.
* **`totalAssets`**: This function returns the total value of assets held by the Savings DAI token, calculated based on the total supply of shares.
* **`convertToShares`**: This function converts the specified amount of assets into the corresponding number of shares based on the current exchange rate.
* **`convertToAssets`**: This function converts the specified number of shares into the corresponding amount of assets based on the current exchange rate.
* **`maxDeposit`**: This function returns the maximum amount of assets that can be deposited into the Savings DAI contract.
* **`previewDeposit`**: This function calculates and returns the number of shares that would be minted for the specified amount of assets upon deposit.
* **`deposit`**: Deposit a specified amount of assets into the Savings DAI contract and receive the corresponding number of shares.
* **`maxMint`**: This function returns the maximum number of shares that can be minted by an address.
* **`previewMint`**: This function calculates and returns the amount of assets that would be minted for the specified number of shares upon minting.
* **`mint`**: Similar to deposit, except here you specify the amount of shares you wish to mint, and the contract will pull the necessary amount of assets from the user wallet.
* **`maxWithdraw`**: This function returns the maximum amount of assets that can be withdrawn by the specified owner address.
* **`previewWithdraw`**: This function calculates and returns the number of shares that would be burned for the specified amount of assets upon withdrawal.
* **`withdraw`**: This function allows the owner to withdraw a specified amount of assets, burns the corresponding number of shares, and transfers the assets to the receiver address.
* **`maxRedeem`**: This function returns the maximum number of shares that can be redeemed by the specified owner address.
* **`previewRedeem`**: This function calculates and returns the amount of assets that would be redeemed for the specified number of shares upon redemption.
* **`redeem`**: This function allows the owner to redeem a specified number of shares, transfers the corresponding amount of assets to the receiver address, and burns the redeemed shares.
* **`permit`**: This function allows the owner to approve a permit for the spender to spend a specific amount of tokens on their behalf, using a signature for authorization.
* **`permit`**: This overloaded version of the **`permit`** function accepts the signature parameters (v, r, s) individually instead of a signature byte array.
#### Events emitted
* **`Approval`**: This event is emitted when an approval is set for a specific address. It indicates that the owner has approved the spender to spend a certain amount of tokens.
* **`Deposit`**: This event is emitted when a deposit is made into the SavingsDai contract. It indicates the sender, the owner of the deposited assets, the amount of assets deposited, and the corresponding shares minted.
* **`Transfer`**: This event is emitted when tokens are transferred from one address to another. It indicates the amount of tokens transferred and the addresses involved in the transfer.
* **`Withdraw`**: This event is emitted when a withdrawal is made from the SavingsDai contract. It indicates the sender, the receiver of the withdrawn assets, the owner of the withdrawn shares, the amount of assets withdrawn, and the corresponding shares burned.
### Key Mechanisms & Concepts
While the aim of DAI is to always be worth 1 USD, sDAI is constantly increasing due to the accumulation of the yield. In order to have a good UX when sending funds, you can use the view function `ConvertToShares` which will take DAI as input and output the sDAI amount.
### Gotchas / Integration Concerns
* No **`Transfer`** event at mint/burn
ERC4626 specifies a **`Deposit`** and **`Withdraw`** event which is more verbose than the ERC20 **`Transfer`** event. In the short term this has a negative effects with integrations of dapps as most only register **`Transfer`** events, ignoring **`Deposit`** and **`Withdraw`**. Long term, it makes sense for dapps to consider the richer events and avoid unnecessary gas use for the redundant event.
### Additional resources
* [Overview of DSR](https://manual.makerdao.com/parameter-index/core/param-dai-savings-rate)
* [DSR Documentation](https://docs.makerdao.com/smart-contract-modules/proxy-module/dsr-manager-detailed-documentation)
* [DAI Documentation](https://docs.makerdao.com/smart-contract-modules/dai-module/dai-detailed-documentation)
* [EIP-4626](https://eips.ethereum.org/EIPS/eip-4626)
* [ERC-4626 Tokenized Vault Standard](https://ethereum.org/en/developers/docs/standards/tokens/erc-4626/)
## Spark PSM
### Overview
The Spark PSM extends the Sky PSM liquidity on Ethereum mainnet to other chains such as Base and Arbitrum. It allows swaps between USDS, sUSDS, and USDC with no slippage or fees beyond gas, making it the top liquidity source for these pairs in DeFi. This enables holders of USDC on supported networks to easily acquire sUSDS to earn yield, at no cost beyond gas.
:::info
**Spark PSM (this page)** is the cross-chain `PSM3` contract deployed by Spark on Base and Arbitrum. The Ethereum mainnet fixed-rate USDC ↔ USDS path is a separate Sky `UsdsPsmWrapper` around the Sky LitePSM — see [Sky LitePSM](/dev/integration-guides/litepsm/) for that integration.
:::
### Contract Details
* Contract Name: PSM3.sol
* Contract Source: [Spark PSM code repository](https://github.com/sparkdotfi/spark-psm)
#### Deployments
| Network | Spark PSM Address |
| -------- | --------------------------------------------------------------------------------------------------------------------- |
| Base | [0x1601843c5E9bC251A3272907010AFa41Fa18347E](https://basescan.org/address/0x1601843c5E9bC251A3272907010AFa41Fa18347E) |
| Arbitrum | [0x2B05F8e1cACC6974fD79A673a341Fe1f58d27266](https://arbiscan.io/address/0x2B05F8e1cACC6974fD79A673a341Fe1f58d27266) |
#### State Variables and Immutables
* **`usdc`**: IERC20 interface of USDC.
* **`usds`**: IERC20 interface of USDS.
* **`susds`**: IERC20 interface of sUSDS. Note that this is an ERC20 and not a ERC4626 because it's not on mainnet.
* **`pocket`**: Address that holds custody of USDC. The `pocket` can deploy USDC to yield-bearing strategies. Defaulted to the address of the PSM itself.
* **`rateProvider`**: Contract that returns a conversion rate between and sUSDS and USD in 1e27 precision. [See Cross-chain Savings Rate Oracle for more information.](/dev/savings/cross-chain-savings-rate-oracle)
* **`totalShares`**: Total shares in the PSM. Shares represent the ownership of the underlying assets in the PSM.
* **`shares`**: Mapping of user addresses to their shares.
#### Functions
##### **Admin Functions**
* **`setPocket`**: Sets the `pocket` address. Only the `owner` can call this function. This is a very important and sensitive action because it transfers the entire balance of USDC to the new `pocket` address. OZ Ownable is used for this function, and `owner` will always be set to the governance proxy.
##### **Swap Functions**
* **`swapExactIn`**: Allows swapping of assets based on current conversion rates, specifying an `amountIn` of the asset to swap. Ensures the derived output amount is above the `minAmountOut` specified by the user before executing the transfer and emitting the swap event. Includes a referral code.
* **`swapExactOut`**: Allows swapping of assets based on current conversion rates, specifying an `amountOut` of the asset to receive from the swap. Ensures the derived input amount is below the `maxAmountIn` specified by the user before executing the transfer and emitting the swap event. Includes a referral code.
##### **Liquidity Provision Functions**
* **`deposit`**: Deposits assets into the PSM, minting new shares. Includes a referral code.
* **`withdraw`**: Withdraws assets from the PSM by burning shares. Ensures the user has sufficient shares for the withdrawal and adjusts the total shares accordingly. Includes a referral code.
##### **Preview Functions**
* **`previewDeposit`**: Estimates the number of shares minted for a given deposit amount.
* **`previewWithdraw`**: Estimates the number of shares burned and the amount of assets withdrawn for a specified amount.
* **`previewSwapExactIn`**: Estimates the amount of `assetOut` received for a given amount of `assetIn` in a swap.
* **`previewSwapExactOut`**: Estimates the amount of `assetIn` required to receive a given amount of `assetOut` in a swap.
##### **Conversion Functions**
:::warning
**Note:** These functions do not round in the same way as preview functions, so they are meant to be used for general quoting purposes.
:::
* **`convertToAssets`**: Converts shares to the equivalent amount of a specified asset.
* **`convertToAssetValue`**: Converts shares to their equivalent value in USD terms with 18 decimal precision.
* **`convertToShares`**: Converts asset values to shares based on the current exchange rate.
##### **Asset Value Functions**
* **`totalAssets`**: Returns the total value of all assets held by the PSM denominated in USD with 18 decimal precision.
##### Events
* **`Swap`**: Emitted on asset swaps.
* **`Deposit`**: Emitted on asset deposits.
* **`Withdraw`**: Emitted on asset withdrawals.
### Key Mechanisms & Concepts
#### **Fetch Liquidity**
You can fetch the liquidity of the PSM3 by checking the USDS and sUSDS ERC20 token balances deposited in the PSM3 contract. USDC liquidity is being kept in the `pocket` address, but currently this address is set to the PSM3 contract itself, however it could be different in the future.
#### **Pricing**
USDS and USDC are always converted at a fixed 1:1 ratio.
sUSDS is a yield accumulating token, meaning its price will increase vs USDS/USDC over time. A [rate provider oracle](/dev/savings/cross-chain-savings-rate-oracle) is used to provide the sUSDS price.
### Additional resources
* [Cross-chain USDS & sUSDS](/dev/savings/cross-chain-tokens)
* [Cross-chain Savings Rate Oracle](/dev/savings/cross-chain-savings-rate-oracle)
## Spark Savings Vaults V2
### Overview
Spark Vaults V2 is an ERC-4626 compliant yield-bearing vault that implements a continuous rate accumulation mechanism. Users can deposit assets and earn yields through the Vault Savings Rate (VSR), with all interest automatically compounded into their share value.
The vault leverages the Spark Liquidity Layer through a permissioned `TAKER_ROLE` that can pull liquidity from the vault and deploy it into yield-bearing strategies, then transfer the assets back to maintain liquidity for withdrawals. The value owed to the vault at any time is calculated as `assetsOutstanding() = totalAssets() - asset.balanceOf(address(this))`.
Spark Vaults V2 is a fork of sUSDS, enhanced with role-based access control, liquidity deployment capabilities, and improved rate management.
:::info
Spark Vaults V2 is managed by Spark Governance. The vault deploys assets through the Spark Liquidity Layer to optimize yield.
:::
### Supported Networks and Token Addresses
| Network | Vault | Token | Address |
| --------- | ----------- | ------- | --------------------------------------------------------------------------------------------------------------------- |
| Ethereum | Spark USDC | spUSDC | [0x28B3a8fb53B741A8Fd78c0fb9A6B2393d896a43d](https://etherscan.io/address/0x28B3a8fb53B741A8Fd78c0fb9A6B2393d896a43d) |
| Ethereum | Spark USDT | spUSDT | [0xe2e7a17dFf93280dec073C995595155283e3C372](https://etherscan.io/address/0xe2e7a17dFf93280dec073C995595155283e3C372) |
| Ethereum | Spark ETH | spETH | [0xfE6eb3b609a7C8352A241f7F3A21CEA4e9209B8f](https://etherscan.io/address/0xfE6eb3b609a7C8352A241f7F3A21CEA4e9209B8f) |
| Ethereum | Spark PYUSD | spPYUSD | [0x80128DbB9f07b93DDE62A6daeadb69ED14a7D354](https://etherscan.io/address/0x80128DbB9f07b93DDE62A6daeadb69ED14a7D354) |
| Avalanche | Spark USDC | spUSDC | [0x28B3a8fb53B741A8Fd78c0fb9A6B2393d896a43d](https://snowscan.xyz/address/0x28B3a8fb53B741A8Fd78c0fb9A6B2393d896a43d) |
### Contract Details
* Contract Name: SparkVault.sol
* Contract Source: [Spark Vaults V2 code repository](https://github.com/sparkdotfi/spark-vaults-v2/)
#### Constants
* **`MAX_VSR`**: Maximum allowed Vault Savings Rate (corresponds to 100% APY): `1.000000021979553151239153027e27`
* **`RAY`**: Precision constant: `1e27`
* **`SETTER_ROLE`**: Role identifier for addresses that can set the VSR
* **`TAKER_ROLE`**: Role identifier for addresses that can take liquidity (Spark Liquidity Layer)
* **`PERMIT_TYPEHASH`**: EIP-712 permit typehash
* **`version`**: Contract version: "1"
#### Variables
* **`asset`**: Address of the underlying asset (USDC, USDT, or WETH)
* **`decimals`**: Token decimals (inherited from underlying asset)
* **`name`**: Token name (e.g., "Spark USDC")
* **`symbol`**: Token symbol (e.g., "spUSDC")
* **`rho`**: Timestamp of last rate update (unix epoch time)
* **`chi`**: Rate accumulator that tracks cumulative growth \[ray]
* **`vsr`**: Vault Savings Rate \[ray]
* **`minVsr`**: Minimum allowed Vault Savings Rate \[ray]
* **`maxVsr`**: Maximum allowed Vault Savings Rate \[ray]
* **`depositCap`**: Maximum total assets that can be deposited
* **`totalSupply`**: Total supply of vault shares
* **`balanceOf`**: Mapping of address to share balance
* **`nonces`**: Mapping of address to permit nonce for EIP-712
* **`allowance`**: Nested mapping of owner → spender → allowance amount
### ERC20 Token Functionality
The contract implements the standard ERC-20 interface:
* **`transfer`**: Transfers shares from the caller to a recipient. Returns boolean success.
* **`transferFrom`**: Transfers shares from one address to another (requires allowance). Returns boolean success.
* **`approve`**: Sets allowance for a spender. Returns boolean success.
### ERC4626 Token Functionality
:::info
**Note:** In the following, the term *asset* refers to the underlying token (USDC/USDT/WETH) and the term *share* refers to the vault token (spUSDC/spUSDT/spETH).
:::
The contract implements the ERC-4626 interface:
* **`asset`**: Returns the address of the underlying asset
* **`totalAssets`**: Returns total value of assets based on current conversion rate (may exceed actual balance)
* **`convertToShares`**: Converts asset amount to shares based on current `chi`
* **`convertToAssets`**: Converts shares to asset amount based on current `chi`
* **`maxDeposit`**: Returns maximum assets that can be deposited (based on deposit cap)
* **`previewDeposit`**: Calculates shares that would be minted for given asset amount
* **`deposit`**: Deposits assets and mints shares to receiver
* **`maxMint`**: Returns maximum shares that can be minted
* **`previewMint`**: Calculates assets required to mint given shares
* **`mint`**: Mints specified shares by pulling required assets
* **`maxWithdraw`**: Returns maximum assets an owner can withdraw (limited by available liquidity)
* **`previewWithdraw`**: Calculates shares that would be burned for given asset withdrawal
* **`withdraw`**: Withdraws assets by burning shares
* **`maxRedeem`**: Returns maximum shares an owner can redeem (limited by available liquidity)
* **`previewRedeem`**: Calculates assets that would be returned for given shares
* **`redeem`**: Redeems shares for assets
* **`permit`**: Allows gasless approvals using EIP-712 signatures
### Role-Based Access Control
Spark Vaults V2 implements OpenZeppelin's AccessControl for granular permissions:
#### DEFAULT\_ADMIN\_ROLE
Can perform the following operations:
* Upgrade the contract implementation
* Set VSR bounds (`setVsrBounds`)
* Set deposit cap (`setDepositCap`)
* Grant and revoke other roles
#### SETTER\_ROLE
Can perform the following operations:
* Set the Vault Savings Rate (`setVsr`) within the bounds set by admin
#### TAKER\_ROLE
Can perform the following operations:
* Take liquidity from the vault (`take`) to deploy into yield strategies
* This role is typically assigned to the Spark Liquidity Layer
:::warning
**Important:** Addresses with `TAKER_ROLE` cannot deposit into or receive deposits from the vault to prevent conflicts of interest.
:::
### Rate Accumulation Mechanism
Spark Vaults V2 uses a continuous rate accumulation system:
#### Core Formula
The rate accumulator (`chi`) is updated using the formula:
```
chi_new = chi_old * (vsr)^(time_delta) / RAY
```
#### Total Assets Calculation
Total assets are calculated as:
```
totalAssets = totalSupply * nowChi() / RAY
```
Where `nowChi()` returns the current `chi` value accounting for time elapsed since last update.
:::info
**Note:** `totalAssets()` represents the theoretical value of all shares and has no relation to the actual balance of the contract. Actual available liquidity is `asset.balanceOf(address(this))`.
:::
#### Rate Update Process
The `drip()` function updates the rate accumulator:
1. Calculates time elapsed since last update (`rho`)
2. Applies compound interest using `vsr` over elapsed time
3. Updates `chi` and `rho` to current values
4. Emits `Drip` event with new chi and accrued interest
#### Key Functions
* **`drip()`**: Updates rate accumulator to current time
* **`nowChi()`**: Returns current chi value without updating state
* **`assetsOf(address)`**: Returns asset value of an address's shares at current time
* **`assetsOutstanding()`**: Returns assets deployed by TAKER\_ROLE (totalAssets - balance)
### Referral Code
The `deposit` and `mint` functions accept an optional `uint16 referral` parameter that integrators can use to track deposits. Such deposits emit a `Referral(uint16 indexed referral, address indexed owner, uint256 assets, uint256 shares)` event.
This referral system is used for tracking integration sources and can be leveraged for reward programs.
### Upgradeability
The contract uses the UUPS (Universal Upgradeable Proxy Standard) pattern for upgradeability:
* Follows ERC-1822 UUPS standard
* Uses ERC-1967 proxy storage slots
* Only `DEFAULT_ADMIN_ROLE` can authorize upgrades via `_authorizeUpgrade`
* Implementation address can be queried via `getImplementation()`
### Admin Functions
#### setDepositCap
```solidity
function setDepositCap(uint256 newCap) external onlyRole(DEFAULT_ADMIN_ROLE)
```
Sets the maximum total assets that can be deposited into the vault.
#### setVsrBounds
```solidity
function setVsrBounds(uint256 minVsr_, uint256 maxVsr_) external onlyRole(DEFAULT_ADMIN_ROLE)
```
Sets the minimum and maximum allowed Vault Savings Rate. Ensures:
* `minVsr >= RAY` (at least 0% APY)
* `maxVsr <= MAX_VSR` (at most 100% APY)
* `minVsr <= maxVsr`
#### setVsr
```solidity
function setVsr(uint256 newVsr) external onlyRole(SETTER_ROLE)
```
Sets the Vault Savings Rate within the bounds. Automatically calls `drip()` before updating.
#### take
```solidity
function take(uint256 value) external onlyRole(TAKER_ROLE)
```
Allows TAKER\_ROLE to withdraw assets for deployment into yield strategies. Emits `Take` event.
### Events Emitted
* **`Approval(address indexed owner, address indexed spender, uint256 value)`**: Emitted when allowance is set
* **`Deposit(address indexed sender, address indexed owner, uint256 assets, uint256 shares)`**: Emitted on deposit
* **`Transfer(address indexed from, address indexed to, uint256 value)`**: Emitted on share transfers
* **`Withdraw(address indexed sender, address indexed receiver, address indexed owner, uint256 assets, uint256 shares)`**: Emitted on withdrawal
* **`Referral(uint16 indexed referral, address indexed owner, uint256 assets, uint256 shares)`**: Emitted on deposits with referral code
* **`Drip(uint256 chi, uint256 diff)`**: Emitted when rate accumulator is updated
* **`DepositCapSet(uint256 oldCap, uint256 newCap)`**: Emitted when deposit cap changes
* **`VsrBoundsSet(uint256 oldMin, uint256 oldMax, uint256 newMin, uint256 newMax)`**: Emitted when VSR bounds change
* **`VsrSet(address indexed setter, uint256 oldVsr, uint256 newVsr)`**: Emitted when VSR changes
* **`Take(address indexed taker, uint256 value)`**: Emitted when liquidity is taken
### Key Mechanisms & Concepts
#### Continuous Compounding
Unlike traditional vaults that update sporadically, Spark Vaults V2 compounds continuously per-second based on the VSR. The `chi` accumulator tracks cumulative growth, making share values increase smoothly over time.
#### Liquidity Deployment
The TAKER\_ROLE (Spark Liquidity Layer) can remove liquidity to deploy into yield strategies. The vault tracks this as:
```
assetsOutstanding = totalAssets() - asset.balanceOf(address(this))
```
This allows the vault to earn yields beyond just holding assets while maintaining ERC-4626 compliance.
#### Share Value Calculation
Unlike rebasing tokens, vault shares remain constant in quantity but increase in value. To get current asset value:
```solidity
uint256 assetValue = vault.convertToAssets(shareBalance);
// or
uint256 assetValue = vault.assetsOf(userAddress);
```
### Gotchas / Integration Concerns
#### No Transfer Event on Mint/Burn
Similar to standard ERC-4626 vaults, the contract emits `Deposit` and `Withdraw` events which are more verbose than ERC-20 `Transfer` events. Integrations should monitor both event types.
#### totalAssets vs Actual Balance
`totalAssets()` returns the theoretical value of all shares based on the rate accumulator, which can exceed the actual token balance when liquidity is deployed. For actual available liquidity, use:
```solidity
uint256 availableLiquidity = IERC20(vault.asset()).balanceOf(address(vault));
```
#### maxWithdraw and maxRedeem Limitations
These functions return amounts limited by available liquidity, not total user holdings. A user may own more shares than can be immediately redeemed if liquidity has been deployed.
#### Deposit Cap
The vault enforces a `depositCap` on total assets. Check `maxDeposit()` before attempting large deposits.
#### TAKER\_ROLE Restrictions
Addresses with `TAKER_ROLE` cannot deposit or receive deposits. This prevents potential conflicts where the liquidity deployer could also be a user.
#### Rate Updates
The VSR can be updated by `SETTER_ROLE` at any time within the bounds set by admin. Share values will adjust accordingly on the next rate accumulation.
### Additional Resources
* [Spark Vaults V2 GitHub Repository](https://github.com/sparkdotfi/spark-vaults-v2/)
* [Savings Vault Intents](/dev/savings/savings-vault-intents)
* [EIP-4626: Tokenized Vault Standard](https://eips.ethereum.org/EIPS/eip-4626)
* [ERC-4626 Documentation](https://ethereum.org/en/developers/docs/standards/tokens/erc-4626/)
* [EIP-712: Typed Structured Data Hashing and Signing](https://eips.ethereum.org/EIPS/eip-712)
* [ERC-1967: Proxy Storage Slots](https://eips.ethereum.org/EIPS/eip-1967)
* [UUPS Upgradeable Proxies](https://docs.openzeppelin.com/contracts/4.x/api/proxy#UUPSUpgradeable)
## sUSDC Token
### Overview
Savings USDC (sUSDC) is an ERC-4626 representation of USDC in the Spark USDC Vault. sUSDC allows users to deposit USDC to receive the yield generated by the Sky Savings Rate while still being able to transfer, stake, lend the tokens. Converting between USDC and sUSDC can be done using the ERC4626 interface.
:::info
Savings USDC and the Sky Savings Rate are non-custodial and permissionless smart contracts offered by [Sky](https://sky.money), and is not issued by Spark. Spark does not have any control over the Sky Savings Rate or the sUSDC token.
:::
### Supported Networks and Token Addresses
| Network | Token | Address | |
| -------- | ----- | -------------------------------------------------------------------------------------------------------------------------------- | - |
| Ethereum | sUSDC | [0xBc65ad17c5C0a2A4D159fa5a503f4992c7B545FE](https://etherscan.io/address/0xBc65ad17c5C0a2A4D159fa5a503f4992c7B545FE) | |
| Base | sUSDC | [0x3128a0F7f0ea68E7B7c9B00AFa7E41045828e858](https://basescan.org/address/0x3128a0F7f0ea68E7B7c9B00AFa7E41045828e858) | |
| Arbitrum | sUSDC | [0x940098b108fB7D0a7E374f6eDED7760787464609](https://arbiscan.io/address/0x940098b108fB7D0a7E374f6eDED7760787464609) | |
| Optimism | sUSDC | [0xCF9326e24EBfFBEF22ce1050007A43A3c0B6DB55](https://optimistic.etherscan.io/address/0xCF9326e24EBfFBEF22ce1050007A43A3c0B6DB55) | |
| Unichain | sUSDC | [0x14d9143BEcC348920b68D123687045db49a016C6](https://uniscan.xyz/address/0x14d9143BEcC348920b68D123687045db49a016C6) | |
### Contract Details
* Contract Name: SUsdc.sol
* Contract Source: [sUSDC code repository](https://github.com/sparkdotfi/spark-vaults)
#### Variables
* **`name`**: Savings USDC
* **`symbol`**: sUSDC
* **`version`**: 1
* **`decimals`**: 18
* **`totalSupply`**: An unsigned integer representing the total supply of the token. It keeps track of the total number of tokens in circulation.
* **`balanceOf`**: A mapping that associates an address with its corresponding token balance. It allows for looking up the balance of a specific address.
* **`allowance`**: A nested mapping that associates an owner address with a spender address and their approved token allowance. It allows an owner to specify how many tokens a specific spender is allowed to transfer on their behalf.
* **`nonces`**: A mapping that associates an address with its corresponding permit nonce. It is used for the EIP712 permit functionality, allowing an address to sign permit messages with a unique nonce.
#### ERC20 token functionality
The contract implements the functions specified in the ERC-20 interface.
* **`transfer`**: Transfers a specified amount of tokens from the caller's address to the specified recipient's address. It returns a boolean value indicating the success of the transfer.
* **`transferFrom`**: Transfers a specified amount of tokens from the **`from`** address to the **`to`** address. The transfer must be allowed by the **`from`** address by calling the **`approve`** function or by setting an allowance. It returns a boolean value indicating the success of the transfer.
* **`approve`**: Sets an allowance for a specific spender to spend a certain amount of tokens on behalf of the caller. It returns a boolean value indicating the success of the approval.
* **`increaseAllowance`**: Increases the allowance granted to a specific spender by adding the **`addedValue`** to the current allowance. It returns a boolean value indicating the success of the operation.
* **`decreaseAllowance`**: Decreases the allowance granted to a specific spender by subtracting the **`subtractedValue`** from the current allowance. It returns a boolean value indicating the success of the operation.
#### **ERC4626 token functionality**
:::info
**Note:** In the following the term *asset* refers to USDC and the term *share* refers to sUSDC.
:::
The contract implements the functions specified in the ERC-4626 interface.
* **`asset`**: This function returns the address of the underlying asset (USDC) associated with the Savings USDC token.
* **`totalAssets`**: This function returns the total value of assets held by the Savings USDC token, calculated based on the total supply of shares.
* **`convertToShares`**: This function converts the specified amount of assets into the corresponding number of shares based on the current exchange rate.
* **`convertToAssets`**: This function converts the specified number of shares into the corresponding amount of assets based on the current exchange rate.
* **`maxDeposit`**: This function returns the maximum amount of assets that can be deposited into the Savings USDC contract.
* **`previewDeposit`**: This function calculates and returns the number of shares that would be minted for the specified amount of assets upon deposit.
* **`deposit`**: Deposit a specified amount of assets into the Savings USDC contract and receive the corresponding number of shares.
* **`maxMint`**: This function returns the maximum number of shares that can be minted by an address.
* **`previewMint`**: This function calculates and returns the amount of assets that would be minted for the specified number of shares upon minting.
* **`mint`**: Similar to deposit, except here you specify the amount of shares you wish to mint, and the contract will pull the necessary amount of assets from the user wallet.
* **`maxWithdraw`**: This function returns the maximum amount of assets that can be withdrawn by the specified owner address.
* **`previewWithdraw`**: This function calculates and returns the number of shares that would be burned for the specified amount of assets upon withdrawal.
* **`withdraw`**: This function allows the owner to withdraw a specified amount of assets, burns the corresponding number of shares, and transfers the assets to the receiver address.
* **`maxRedeem`**: This function returns the maximum number of shares that can be redeemed by the specified owner address.
* **`previewRedeem`**: This function calculates and returns the amount of assets that would be redeemed for the specified number of shares upon redemption.
* **`redeem`**: This function allows the owner to redeem a specified number of shares, transfers the corresponding amount of assets to the receiver address, and burns the redeemed shares.
* **`permit`**: This function allows the owner to approve a permit for the spender to spend a specific amount of tokens on their behalf, using a signature for authorization.
* **`permit`**: This overloaded version of the **`permit`** function accepts the signature parameters (v, r, s) individually instead of a signature byte array.
#### Referral Code
The `deposit` and `mint` functions accept an optional `uint16 referral` parameter that integrators such as frontends can use to track deposits as originating from them. Such deposits emit a `Referral(uint16 indexed referral, address indexed owner, uint256 assets, uint256 shares)` event. This referral code is used in the [Integration Boost](https://forum.sky.money/t/weekly-atlas-edit-proposal-week-of-2024-10-21-0/25364) and[ Improved Accessibility Rewards](https://forum.sky.money/t/improved-accessibility-reward/24744) by Sky.
#### Upgradeability
The contract uses the ERC-1822 UUPS pattern for upgradeability and the ERC-1967 proxy storage slots standard.
#### Events emitted
* **`Approval`**: This event is emitted when an approval is set for a specific address. It indicates that the owner has approved the spender to spend a certain amount of tokens.
* **`Deposit`**: This event is emitted when a deposit is made into the Savings USDC contract. It indicates the sender, the owner of the deposited assets, the amount of assets deposited, and the corresponding shares minted.
* **`Transfer`**: This event is emitted when tokens are transferred from one address to another. It indicates the amount of tokens transferred and the addresses involved in the transfer.
* **`Withdraw`**: This event is emitted when a withdrawal is made from the Savings USDC contract. It indicates the sender, the receiver of the withdrawn assets, the owner of the withdrawn shares, the amount of assets withdrawn, and the corresponding shares burned.
### Key Mechanisms & Concepts
sUSDC is constantly increasing in value against USDC due to the accumulation of the yield. In order to have a good UX when sending funds, you can use the view function `convertToShares` which will take USDC as input and output the sUSDC amount.
### Gotchas / Integration Concerns
* No **`Transfer`** event at mint/burn
ERC4626 specifies a **`Deposit`** and **`Withdraw`** event which is more verbose than the ERC20 **`Transfer`** event. In the short term this has a negative effect with integrations of dapps as most only register **`Transfer`** events, ignoring **`Deposit`** and **`Withdraw`**. Long term, it makes sense for dapps to consider the richer events and avoid unnecessary gas use for the redundant event.
### Additional resources
* [EIP-4626](https://eips.ethereum.org/EIPS/eip-4626)
* [ERC-4626 Tokenized Vault Standard](https://ethereum.org/en/developers/docs/standards/tokens/erc-4626/)
## sUSDS Token
:::info
**This page only reflects the sUSDS implementation on Ethereum mainnet. If you are looking to integrate sUSDS on other networks, see this page:** [**Cross-chain USDS & sUSDS**](/dev/savings/cross-chain-tokens)**.**
:::
### Overview
Savings USDS (sUSDS) is an ERC-4626 representation/wrapper of USDS in the Sky Savings Rate module (SSR). sUSDS allows users to deposit USDS to receive the yield generated by the Sky Protocol while still being able to transfer, stake, lend the tokens. Converting between USDS and sUSDS can be done using the ERC4626 interface.
:::info
Savings USDS and the Sky Savings Rate are non-custodial and permissionless smart contracts offered by [Sky](https://sky.money), and is not issued by Spark. Spark does not have any control over the Sky Savings Rate or the sUSDS token.
:::
### Supported Networks and Token Addresses
| Network | Token | Address |
| -------- | ----- | --------------------------------------------------------------------------------------------------------------------- |
| Ethereum | USDS | [0xdC035D45d973E3EC169d2276DDab16f1e407384F](https://etherscan.io/address/0xdC035D45d973E3EC169d2276DDab16f1e407384F) |
| Ethereum | sUSDS | [0xa3931d71877c0e7a3148cb7eb4463524fec27fbd](https://etherscan.io/address/0xa3931d71877c0e7a3148cb7eb4463524fec27fbd) |
| Base | USDS | [0x820C137fa70C8691f0e44Dc420a5e53c168921Dc](https://basescan.org/address/0x820C137fa70C8691f0e44Dc420a5e53c168921Dc) |
| Base | sUSDS | [0x5875eEE11Cf8398102FdAd704C9E96607675467a](https://basescan.org/address/0x5875eEE11Cf8398102FdAd704C9E96607675467a) |
| Arbitrum | USDS | [0x6491c05A82219b8D1479057361ff1654749b876b](https://arbiscan.io/address/0x6491c05A82219b8D1479057361ff1654749b876b) |
| Arbitrum | sUSDS | [0xdDb46999F8891663a8F2828d25298f70416d7610](https://arbiscan.io/address/0xdDb46999F8891663a8F2828d25298f70416d7610) |
### Contract Details
* Contract Name: SUsds.sol
* Contract Source: [sUSDS code repository](https://github.com/makerdao/sdai/blob/susds/src/SUsds.sol)
* Ethereum Deployment: [0xa3931d71877C0E7a3148CB7Eb4463524FEc27fbD](https://etherscan.io/address/0xa3931d71877c0e7a3148cb7eb4463524fec27fbd)
#### Variables
* **`name`**: Savings USDS
* **`symbol`**: sUSDS
* **`version`**: 1
* **`decimals`**: 18
* **`totalSupply`**: An unsigned integer representing the total supply of the token. It keeps track of the total number of tokens in circulation.
* **`balanceOf`**: A mapping that associates an address with its corresponding token balance. It allows for looking up the balance of a specific address.
* **`allowance`**: A nested mapping that associates an owner address with a spender address and their approved token allowance. It allows an owner to specify how many tokens a specific spender is allowed to transfer on their behalf.
* **`nonces`**: A mapping that associates an address with its corresponding permit nonce. It is used for the EIP712 permit functionality, allowing an address to sign permit messages with a unique nonce.
#### ERC20 token functionality
The contract implements the functions specified in the ERC-20 interface.
* **`transfer`**: Transfers a specified amount of tokens from the caller's address to the specified recipient's address. It returns a boolean value indicating the success of the transfer.
* **`transferFrom`**: Transfers a specified amount of tokens from the **`from`** address to the **`to`** address. The transfer must be allowed by the **`from`** address by calling the **`approve`** function or by setting an allowance. It returns a boolean value indicating the success of the transfer.
* **`approve`**: Sets an allowance for a specific spender to spend a certain amount of tokens on behalf of the caller. It returns a boolean value indicating the success of the approval.
* **`increaseAllowance`**: Increases the allowance granted to a specific spender by adding the **`addedValue`** to the current allowance. It returns a boolean value indicating the success of the operation.
* **`decreaseAllowance`**: Decreases the allowance granted to a specific spender by subtracting the **`subtractedValue`** from the current allowance. It returns a boolean value indicating the success of the operation.
#### **ERC4626 token functionality**
:::info
**Note:** In the following the term *asset* refers to USDS and the term *share* refers to sUSDS.
:::
The contract implements the functions specified in the ERC-4626 interface.
* **`asset`**: This function returns the address of the underlying asset (USDS) associated with the Savings USDS token.
* **`totalAssets`**: This function returns the total value of assets held by the Savings USDS token, calculated based on the total supply of shares.
* **`convertToShares`**: This function converts the specified amount of assets into the corresponding number of shares based on the current exchange rate.
* **`convertToAssets`**: This function converts the specified number of shares into the corresponding amount of assets based on the current exchange rate.
* **`maxDeposit`**: This function returns the maximum amount of assets that can be deposited into the Savings USDS contract.
* **`previewDeposit`**: This function calculates and returns the number of shares that would be minted for the specified amount of assets upon deposit.
* **`deposit`**: Deposit a specified amount of assets into the Savings USDS contract and receive the corresponding number of shares.
* **`maxMint`**: This function returns the maximum number of shares that can be minted by an address.
* **`previewMint`**: This function calculates and returns the amount of assets that would be minted for the specified number of shares upon minting.
* **`mint`**: Similar to deposit, except here you specify the amount of shares you wish to mint, and the contract will pull the necessary amount of assets from the user wallet.
* **`maxWithdraw`**: This function returns the maximum amount of assets that can be withdrawn by the specified owner address.
* **`previewWithdraw`**: This function calculates and returns the number of shares that would be burned for the specified amount of assets upon withdrawal.
* **`withdraw`**: This function allows the owner to withdraw a specified amount of assets, burns the corresponding number of shares, and transfers the assets to the receiver address.
* **`maxRedeem`**: This function returns the maximum number of shares that can be redeemed by the specified owner address.
* **`previewRedeem`**: This function calculates and returns the amount of assets that would be redeemed for the specified number of shares upon redemption.
* **`redeem`**: This function allows the owner to redeem a specified number of shares, transfers the corresponding amount of assets to the receiver address, and burns the redeemed shares.
* **`permit`**: This function allows the owner to approve a permit for the spender to spend a specific amount of tokens on their behalf, using a signature for authorization.
* **`permit`**: This overloaded version of the **`permit`** function accepts the signature parameters (v, r, s) individually instead of a signature byte array.
#### Referral Code
The `deposit` and `mint` functions accept an optional `uint16 referral` parameter that integrators such as frontends can use to track deposits as originating from them. Such deposits emit a `Referral(uint16 indexed referral, address indexed owner, uint256 assets, uint256 shares)` event. This referral code is used in the [Integration Boost](https://forum.sky.money/t/weekly-atlas-edit-proposal-week-of-2024-10-21-0/25364) and[ Improved Accessibility Rewards](https://forum.sky.money/t/improved-accessibility-reward/24744) by Sky.
#### Upgradeability
The contract uses the ERC-1822 UUPS pattern for upgradeability and the ERC-1967 proxy storage slots standard.
#### Events emitted
* **`Approval`**: This event is emitted when an approval is set for a specific address. It indicates that the owner has approved the spender to spend a certain amount of tokens.
* **`Deposit`**: This event is emitted when a deposit is made into the Savings USDS contract. It indicates the sender, the owner of the deposited assets, the amount of assets deposited, and the corresponding shares minted.
* **`Transfer`**: This event is emitted when tokens are transferred from one address to another. It indicates the amount of tokens transferred and the addresses involved in the transfer.
* **`Withdraw`**: This event is emitted when a withdrawal is made from the Savings USDS contract. It indicates the sender, the receiver of the withdrawn assets, the owner of the withdrawn shares, the amount of assets withdrawn, and the corresponding shares burned.
### Key Mechanisms & Concepts
While the aim of USDS is to always be worth 1 USD, sUSDS is constantly increasing in value due to the accumulation of the yield. In order to have a good UX when sending funds, you can use the view function `ConvertToShares` which will take USDS as input and output the sUSDS amount.
### Gotchas / Integration Concerns
* No **`Transfer`** event at mint/burn
ERC4626 specifies a **`Deposit`** and **`Withdraw`** event which is more verbose than the ERC20 **`Transfer`** event. In the short term this has a negative effect with integrations of dapps as most only register **`Transfer`** events, ignoring **`Deposit`** and **`Withdraw`**. Long term, it makes sense for dapps to consider the richer events and avoid unnecessary gas use for the redundant event.
### Additional resources
* [EIP-4626](https://eips.ethereum.org/EIPS/eip-4626)
* [ERC-4626 Tokenized Vault Standard](https://ethereum.org/en/developers/docs/standards/tokens/erc-4626/)
### Introduction
This integration guide explains why listing sUSDS instead of USDS on lending markets is beneficial and how to implement this integration efficiently.
### Benefits of Listing sUSDS Over USDS
The key advantage of listing sUSDS over USDS is that it ensures base lending and borrowing rates follow the Sky Savings Rate (SSR) of sUSDS, making markets more capital-efficient. In practice, this means liquidity providers will always earn at least the base rate of sUSDS—the Sky Savings Rate—even without any borrowing activity.
This is not the case with USDS, where markets require either sufficient borrowing demand or efficient rate arbitrage to ensure the lending rate matches that of sUSDS. By listing sUSDS, the protocol becomes more capital-efficient for LPs by eliminating the opportunity cost of potentially low rates, as depositors always earn the Sky Savings Rate. This should attract more liquidity to the lending protocol, potentially generating more loans and ultimately more fees.
Conversely, listing sUSDS also guarantees a minimum borrow rate equal to the SSR. This reduces the need for rate arbitrage across lending markets by mitigating market inefficiencies.
From a user experience perspective, sUSDS usage can be completely abstracted away, as USDS and sUSDS can be freely converted without liquidity constraints or fees. The result is a lending market that appears to be a standard USDS market but with guaranteed lending and borrowing base rates equal to the SSR.
### How Does it Work?
sUSDS is a token that increases in value against USDS according to the Sky Savings Rate. This means the dollar value of sUSDS gradually increases over time. By listing sUSDS in a lending market, depositors earn this rate as their sUSDS becomes more valuable, in addition to the interest earned (which is also in sUSDS).
Similarly, when borrowing sUSDS, both the interest and the principal debt amount increase in value over time according to the Sky Savings Rate. In other words, it gradually becomes more expensive to acquire the sUSDS tokens needed to repay the debt.
Lending markets should adjust their interest rate mechanisms to account for these "built-in" rates. Read more about this in the [Rates section](#rates) below.
### Improving the User Experience
Since many users are unfamiliar with lending and borrowing a yield-accumulating token, it makes sense in some cases to abstract away this complexity.
As mentioned earlier, sUSDS usage can be abstracted to appear as a normal USDS lending market with guaranteed base rates equal to the SSR. This is possible because USDS and sUSDS can be freely and instantly converted without fees, slippage, or liquidity constraints. A user could deposit USDS, and the lending protocol would convert it to sUSDS before depositing it into the lending market. The protocol would then display converted balances and rates for USDS. When users borrow USDS, the protocol would withdraw sUSDS and convert it to USDS before sending it to the user. From the end user's perspective, this would function like a standard USDS lending market. The sections below explain how this can be implemented.
### Integrating sUSDS Into a Lending Market
The following sections explore how sUSDS can be listed from a technical perspective. There are two options: listing sUSDS directly, or listing sUSDS while abstracting it as a USDS lending market.
sUSDS is an ERC4626 token with USDS as its base asset. sUSDS increases in value against USDS over time. It's an accumulating token, not a rebasing token, as yield accumulates in its value rather than through an increasing supply.
sUSDS can be integrated like any other token as it is ERC20 compliant.
You can find more documentation on sUSDS here:
* [sUSDS Developer Documentation](/dev/savings/susds-token)
#### Price Feed
For markets to list an asset, they typically need a price feed to calculate user collateral value, borrow limits, and trigger liquidations.
On Ethereum Mainnet the sUSDS token contract on Ethereum mainnet contains a conversion function [`convertToAssets`](https://etherscan.io/token/0xa3931d71877C0E7a3148CB7Eb4463524FEc27fbD#readProxyContract#F8) which takes a USDS amount and returns the sUSDS amount. If you just want the sUSDS price, you can simply input 10ˆ18 (due to 18 decimals) and divide by 10^18:
`sUSDS_price = convertToAssets(10ˆ18) / 10ˆ18`
The protocol can leverage a USDS/USD oracle price to calculate the sUSDS/USD price by multiplying the two together:
`sUSDS/USD = USDS/USD * sUSDS/USDS`
On networks other than Ethereum mainnet, sUSDS is not an ERC4626 token and doesn't contain the `convertToAssets` function. Instead, the `getConversionRate` function can be used from the [SSR Oracle here](https://basescan.org/address/0x65d946e533748A998B1f0E430803e39A6388f7a1#readContract#F4) (in this example Base) to retrieve the sUSDS price.
You can read more about the SSR Oracle here.
* [SSR Oracle Developer Documentation](/dev/savings/cross-chain-savings-rate-oracle)
If you need a Chainlink compliant oracle, you can use the [Chainlink Rate Provider](/dev/savings/cross-chain-savings-rate-oracle#rate-providers), which will wrap the SSR oracle data in a Chainlink compliant format. [You can find a list of supported networks here.](/dev/savings/cross-chain-savings-rate-oracle#deployments)
#### Conversions
The following section will explain how to convert between USDS and sUSDS amounts for accounting purposes. For swapping between USDS and sUSDS see the [Depositing and Withdrawing section](#depositing--withdrawing-usds).
##### Ethereum
On Ethereum, the following ERC4626 functions can be used for conversions:
sUSDS to USDS conversion:
* The ERC4626 function [`convertToAssets`](https://etherscan.io/token/0xa3931d71877C0E7a3148CB7Eb4463524FEc27fbD#readProxyContract#F8) takes an sUSDS amount and returns the USDS amount.
USDS to sUSDS conversion:
* The ERC4626 function [`convertToShares`](https://etherscan.io/token/0xa3931d71877C0E7a3148CB7Eb4463524FEc27fbD#readProxyContract#F9) takes a USDS amount and returns the sUSDS amount.
##### Other Networks
On other networks, the SSR Oracle can be used to do conversions. [See which networks are supported here](/dev/savings/cross-chain-savings-rate-oracle#deployments).
* The `getConversionRate` function from the SSROracle ([Base Example](https://basescan.org/address/0x65d946e533748A998B1f0E430803e39A6388f7a1#readContract#F6)) can be used to get the conversion rate between USDS and sUSDS. This is essentially the sUSDS price in USDS. This is a 27-decimal variable, so you should divide by 10ˆ27 to get the price:
`USDS amount = sUSDS_amount * getConversionRate / 10ˆ27`
`sUSDS amount = USDS_amount / getConversionRate * 10ˆ27`
#### Rates
The Sky Savings Rate can be fetched from the [sUSDS contract on Ethereum](https://etherscan.io/token/0xa3931d71877C0E7a3148CB7Eb4463524FEc27fbD#readProxyContract#F24) or from the [SSROracle on external networks](https://basescan.org/address/0x65d946e533748A998B1f0E430803e39A6388f7a1#readContract#F13) as the `ssr` variable. `ssr` is a 27-decimal variable. This is a per-second rate, so to calculate the APY, use the following conversion:
`APY = (ssr/ray)^(seconds_in_a_year)-1 = (ssr/ray)^(60*60*24*365)-1`
An example is:
`APY = (1.000000002659864411854984565/10^27)^(60*60*24*365)-1 = 0.0875 = 8.75%`
#### Interest Rate Models
Since sUSDS has a "built-in" rate, integrators should consider this when defining their interest rate models.
In an Aave-type lending market, this would mean adjusting the base rate. From a USDS perspective, the base rate and optimal rate in this scenario are the additional rates on top of the SSR. The base rate could be set to 0 to just reflect the underlying SSR, with the optimal rate slightly above. These rates would therefore need to be set differently than for non-yielding stablecoins.Æ
The combined rate of the SSR and the protocol rate in USDS terms would be calculated as:
`APY_combined_USDS = (1+ssr_apy) * (1+protocol_apy_sUSDS) - 1`
This applies to both lending and borrowing rates.
Note that we use APY for both rates. This can subsequently be converted into APRs if necessary, using the number of compounding periods.
**Example**
* The Sky Savings Rate is 5% APY.
* sUSDS price is `1.0384`
Alice deposits 1000 USDS into sUSDS and receives 962.98 sUSDS (worth 1000 USDS)
Alice deposits 962.98 sUSDS into a lending market which has an APY of 2%.
After a year, Alice will have earned:
`0.02 * 962.98 sUSDS = 19.26 sUSDS`
Making her total balance `962.98 + 19.26 = 982.24` sUSDS total.
In the same time span, sUSDS has increased in value by 5% against USDS.
`New_Price_sUSDS = Old_Price_sUSDS * 1.05 = 1.0384 * 1.05 = 1.0903`
Her total USDS amount after 1 year is:
`USDS_amount = sUSDS_amount * New_Price_sUSDS = 982.24 * 1.0903 = 1071`
This gives a combined APY for USDS of 7.1%
Which is equal to
`APY_combined_USDS = (1+ssr_apy) * (1+protocol_apy_sUSDS) - 1 = (1+0.05) * (1+0.02) - 1 = 0.071 = 7.1%`
#### Abstracting away sUSDS
Since users are mostly familiar with lending/borrowing non-yielding stablecoins, it makes sense to abstract away the use of sUSDS. It's important to note that this is simply an sUSDS market on the backend, but with clever conversions will look and behave like a standard USDS lending market with a base rate equal to the Sky Savings Rate. This can be achieved using the ERC4626 conversion functions of the sUSDS token on Ethereum, or the Spark PSM on other networks, when depositing and withdrawing USDS into the lending market. Furthermore, the rate conversions above can be used to display accounting of supply, debt, lending, and borrowing rates in terms of USDS instead of sUSDS.
#### Price Feed
Since the market would be an sUSDS market on the backend, it will still use an sUSDS oracle for collateral pricing. See the price feed section for more information.
#### Depositing & Withdrawing USDS
If the user already has sUSDS, they should simply be able to deposit it directly. However, the frontend will still display balances, accounting, and rates for USDS using the conversion methods outlined above.
On Ethereum, if the user has USDS, the lending market can integrate the deposit function of sUSDS to mint sUSDS and transfer it into the lending market. The balances and rates shown to the user in the frontend would be converted to USDS, as per the [Conversions](#conversions) and [Rates](#rates) sections above.
When the user withdraws, the system can leverage the withdraw function of sUSDS to send USDS to the user. This is also done when a user borrows USDS.
You can read about the sUSDS ERC4626 functions here:
* [sUSDS Developer Documentation](/dev/savings/susds-token#erc4626-token-functionality)
On networks other than Ethereum mainnet, sUSDS is not an ERC4626 token but a simple ERC20 token, which is why these conversion functions are not available in the token itself. Instead, you can leverage the Spark PSM, which enables swapping between USDS, sUSDS, and USDC with no slippage or fee (besides gas), to achieve the same functionality. You can read more about the Spark PSM here.
* [Spark PSM Developer Documentation](/dev/savings/spark-psm)
The Spark Liquidity Layer will ensure there is always enough liquidity on external networks for swapping.
#### USDS Balances & Debt
To display USDS balances and debt in the UI, the conversion functions in the [Conversions section](#conversions) can be used to convert sUSDS balances to USDS balances.
#### USDS Lending and Borrow Rates
To display rates according to USDS, you can refer to the example in the [Interest Rate Models section](#interest-rate-models). The rates for USDS can be calculated using the Sky Savings Rate and the sUSDS borrow or lending rate as follows:
`APY_combined_USDS = (1+ssr_apy) * (1+protocol_apy_sUSDS) - 1`
#### USDS Liquidations
For liquidations, the protocol can elect to support paying down sUSDS debt using USDS, by using the same conversions as for lending and borrowing. Liquidators would still have to monitor the sUSDS debt and price to trigger liquidations.
## Contract Reference
### `UsdsPsmWrapper` (USDS-USDC)
The integrator-facing contract. Presents a USDS interface and routes through the underlying DAI LitePSM plus Maker's DAI and USDS join adapters.
* **Address**: [0xA188EEC8F81263234dA3622A406892F3D630f98c](https://etherscan.io/address/0xA188EEC8F81263234dA3622A406892F3D630f98c)
* **Source**: [sky-ecosystem/usds-wrappers](https://github.com/sky-ecosystem/usds-wrappers) ([`UsdsPsmWrapper.sol`](https://github.com/sky-ecosystem/usds-wrappers/blob/dev/src/UsdsPsmWrapper.sol))
* **Audit**: [ChainSecurity MakerDAO USDS Wrappers audit](https://github.com/sky-ecosystem/usds-wrappers/blob/dev/audit/20240904-ChainSecurity_MakerDAO_USDS_Wrappers_audit.pdf)
#### State Getters
* **`psm`**: address of the underlying [LitePSM-DAI-USDC](https://etherscan.io/address/0xf6e72Db5454dd049d0788e411b06CfAF16853042).
* **`dai`**: backwards-compatibility getter that returns the USDS token address, not DAI.
* **`usds`**: address of USDS.
* **`gem`**: address of USDC (the "gem" token).
* **`usdsJoin`**: Maker USDS join adapter used by the wrapper.
* **`vat`**: Maker Vat address, exposed through the wrapper.
* **`gemJoin`**: backwards-compatibility getter that returns the wrapper address itself.
* **`dec`**: USDC decimals, exposed for compatibility.
* **`ilk`**: collateral type identifier copied from the underlying core PSM.
* **`tin`**: sell-gem fee in WAD. `type(uint256).max` indicates the sell direction is halted.
* **`tout`**: buy-gem fee in WAD. `type(uint256).max` indicates the buy direction is halted.
* **`buf`**: target DAI buffer maintained by the core PSM, in WAD.
* **`pocket`**: immutable address holding USDC custody. Buy-side liquidity equals `gem.balanceOf(pocket)`.
* **`vow`**: Maker Vow address where collected fees are sent on `chug()`.
* **`to18ConversionFactor`**: constant `10^12`, scales USDC (6 decimals) to WAD.
* **`HALTED`**: `type(uint256).max`, exposed for compatibility.
* **`live`**: returns `vat.live()`; it is not a wrapper-owned pause flag.
#### Write Functions
##### `sellGem(address usr, uint256 gemAmt) → uint256 usdsOut`
Swaps USDC for USDS.
* **Inputs**:
* `usr` — recipient of the USDS.
* `gemAmt` — USDC amount to sell, in 6-decimal units.
* **Return**: `usdsOut` in WAD.
* **Approval required**: caller must `approve(wrapper, gemAmt)` on USDC before calling.
* **Reverts** when `tin == type(uint256).max` (sell direction halted), when the caller has not approved enough USDC, or when the core PSM's external DAI balance is insufficient for the USDS output.
##### `buyGem(address usr, uint256 gemAmt) → uint256 usdsIn`
Swaps USDS for USDC.
* **Inputs**:
* `usr` — recipient of the USDC.
* `gemAmt` — USDC amount to receive, in 6-decimal units.
* **Return**: `usdsIn` in WAD (the USDS amount the caller is required to provide).
* **Approval required**: caller must `approve(wrapper, gemAmt * 10^12 * (WAD + tout) / WAD)` on USDS before calling. With `tout = 0`, this simplifies to `gemAmt * 10^12`.
* **Reverts** when `tout == type(uint256).max` (buy direction halted), when the caller has not approved enough USDS, or when the core PSM cannot transfer `gemAmt` USDC from the pocket.
### LitePSM-DAI-USDC (Core)
The core DAI-denominated LitePSM that the wrapper delegates to. Integrators do not normally need to call this directly. It is documented here for completeness and for keeper integrations.
* **Address**: [0xf6e72Db5454dd049d0788e411b06CfAF16853042](https://etherscan.io/address/0xf6e72Db5454dd049d0788e411b06CfAF16853042)
* **Source**: [sky-ecosystem/dss-lite-psm](https://github.com/sky-ecosystem/dss-lite-psm) ([`DssLitePsm.sol`](https://github.com/sky-ecosystem/dss-lite-psm/blob/main/src/DssLitePsm.sol))
* **Audits**: [dss-lite-psm audits directory](https://github.com/sky-ecosystem/dss-lite-psm/tree/main/audits)
The core exposes a DAI-denominated surface (`sellGem`, `buyGem`, `sellGemNoFee`, `buyGemNoFee`) with the same semantics as the wrapper, plus three permissionless bookkeeping functions:
* **`fill()`** — mints `rush()` DAI from the Maker Vat into the PSM, bounded by the target debt calculation and the local/global debt ceilings.
* **`trim()`** — burns `gush()` DAI and repays Vat debt when the PSM has excess debt or needs to reduce debt against its target.
* **`chug()`** — sweeps `cut()` accumulated fees to the Maker Vow.
The `HALTED` sentinel for both `tin` and `tout` is `type(uint256).max`. When set, the corresponding `sellGem` / `buyGem` reverts. The emergency halt is performed by the `DssLitePsmMom` contract on behalf of Sky governance.
The no-fee variants (`sellGemNoFee`, `buyGemNoFee`) are gated by a `bud` whitelist set by governance and are not generally available to integrators.
### Pocket
The USDC custody address. The core LitePSM holds a max allowance to transfer USDC from this address during `buyGem`. The pocket address is immutable in the deployed core PSM.
* **Address**: [0x37305B1cD40574E4C5Ce33f8e8306Be057fD7341](https://etherscan.io/address/0x37305B1cD40574E4C5Ce33f8e8306Be057fD7341)
### Events
Emitted by the core LitePSM:
* **`SellGem(address indexed owner, uint256 value, uint256 fee)`** — `value` is USDC sold (6 decimals), `fee` is DAI fee retained (WAD).
* **`BuyGem(address indexed owner, uint256 value, uint256 fee)`** — `value` is USDC bought (6 decimals), `fee` is DAI fee retained (WAD).
* **`Fill(uint256 wad)`** — DAI minted into the core PSM (WAD).
* **`Trim(uint256 wad)`** — DAI burned from the core PSM (WAD).
* **`Chug(uint256 wad)`** — DAI swept to the Vow (WAD).
### ABI Snippet
```solidity
interface IUsdsPsmWrapper {
// Swaps
function sellGem(address usr, uint256 gemAmt) external returns (uint256 usdsOut);
function buyGem(address usr, uint256 gemAmt) external returns (uint256 usdsIn);
// State
function psm() external view returns (address);
function dai() external view returns (address); // compatibility getter; returns USDS
function usds() external view returns (address);
function gem() external view returns (address);
function usdsJoin() external view returns (address);
function vat() external view returns (address);
function ilk() external view returns (bytes32);
function pocket() external view returns (address);
function dec() external view returns (uint256);
function gemJoin() external view returns (address);
// Forwarded from core PSM
function tin() external view returns (uint256);
function tout() external view returns (uint256);
function buf() external view returns (uint256);
function vow() external view returns (address);
function live() external view returns (uint256);
function HALTED() external view returns (uint256);
function to18ConversionFactor() external view returns (uint256);
}
```
## How the LitePSM Works
### Architecture
A USDS ↔ USDC swap through the deployed wrapper flows through the USDS wrapper, the core DAI LitePSM, and the pocket. The wrapper also uses Maker's DAI and USDS join adapters to translate the DAI-denominated core route into a USDS-denominated interface:
```
caller ──► UsdsPsmWrapper ──► DssLitePsm (LITE-PSM-USDC-A) ──► Pocket
│ ▲
├──── DaiJoin ────────────┤
└──── UsdsJoin ───────────┘
```
The core **`DssLitePsm`** is DAI-native: it swaps USDC against a pre-minted DAI balance. To present a USDS interface, the **`UsdsPsmWrapper`** wraps the core PSM and uses `DaiJoin` and `UsdsJoin` to move between DAI, USDS, and Vat internal balances. USDC custody lives in the **Pocket**, a separate address whose balance is the maximum USDC available for buy-side liquidity.
The "lite" in LitePSM refers to a design choice: the original Maker DSS PSM touched the Vat on every swap, which is expensive in gas. The LitePSM holds pre-minted DAI inside the core PSM contract, so core user swaps reduce to ERC-20 transfers plus small accounting around fees. Periodic permissionless bookkeeping calls (described below) keep the system aligned with its target accounting state.
### Pre-Minted DAI Buffer
The core PSM has a `buf` parameter, currently `400_000_000e18`, representing the target amount of unused pre-minted DAI the system is designed to keep available in most situations. `buf` is not the same thing as the exact current DAI balance, and `fill()` / `trim()` do not simply compare `dai.balanceOf(psm)` to `buf`.
The core contract computes its target debt as:
```
targetArt = gem.balanceOf(pocket) * to18ConversionFactor + buf
```
Two permissionless functions use this target together with the local and global debt ceilings:
* **`fill()`** — mints `rush()` DAI from the Maker Vat into the core PSM when additional DAI can be generated under the target and debt-ceiling constraints.
* **`trim()`** — burns `gush()` DAI and repays Vat debt when the core PSM has excess debt or needs to reduce debt against the target.
Both functions are typically called by automated keeper jobs and are not part of the normal swap path. From an integrator's perspective, the sell-side capacity for USDC → USDS is the actual external DAI balance of the core PSM:
```
dai.balanceOf(address(wrapper.psm()))
```
That balance can be below, equal to, or above `buf`. For large routes, read the live DAI balance and account for same-block `fill()`, `trim()`, `chug()`, and competing swaps.
### The Pocket
USDC is not held in the LitePSM contract itself. It is held in a separate **Pocket** address ([0x37305B...D7341](https://etherscan.io/address/0x37305B1cD40574E4C5Ce33f8e8306Be057fD7341)), which has granted the core `DssLitePsm` a max allowance to move USDC during `buyGem` calls. This decoupling has two consequences:
1. **Buy-side liquidity** is exactly `gem.balanceOf(pocket)`. Integrators should read this directly when sizing routes.
2. **The pocket address is immutable in the deployed core PSM.** The current PSM cannot reassign `pocket` through a `file` call; changing that address would require deploying or migrating to a different PSM/wrapper setup.
The Pocket is a Coinbase Custody account with a private key that was burned with a [heavily witnessed key generation and burning ceremony](https://forum.skyeco.com/t/coinbase-web3-wallet-legal-overview/24577#p-97770-key-shard-generation-handling-agreement-15). The idea is that the only transaction made on this Custody account was an infinite approval to the PSM contract, which allows adding and removing funds. After that transaction was complete, both Coinbase's and Sky's keys were permanently destroyed.
### Fees
The PSM exposes two fee parameters in WAD precision (where `1e18 = 100%`):
* **`tin`** — fee applied when a user sells USDC for DAI/USDS.
* **`tout`** — fee applied when a user buys USDC with DAI/USDS.
Both are currently **0**. Accrued fees stay in the contract as DAI and are swept to the Maker Vow (surplus buffer) by a permissionless `chug()` call.
### Halts and Failure Modes
:::warning
The LitePSM has a documented set of states and external dependencies that can cause swaps to fail. Integrators should handle these defensively.
:::
* **Direction halt.** Sky governance, or the `DssLitePsmMom` emergency contract, can set `tin` or `tout` to `type(uint256).max` (the `HALTED` sentinel). When set, the corresponding direction reverts. Read `tin()` and `tout()` before quoting and reject if either equals `type(uint256).max`.
* **Pocket depletion.** If `gem.balanceOf(pocket)` is below the requested `gemAmt`, `buyGem` reverts. Check pocket balance before routing buy-side liquidity.
* **USDC blacklisting.** USDC has an admin-controlled blacklist. If Circle blacklists the pocket or the wrapper, swaps in the affected direction revert at the USDC transfer step.
* **Debt ceiling exhaustion.** If the Maker Vat debt ceiling for the LitePSM ilk is exhausted, `fill()` reverts and sell-side liquidity stops replenishing. Swaps continue to work against the existing buffer until it is drained.
* **Vat cage / global settlement assumptions.** `live()` is a compatibility getter that returns `vat.live()`. The swap functions do not check this flag directly, and the ChainSecurity audit notes that `DssLitePsm` does not support coordinated Global Settlement. Treat any Vat cage or settlement state as unsupported for normal integrations.
### Decimals
USDC has 6 decimals. USDS and DAI have 18 decimals. The PSM uses a constant `to18ConversionFactor = 10^12` to translate between them.
Both `sellGem` and `buyGem` take `gemAmt` in **USDC decimals** (6). The functions return DAI/USDS amounts in **WAD** (18 decimals).
Worked example — selling 1 USDC for USDS with `tin = 0`:
```
gemAmt = 1_000_000 (1 USDC, 6 decimals)
usdsOut = gemAmt * 10^12 (scale to WAD)
= 1_000_000_000_000_000_000 (1 USDS, 18 decimals)
```
With a non-zero `tin`, the output is reduced proportionally:
```
usdsOut = gemAmt * 10^12 * (WAD - tin) / WAD
```
For `buyGem`, the **input** USDS amount is increased by `tout`:
```
usdsIn = gemAmt * 10^12 * (WAD + tout) / WAD
```
## Sky LitePSM
### Introduction
The Sky LitePSM is Ethereum mainnet stablecoin swap infrastructure for fixed-rate USDC swaps. The core `DssLitePsm` swaps USDC against DAI, while Sky's `UsdsPsmWrapper` exposes the USDS-facing USDC ↔ USDS interface most integrators should use. Today the public fees are zero, but `tin` and `tout` are governance-controlled parameters and should be read on-chain before quoting.
Architecturally, the LitePSM minimizes per-swap gas overhead by keeping a pre-minted DAI balance in the core PSM instead of touching the Maker core accounting contract (`Vat`) on every user trade. USDC custody sits in a separate immutable pocket address, and live route capacity must be read from the core PSM's DAI balance and the pocket's USDC balance.
For contract-level integrations on Ethereum mainnet, this is the canonical Sky USDC ↔ USDS fixed-rate route. It provides deterministic pricing without AMM curve math, but it still has mutable fees, halt states, finite per-block liquidity, and external token dependencies that integrators need to handle.
### Role in Spark
The LitePSM is an important piece of infrastructure for Spark because it makes USDS highly liquid against USDC on Ethereum mainnet. By connecting USDS to billions of dollars of USDC liquidity in the Sky PSM pocket, it gives Spark products access to a deep fixed-rate USDS ↔ USDC conversion path.
Spark uses this liquidity in the [Swap](/user-guides/swap/) product for USDS and USDC conversion, and in [SparkLend](/products/sparklend) for the **USDC via USDS** market.
### Key Contracts
| Contract | Address |
| --------------------------------------- | --------------------------------------------------------------------------------------------------------------------- |
| `UsdsPsmWrapper` (USDS-USDC) | [0xA188EEC8F81263234dA3622A406892F3D630f98c](https://etherscan.io/address/0xA188EEC8F81263234dA3622A406892F3D630f98c) |
| `DssLitePsm` / `LITE-PSM-USDC-A` (core) | [0xf6e72Db5454dd049d0788e411b06CfAF16853042](https://etherscan.io/address/0xf6e72Db5454dd049d0788e411b06CfAF16853042) |
| Pocket (USDC custody) | [0x37305B1cD40574E4C5Ce33f8e8306Be057fD7341](https://etherscan.io/address/0x37305B1cD40574E4C5Ce33f8e8306Be057fD7341) |
Integrators swapping between USDS and USDC should call the **`UsdsPsmWrapper`**. The wrapper internally routes through the DAI-denominated core LitePSM and uses the Maker `DaiJoin`/`UsdsJoin` adapters to convert between external DAI/USDS balances and internal Vat balances, while exposing a USDS-native `sellGem`/`buyGem` interface.
:::warning
**Not to be confused with the Spark PSM.** This documentation covers the **Sky LitePSM**, deployed on Ethereum mainnet. The [Spark PSM](/dev/savings/spark-psm) is a separate contract (PSM3) deployed by Spark on Base and Arbitrum to provide cross-chain USDC ↔ USDS ↔ sUSDS swapping. Different chains, different contracts, different mechanics.
:::
### What's Next
* [How It Works](/dev/integration-guides/litepsm/how-it-works) — the swap mechanism, pre-minted buffer, immutable pocket model, and fee parameters.
* [Contract Reference](/dev/integration-guides/litepsm/contract-reference) — deployment addresses, ABI, state variables, and events.
* [Integration Guide](/dev/integration-guides/litepsm/integration-guide) — step-by-step swap flows with Solidity examples and liquidity checks.
## Integration Guide
This guide shows how to integrate the [`UsdsPsmWrapper`](/dev/integration-guides/litepsm/contract-reference#usdspsmwrapper-usds-usdc) into a smart contract or off-chain routing system. Addresses, source links, audits, and the full ABI are maintained in the [Contract Reference](/dev/integration-guides/litepsm/contract-reference).
For background on the underlying mechanism, see [How It Works](/dev/integration-guides/litepsm/how-it-works).
:::warning
The Solidity below is a reference adapter pattern, not audited production code. Keep user-facing min/max controls, read fees and liquidity immediately before execution, and verify the deployed wrapper/core addresses in your own deployment configuration.
:::
### Quick Reference
Use the deployed wrapper ABI, not the core `DssLitePsm` ABI, when integrating USDS ↔ USDC directly. The adapter example below includes the minimal interface it needs.
| Direction | Wrapper call | Input token | Output token | Approval target | Liquidity check |
| ----------- | ---------------------------- | ----------------- | ----------------- | ------------------------------ | ---------------------------------------- |
| USDC → USDS | `sellGem(recipient, gemAmt)` | USDC, 6 decimals | USDS, 18 decimals | Wrapper, for `gemAmt` USDC | Canonical DAI balance at `wrapper.psm()` |
| USDS → USDC | `buyGem(recipient, gemAmt)` | USDS, 18 decimals | USDC, 6 decimals | Wrapper, for returned `usdsIn` | USDC balance at `wrapper.pocket()` |
`gemAmt` is always the USDC amount in 6-decimal units. The return value is always the 18-decimal stablecoin amount: `usdsOut` for sells and `usdsIn` for buys.
```text
USDC → USDS
caller/adapter ── USDC ──► UsdsPsmWrapper ──► core DssLitePsm ──► DaiJoin/UsdsJoin ──► USDS recipient
USDS → USDC
caller/adapter ── USDS ──► UsdsPsmWrapper ──► DaiJoin/UsdsJoin ──► core DssLitePsm ──► USDC recipient
```
### Adapter Pattern
This example uses OpenZeppelin Contracts 5.x. It assumes the adapter does not custody idle balances. It pulls the exact token amount needed for each call, approves the wrapper for the exact spend, and clears the allowance after the swap.
```solidity
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;
import {IERC20} from "@openzeppelin/contracts/token/ERC20/IERC20.sol";
import {SafeERC20} from "@openzeppelin/contracts/token/ERC20/utils/SafeERC20.sol";
import {Math} from "@openzeppelin/contracts/utils/math/Math.sol";
import {ReentrancyGuard} from "@openzeppelin/contracts/utils/ReentrancyGuard.sol";
interface IUsdsPsmWrapper {
function sellGem(address usr, uint256 gemAmt) external returns (uint256 usdsOutWad);
function buyGem(address usr, uint256 gemAmt) external returns (uint256 usdsInWad);
function psm() external view returns (address);
function pocket() external view returns (address);
function tin() external view returns (uint256);
function tout() external view returns (uint256);
function to18ConversionFactor() external view returns (uint256);
}
contract UsdsPsmWrapperAdapter is ReentrancyGuard {
using SafeERC20 for IERC20;
uint256 internal constant WAD = 1e18;
uint256 internal constant HALTED = type(uint256).max;
IUsdsPsmWrapper public immutable wrapper;
IERC20 public immutable usdc;
IERC20 public immutable usds;
IERC20 public immutable dai; // Canonical DAI token, not wrapper.dai().
error ZeroAddress();
error SellHalted();
error BuyHalted();
error FeeTooHigh();
error InsufficientSellLiquidity(uint256 requested, uint256 available);
error InsufficientBuyLiquidity(uint256 requested, uint256 available);
error InsufficientOutput(uint256 received, uint256 minimum);
error ExcessiveInput(uint256 required, uint256 maximum);
constructor(IUsdsPsmWrapper wrapper_, IERC20 usdc_, IERC20 usds_, IERC20 dai_) {
if (
address(wrapper_) == address(0) ||
address(usdc_) == address(0) ||
address(usds_) == address(0) ||
address(dai_) == address(0)
) {
revert ZeroAddress();
}
wrapper = wrapper_;
usdc = usdc_;
usds = usds_;
dai = dai_;
}
function previewSellGem(uint256 gemAmt) public view returns (uint256 usdsOutWad) {
uint256 tin = wrapper.tin();
if (tin == HALTED) revert SellHalted();
if (tin >= WAD) revert FeeTooHigh();
uint256 gemAmt18 = Math.mulDiv(gemAmt, wrapper.to18ConversionFactor(), 1);
return Math.mulDiv(gemAmt18, WAD - tin, WAD);
}
function previewBuyGem(uint256 gemAmt) public view returns (uint256 usdsInWad) {
uint256 tout = wrapper.tout();
if (tout == HALTED) revert BuyHalted();
if (tout > WAD) revert FeeTooHigh();
uint256 gemAmt18 = Math.mulDiv(gemAmt, wrapper.to18ConversionFactor(), 1);
return gemAmt18 + Math.mulDiv(gemAmt18, tout, WAD);
}
function maxSellGem() public view returns (uint256 gemAmt) {
uint256 tin = wrapper.tin();
if (tin == HALTED || tin >= WAD) return 0;
uint256 denominator = wrapper.to18ConversionFactor() * (WAD - tin);
return Math.mulDiv(dai.balanceOf(wrapper.psm()), WAD, denominator);
}
function maxBuyGem() public view returns (uint256 gemAmt) {
if (wrapper.tout() == HALTED) return 0;
return usdc.balanceOf(wrapper.pocket());
}
function sellUsdcForUsds(
uint256 gemAmt,
uint256 minUsdsOut,
address recipient
) external nonReentrant returns (uint256 usdsOut) {
if (recipient == address(0)) revert ZeroAddress();
uint256 expectedOut = previewSellGem(gemAmt);
if (expectedOut < minUsdsOut) revert InsufficientOutput(expectedOut, minUsdsOut);
uint256 sellCapacity = maxSellGem();
if (gemAmt > sellCapacity) revert InsufficientSellLiquidity(gemAmt, sellCapacity);
usdc.safeTransferFrom(msg.sender, address(this), gemAmt);
usdc.forceApprove(address(wrapper), gemAmt);
usdsOut = wrapper.sellGem(recipient, gemAmt);
usdc.forceApprove(address(wrapper), 0);
if (usdsOut < minUsdsOut) revert InsufficientOutput(usdsOut, minUsdsOut);
}
function buyUsdcWithUsds(
uint256 gemAmt,
uint256 maxUsdsIn,
address recipient
) external nonReentrant returns (uint256 usdsIn) {
if (recipient == address(0)) revert ZeroAddress();
uint256 requiredIn = previewBuyGem(gemAmt);
if (requiredIn > maxUsdsIn) revert ExcessiveInput(requiredIn, maxUsdsIn);
uint256 buyCapacity = maxBuyGem();
if (gemAmt > buyCapacity) revert InsufficientBuyLiquidity(gemAmt, buyCapacity);
uint256 balanceBefore = usds.balanceOf(address(this));
usds.safeTransferFrom(msg.sender, address(this), requiredIn);
usds.forceApprove(address(wrapper), requiredIn);
usdsIn = wrapper.buyGem(recipient, gemAmt);
usds.forceApprove(address(wrapper), 0);
if (usdsIn > maxUsdsIn) revert ExcessiveInput(usdsIn, maxUsdsIn);
uint256 balanceAfter = usds.balanceOf(address(this));
if (balanceAfter > balanceBefore) {
usds.safeTransfer(msg.sender, balanceAfter - balanceBefore);
}
}
}
```
### Production Checklist
Before executing a route, check direction-specific state in the same transaction path:
* **USDC → USDS**: reject if `tin() == type(uint256).max`; reject if `tin() >= 1e18`; ensure `gemAmt <= maxSellGem()`.
* **USDS → USDC**: reject if `tout() == type(uint256).max`; ensure `gemAmt <= maxBuyGem()`.
* **User protection**: always take `minUsdsOut` for sells and `maxUsdsIn` for buys, even though the PSM itself has no slippage parameter.
* **Token approvals**: approve the wrapper only for the exact token amount the adapter is about to spend, and clear the allowance after the call.
* **DAI balance reads**: use the canonical DAI token to read `dai.balanceOf(wrapper.psm())`. Do not use `wrapper.dai()` for this; the deployed wrapper's compatibility getter returns USDS.
* **Address configuration**: configure the wrapper, USDC, USDS, and canonical DAI addresses explicitly. Do not infer DAI from the wrapper.
The PSM price is deterministic, but route execution can still fail because fees, halts, DAI balance, pocket balance, and token transfer permissions are live chain state.
### Large Trades
USDS → USDC capacity is the pocket's live USDC balance. USDC → USDS capacity is the core PSM's live DAI balance after applying `tin`.
For a USDC → USDS route larger than the current DAI balance, use one of these strategies:
| Strategy | When to use |
| -------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Refuse the quote | Default for simple integrations and frontends. |
| Split the route | Useful when the user can tolerate multiple transactions or partial routing through other venues. |
| Bundle `fill()` atomically | Advanced integrations only. The core `fill()` function is permissionless, but the batch still needs to handle debt-ceiling limits, same-block competition, and revert risk. |
Do not quote against the governance debt ceiling as if it were immediately available liquidity. Quote against the actual DAI balance unless your transaction path explicitly includes and validates a `fill()`.
### Off-Chain Routers
For quoting engines and aggregators, model LitePSM as a stateful fixed-price venue rather than an AMM:
* Re-read `tin`, `tout`, `to18ConversionFactor`, `dai.balanceOf(wrapper.psm())`, and `usdc.balanceOf(wrapper.pocket())` per block.
* Do not quote USDC → USDS above the core PSM's live DAI balance converted through the current `tin`.
* Do not quote USDS → USDC above the pocket's live USDC balance.
* Treat `tin` and `tout` independently; one direction can be halted while the other remains available.
* Keep a user min/max guard in the final transaction calldata or wrapping contract.
Live protocol stats are available from the [LitePSM dashboard](https://litepsm.blockanalitica.com/). Treat dashboard data as monitoring context; execution checks should still read on-chain state.
### Troubleshooting
| Symptom | Likely cause | Check |
| ------------------------------ | --------------------------------------------------------------------- | ---------------------------------------------------------- |
| USDC → USDS reverts | Sell direction halted | `wrapper.tin() == type(uint256).max` |
| USDC → USDS reverts | Not enough DAI in the core PSM | `dai.balanceOf(wrapper.psm())` |
| USDS → USDC reverts | Buy direction halted | `wrapper.tout() == type(uint256).max` |
| USDS → USDC reverts | Not enough USDC in the pocket | `usdc.balanceOf(wrapper.pocket())` |
| Quote changes before execution | Governance fee update or competing transaction | Re-read `tin`, `tout`, and balances in the execution path |
| DAI balance looks wrong | Reading `wrapper.dai()` instead of canonical DAI | Use the DAI token address directly |
| Token transfer fails | Missing allowance, insufficient balance, or USDC transfer restriction | Check token balances, allowances, and USDC transfer status |
### UI Example: USDC via USDS
SparkLend may present a user-facing market where users interact with **USDC via USDS**. This is useful product context for understanding how USDS-backed USDC liquidity can appear in Spark interfaces.
*SparkLend market: USDC via USDS*
```text
User-facing market: USDC via USDS
│
▼
USDS-denominated source or debt
│
▼
Sky UsdsPsmWrapper
│
├── Core DssLitePsm + USDC pocket
│
▼
USDC delivered to recipient
```
The relevant contract primitive for a generic USDS → USDC leg is `wrapper.buyGem(recipient, gemAmt)`.
## Deployments
### Spark Deployments
The Spark Address Registry contains addresses of all smart contracts used in the Spark ecosystem. Find all addresses for each network in this repository:
* [**Spark Address Registry**](https://github.com/sparkdotfi/spark-address-registry/tree/master/src).
### Sky Deployments
The Sky Chainlog contains addresses of all smart contracts used in the Sky ecosystem.
* [**Sky Chainlog**](https://chainlog.sky.money/)
## Spark Brand Assets | Press Kit
Welcome to the Spark Brand Kit. Here you will find logos, banners, colors and visuals from Spark.
### Download All Brand Assets
:::tip[Download Brand Assets]
[Download the complete Spark brand assets package](https://drive.google.com/uc?export=download\&id=1581UgpXKufdI4_p-Ad7aBj0gVY-gUwXA)
:::
You can also find all the brand assets in this [Google Drive folder](https://drive.google.com/drive/folders/1mknRFyo4VfVpAT-Lhh6-hGbxRnJ1RnAY?usp=sharing).
### Brand Guidelines
Download the brand guidelines here: [Spark Brand Guidelines](https://drive.google.com/file/d/1qMl3aVagyv_wlNv_4f3PD6COq12dxi3l/view?usp=drive_link)
### Spark Logo
:::info
Logos are best viewed in light mode.
:::
### Spark Logomark
### Spark Badge
### SPK Token
### Spark Products
#### Savings
#### sUSDS
#### sUSDC
#### Spark Liquidity Layer
#### SparkLend
### Colors
See [Brand Guidelines](#brand-guidelines) for color usage.
### Typography
See [Brand Guidelines](#brand-guidelines) for font usage.
#### Roobert
Primary typeface for Spark.
* License Required - [See here](https://displaay.net/typeface/roobert-collection/roobert/)
#### Inter
Secondary typeface for Spark.
Used for body text and captions.
* Free - [See here](https://fonts.google.com/specimen/Inter)
## SPK Cookie.fun Airdrop
The Spark SNAPS airdrop rewarded users who demonstrated significant participation in the Spark SNAPS campaign on the [Cookie.fun platform](https://cookie.fun/tokens/spark). The campaign initiative was aimed at driving community engagement and awareness. The campaign ran from May 22, 2025 5pm UTC to June 24, 2025 14:00 UTC.
### How many SPK tokens were allocated to the Cookie.fun campaign Airdrop?
The total SPK allocated to the Spark SNAPS airdrop was approximately 5 million SPK. It was distributed to the top 500 SNAPPERS in the Spark SNAPS campaign based on engagement metrics provided by Cookie.fun, with these top 500 SNAPPERS grouped by the top 25th percentile, mid 50th percentile and bottom 25th percentile.
Tokens were allocated to these three groups as follows, and were distributed to users within each group *pro rata* based on the user's total number of SNAPS relative to other users in the group:
* Top 25th percentile (users with 63.2-125.2 SNAPS): 2,255,425 total SPK
* Mid 50th percentile (users with 23.2-63.1 SNAPS): 2,012,651 total SPK
* Bottom 25th percentile (users with 5.7-23.1 SNAPS): 718,568 total SPK
### How did users qualify for the Spark SNAPS airdrop?
To qualify for the Spark SNAPS airdrop, in addition to meeting the criteria above and any other general eligibility criteria, users had to have also supplied an eligible wallet address to Cookie.fun during the campaign period.
### Claiming Deadline
The claiming period ran until December 17, 2025 at 14:00 UTC and has ended. Any SPK which remained unclaimed was returned to the ecosystem treasury.
### Important Notes
Airdrop amounts were determined based upon Cookie.fun engagement metrics. These determinations are final, per the [Airdrop Terms & Conditions](/airdrop/terms).
## SPK Ignition Airdrop
Spark ran an airdrop campaign to reward users who participated in various DeFi activities across multiple chains. The campaign consisted of two phases: the main Ignition airdrop and an optional Overdrive phase where users could boost their airdrop amount.
### How many SPK tokens are allocated to Ignition?
A total of 325,485,000 SPK tokens were allocated to the Ignition airdrop campaign. Tokens which remained unclaimed at the end of the Ignition claiming period were distributed in the Overdrive airdrop as specified in the Overdrive rules. [You can find more info on the Overdrive airdrop here](/airdrop/overdrive).
### How did users qualify for the Ignition airdrop?
Users could qualify for the Ignition airdrop by meeting one or more of the following criteria. Each criterion met earned users one "Ignition unit". Users' final SPK allocation was proportional to their total Ignition units relative to the units of all qualifying users.
#### Qualification Criteria
##### Stablecoin Holdings
* **USDS, sUSDS, sUSDC, sDAI, or SAI Holdings**
* Hold at least $1,000 total across any of these tokens on any of the snapshot dates
* Snapshot dates: April 15, 2023, April 15, 2024, April 15, 2025 - all 23:59:59 UTC
* Qualifying chains: Mainnet, Base, Arbitrum
* Possible units: One for each of the four listed tokens
* **xDAI Holdings**
* Hold at least 1,000 xDAI on any of the snapshot dates
* Snapshot dates: April 15, 2023, April 15, 2024, April 15, 2025 - all 23:59:59 UTC
* Qualifying chains: Gnosis
* Possible units: One
* **DAI Holdings**
* Hold at least $10,000 in DAI on any of the snapshot dates
* Snapshot dates: April 15, 2023, April 15, 2024, April 15, 2025 - all 23:59:59 UTC
* Qualifying chains: Mainnet, Base, Arbitrum, Optimism, Polygon
* Possible units: One
##### SparkLend Activity
* **SparkLend Supply**
* Supply over $100 in a single transaction into SparkLend
* Deadline: On or prior to April 15, 2025 23:59:59 UTC
* Qualifying chains: Mainnet, Gnosis
* Possible units: One
##### Lending Platform Activity
* **Aave Lending**
* Lend at least $5,000 in aggregate across USDS, sUSDS, USDT, USDC, USDe, sUSDe, DAI, or sDAI
* Snapshot date: March 15, 2025 23:59:59 UTC
* Qualifying chains: Mainnet, Base, Arbitrum, Polygon, Optimism, Gnosis
* Possible units: One
* **Morpho Lending**
* Lend at least $5,000 in aggregate across USDS, sUSDS, USDT, USDC, USDe, sUSDe, DAI, or sDAI
* Snapshot date: March 15, 2025 23:59:59 UTC
* Qualifying chains: Mainnet, Base, Polygon
* Possible units: One
* **Fluid Lending**
* Lend at least $5,000 in aggregate across USDS, sUSDS, USDT, USDC, USDe, sUSDe, DAI, or sDAI
* Snapshot date: March 15, 2025 23:59:59 UTC
* Qualifying chains: Mainnet, Arbitrum, Base, Polygon
* Possible units: One
##### Other DeFi Activities
* **Pendle PT, YT, or LP Holdings**
* Hold at least $5,000 in aggregate in Pendle PT, YT, or LP in top 3 markets by TVL on the snapshot date
* Snapshot date: March 15, 2025 23:59:59 UTC
* Qualifying chains: Mainnet
* Possible units: One
* **Ethena Holdings**
* Hold at least $5,000 in Ethena sUSDe or USDe
* Snapshot date: March 15, 2025 23:59:59 UTC
* Qualifying chains: Mainnet
* Possible units: One for each of the two listed tokens
* **Curve 3pool LP**
* Supply at least $5,000 as a Curve 3pool LP
* Snapshot date: March 15, 2025 23:59:59 UTC
* Qualifying chains: Mainnet
* Possible units: One
* **Pendle vePENDLE**
* Hold at least $5,000 in Pendle vePENDLE
* Snapshot date: March 15, 2025 23:59:59 UTC
* Qualifying chains: Mainnet
* Possible units: One
### Claiming Period
The claim period for Ignition airdrop tokens ran from June 17, 2025 - 08:00 UTC to July 29, 2025 - 14:00 UTC. The claiming period ended on July 29, 2025. Unclaimed SPK tokens were allocated to the Overdrive phase. Please see Overdrive rules for more details.
### Which networks qualified for the Ignition airdrop?
The Ignition airdrop rewarded activity across multiple networks, including:
* Ethereum Mainnet
* Base
* Arbitrum
* Optimism
* Gnosis
* Polygon
Note that only specific activities on a given network may have qualified for Ignition units. Please refer to the specific qualification criteria above for more details.
Claiming SPK was only possible on Ethereum Mainnet.
### Important Notes
* All qualifying amounts are denominated in USD and were calculated using Dune pricing at the time of the snapshot.
* Users who qualified for multiple criteria received more Ignition units.
* Each user's Ignition airdrop amount was proportional to their total Ignition units relative to the units of all qualifying users.
## SPK Airdrop
Spark airdropped SPK tokens to three main categories of users:
* [Pre-Farming](/airdrop/pre-farm): Based on lending/borrowing activity on SparkLend and Aave during the pre-farming period.
* [Spark Ignition](/airdrop/ignition) & [Overdrive](/airdrop/overdrive): Based on participation in specified DeFi activities on specific snapshot dates, with an option to boost rewards.
* [Layer3](/airdrop/layer3): Based on participation in Spark's Quests on the Layer3 platform.
You can read more about each campaign in the following pages, or by clicking the links above.
### Airdrop Status
The SPK airdrop has concluded. All claiming periods have ended, with the final claiming date being December 17th, 2025. The airdrop is no longer claimable. Do not trust any websites or platforms claiming to offer SPK tokens or access to claims. Beware of scammers and false SPK tokens.
### Eligibility
In addition to any eligibility requirements for a particular phase of the Airdrop, to have been eligible, you had to be at least 18 years of age and not an individual or entity subject to national or international sanctions or otherwise designated on any list of prohibited or restricted parties, including but not limited to the lists maintained by the United Kingdom, the United Nations, the European Union or its Member States, the United States, or other applicable government authority. Please read the [Spark Airdrop Terms and Conditions](/airdrop/terms) and the requirements for each airdrop phase for more information.
### Claiming Periods
The table below outlines all the claiming periods for all SPK airdrop campaigns. All claiming periods have now ended. Note times were in 24h UTC format.
| **Airdrop** | **Claiming starts** | **Claiming ends** |
| ----------- | --------------------------- | ----------------------------- |
| Ignition | June 17, 2025 - 08:00 UTC | July 29, 2025 - 14:00 UTC |
| Overdrive | August 12, 2025 - 14:00 UTC | December 17, 2025 - 14:00 UTC |
| Layer3 | June 17, 2025 - 08:00 UTC | December 17, 2025 - 14:00 UTC |
| Pre-farming | June 17, 2025 - 08:00 UTC | December 17, 2025 - 14:00 UTC |
| Cookie.fun | June 26, 2025 - 14:00 UTC | December 17, 2025 - 14:00 UTC |
### Important Notes
* The airdrop claiming period has ended. The claim interface is no longer available.
* Official announcements were made through the official X account of [Spark (@sparkdotfi)](https://x.com/sparkdotfi).
* Beware of scammers and fake claiming websites.
* You can find the full terms and conditions for the airdrop [here](/airdrop/terms).
### Markets In Crypto-Assets Regulation (MiCA) Information
Please see [spark.fi/mica](http://spark.fi/mica) for Spark's crypto-asset white paper and other relevant information.
## SPK Layer3 Airdrop
The Layer3 airdrop rewarded users who participated in Spark's learning campaign on the Layer3 platform. This initiative aimed to educate users about Spark's ecosystem.
### How many SPK tokens were allocated to the Layer3 campaign Airdrop?
The total SPK allocation for the Layer3 airdrop was 500,000 SPK, and was evenly distributed amongst all users who completed all four quests on Layer3.
### How did users qualify for the Layer3 airdrop?
To qualify for the Layer3 airdrop, users had to have completed all four of Spark's Quests on the Layer3 platform during the qualification period.
### Claiming Period
The claim period for Layer3 SPK tokens ran from June 17, 2025 - 08:00 UTC to December 17, 2025 - 14:00 UTC. The claiming period ended on December 17, 2025. Any unclaimed SPK tokens were returned to the ecosystem treasury.
### Could users still participate in the Layer3 Campaign?
No, the Layer3 campaign ran from March 7, 2025 to April 7, 2025. The campaign has ended.
## SPK Overdrive Airdrop
Overdrive was the second phase of the Ignition airdrop series, where Ignition claimants had an option to qualify for a second airdrop. The Ignition airdrop phase lasted from the airdrop date to six weeks after the airdrop date. After this period, Ignition recipients were no longer able to claim their airdrop. SPK which was unclaimed after that period was allocated for distribution to participants in Overdrive as follows. For simplicity, the following dates have the following IDs:
* `DATE_1`: July 29, 2025 - 14:00 UTC
* `DATE_2`: August 11, 2025 - 14:00 UTC
### How did users qualify for the Overdrive airdrop?
To qualify for Overdrive, users had to stake their Ignition SPK during the Overdrive period as explained below.
#### Official Overdrive Qualification Rules:
1. User must have claimed their Ignition airdrop before the claiming deadline.
2. Users had to *stake* *at least* *their total allocation of SPK from the Ignition airdrop* by `DATE_1` using the same wallet that qualified for the corresponding Ignition airdrop.
3. This staked SPK *had to remain staked* until `DATE_2`.
4. This staked SPK *could not be in cooldown at any point* from `DATE_1` to `DATE_2`.
5. The above rules only applied to the amount of SPK that was earned from the Ignition airdrop for a given wallet. Unstaking SPK that was earned in another way did not impact Overdrive eligibility.
6. Similarly, staking more SPK than was received in the Ignition airdrop did not translate to a higher Overdrive airdrop amount. The Overdrive amount was based on the user's Ignition airdrop amount only.
### What was Overdrive Boosting?
Users that qualified for Overdrive could boost their Overdrive airdrop amount by using Spark Savings during the Overdrive period.
#### Official Boost Qualification Rules:
1. Users had to have *at least* 1,000 USDS or USDC in Spark Savings associated with the same wallet they used to claim the Ignition airdrop by `DATE_1`.
2. This minimum amount had to *remain* in Spark Savings continuously from `DATE_1` to `DATE_2`.
3. Users that were *already saving* the minimum amount of USDS or USDC in Spark Savings before Overdrive began *did not have to take any action* and could still qualify if they met the two requirements above.
### How was Overdrive SPK distributed?
Overdrive SPK was distributed from the pool of unclaimed SPK from the Ignition phase to all qualifying users in the Overdrive phase proportional to how many "Overdrive units" they had.
Overdrive units were calculated as follows:
1. Base Units:
* Users received 1 "Overdrive unit" for each SPK token received in Ignition that was staked for the entire Overdrive period (`DATE_1` to `DATE_2`).
2. Boost Option:
* Users could double their Overdrive units by boosting as described above.
3. Max Amount:
* As a contingency measure for low airdrop participation, the max amount of SPK that each user could receive from their Overdrive airdrop was 10x the amount that they received from their Ignition airdrop.
* In this situation, any remaining SPK after the Overdrive airdrop was complete would go back to the Spark treasury.
Overdrive participants received SPK in an amount proportional to their Overdrive units relative to the Overdrive units of other participants, with a max of 10x their Ignition airdrop amount:
### When was the Overdrive period?
The Overdrive period ran from July 29, 2025 - 14:00 UTC to August 11, 2025 - 14:00 UTC.
### Claiming Period
The claim period for Overdrive SPK tokens ran from August 12, 2025 - 14:00 UTC to December 17, 2025 - 14:00 UTC. The claiming period ended on December 17, 2025. Any Overdrive SPK tokens which remained unclaimed were returned to the ecosystem treasury.
## SPK Pre-Farming Airdrop
Spark's pre-farming airdrop campaign rewarded users based on usage of SparkLend and AAVE on Ethereum mainnet. Select users of those platforms during the pre-farming period received an airdrop, depending on how much and how long they used either platform during specific periods, also known as "seasons." See further details on [qualification criteria](#how-do-i-qualify-for-the-spk-airdrop) for the airdrop, and the [different seasons](#season-1-aug-20-2023-may-20-2024) below.
### How much SPK is allocated to pre-farming users?
SPK for pre-farming is allocated as follows:
* Season 1 (Aug 20, 2023 - May 20, 2024):
* 130,434,783 SPK
* Season 2 pool (May 20, 2024 - June 16, 2025):
* SparkLend: 14,478,261 SPK per month (prorated on a per-second basis from May 2024 and onwards)
* Aave: 7,239,130 SPK per month (prorated on a per-second basis from May 2024 and onwards)
### How is SPK distributed to pre-farming users?
#### **Season 1**
* 80% of Season 1 SPK allocation is distributed *pro rata* to users borrowing DAI and 20% is distributed *pro rata* to users supplying ETH during the Season 1 time period.
* Season 1 calculations are based on the qualifying amount and total duration supplied.
:::info
**Note:** only activities on Ethereum mainnet are counted.
:::
#### **Season 2**
* SparkLend: 80% of Season 2 SparkLend allocation is distributed *pro rata* to users borrowing USDS or DAI and 20% is distributed *pro rata* to users supplying ETH during the Season 2 time period.
* Aave: Season 2 Aave allocation is distributed *pro rata* to users who supplied USDS into Aave during the Season 2 time period.
Season 2 calculations are done per block, based on the qualifying amount supplied in each block.
:::info
**Note:** only activities on Ethereum mainnet are counted.
:::
### Claiming Period
The claim period for pre-farming SPK ran from June 17, 2025 - 08:00 UTC until December 17, 2025 - 14:00 UTC. The claiming period ended on December 17, 2025. Any SPK which was not claimed during that period has been returned to the Spark ecosystem treasury.
### Excluded behaviors and "anti-cheat" formulas
To ensure a fair airdrop, certain behaviors disqualified users from the pre-farming airdrop, including:
* **SparkLend**: Lending sDAI while borrowing DAI or lending and borrowing ETH on the same account
* **Aave**: "stablecoin looping" (i.e., supplying USDS and borrowing DAI or USDS and supplying USDS again, effectively providing a highly leveraged USDS position)
Details on the anti-cheat formulas are below.
#### **SparkLend Anti-cheat formula**
Below is the anti-cheat formula applied to screen for excluded behavior on SparkLend (don't worry about this if you used the system legitimately):
`Airdrop = 80% * (DAI Borrows + USDS Borrows - sDAI Supplies * sDAI Liquidation Threshold - sUSDS Supplies * sUSDS Liquidation Threshold) + 20% * (ETH Supplies - ETH Borrows / ETH Liquidation Threshold)`
For clarity, here are some **valid examples:**
* ✅ Supply wstETH, Borrow USDS - USDS amount is included
* ✅ Supply rETH, Borrow USDS - USDS amount is included
* ✅ Supply wstETH, Borrow USDS, Swap USDS for sUSDS - USDS amount is included
* ✅ Supply ETH, Borrow USDS - Both ETH and USDS amounts are included in the airdrop
* ✅ Supply rETH, Supply ETH, Borrow USDS - Both ETH and USDS amounts are included in the airdrop
* ✅ Supply GNO, Borrow USDS - USDS amount is included
* ✅ Supply wstETH, Borrow DAI - DAI amount is included
* ✅ Supply rETH, Borrow DAI - DAI amount is included
* ✅ Supply wstETH, Borrow DAI, Swap DAI for sDAI - DAI amount is included
* ✅ Supply ETH, Borrow DAI - Both ETH and DAI amounts are included in the airdrop
* ✅ Supply rETH, Supply ETH, Borrow DAI - Both ETH and DAI amounts are included in the airdrop
* ✅ Supply GNO, Borrow DAI - DAI amount is included
* ✅ Supply ETH - ETH amount is included
* ✅ Supply ETH, Borrow wstETH - ETH amount is included
**Invalid examples:**
* ❌ Supply sUSDS, Borrow USDS - FORFEIT AIRDROP
* ❌ Supply sUSDS, Borrow DAI - FORFEIT AIRDROP
* ❌ Supply sDAI, Borrow USDS - FORFEIT AIRDROP
* ❌ Supply sDAI, Borrow DAI - FORFEIT AIRDROP
* ❌ Supply ETH, Borrow ETH - FORFEIT AIRDROP
* ❌ Supply wstETH, Borrow USDS, Supply sUSDS as Collateral - FORFEIT AIRDROP
* ❌ Supply wstETH, Borrow USDS, Supply sDAI as Collateral - FORFEIT AIRDROP
* ❌ Supply wstETH, Borrow DAI, Supply sDAI as Collateral - FORFEIT AIRDROP
* ❌ Supply wstETH, Borrow DAI, Supply sUSDS as Collateral - FORFEIT AIRDROP
**Note:** Borrowing DAI and depositing it into sDAI using the Savings feature of Spark is accepted and does not count against the airdrop. It is only penalized if you supply sDAI as collateral to borrow against.
#### Aave Anti-cheat formula
To prevent gaming the incentives through "stablecoin looping", meaning supplying USDS and borrowing DAI or USDS and supplying USDS again, effectively providing a highly leveraged USDS position, the following formula is used to discount such behavior:
`USDS Supplies - Sum_i(USDS+DAI Borrow Amount (in USD) / USDS+DAI Liquidation Threshold)`
## Spark Airdrop Terms and Conditions
These Spark Airdrop Terms and Conditions (“Terms”) govern your participation in Spark’s airdrop of the SPK token (“Airdrop”). The Airdrop is offered and administered solely by SPK Company Ltd. (hereinafter, “we,” “us,” or “our”). By participating in the Airdrop, you agree to these Terms. If you do not agree, you may not participate. These Terms apply in addition to any other rules, policies, procedures and/or other terms and conditions that may apply from time to time with respect to the Tokens.
### Rules and Eligibility
The Airdrop is being offered in multiple phases. More information about each phase may be found at [https://docs.spark.fi/airdrop](https://docs.spark.fi/airdrop), including eligibility criteria, rules of participation, claiming deadlines, and an explanation of how airdrop amounts are being calculated.
In addition to any eligibility requirements for a particular phase of the Airdrop, to be eligible, you must be at least 18 years of age and not an individual or entity subject to national or international sanctions or otherwise designated on any list of prohibited or restricted parties, including but not limited to the lists maintained by the United Kingdom, the United Nations, the European Union or its Member States, the United States, or other applicable government authority.
You may be disqualified from participation in the Airdrop without notice to you if we determine, in our sole discretion, that you have violated these Terms. In addition, we reserve the right to disqualify any participant, wallet address, or transaction that is, in our sole discretion, associated with: suspicious activity; illegal or prohibited conduct; a jurisdiction or individual subject to sanctions or other restrictions; or any wallet address or transaction identified as high risk by blockchain analytics providers. We may rely on third-party data, internal investigations, or any other information available to us in making such determinations, and our decisions shall be final and binding.
### No Purchase Necessary
Participation in the Airdrop is free. No payment or purchase is necessary.
### Claiming
Eligible participants may be able to claim SPK tokens (“Tokens”) based on criteria defined by us. You acknowledge and agree that our determination of your airdrop amount, if any, shall be final and you agree not to contest such determination. You acknowledge and agree that we have no obligation to provide you with any information explaining how we calculated your airdrop amount, if any. Without limiting the generality of the foregoing, you acknowledge that, in determining airdrop amounts, we may rely on data, metrics, or other information provided by third-party sources, including but not limited to wallet addresses, engagement metrics, or other eligibility criteria. We do not independently verify, audit, or validate such data, and we make no representations, warranties, or guarantees as to its accuracy, completeness, or reliability.
Access to claim the Airdrop requires a stable internet connection, a non-custodial wallet, and sufficient ETH to cover network fees on Ethereum mainnet. Participants are solely responsible for meeting these technical requirements and bearing any associated costs.
### Representations and Warranties
By participating in the Airdrop, you represent and warrant that:
* You are at least 18 years old;
* You are not an individual or entity subject to national or international sanctions or otherwise designated on any list of prohibited or restricted parties, including but not limited to the lists maintained by the United Kingdom, the United Nations, the European Union or its Member States, the United States, or other applicable government authority;
* You are solely responsible for determining what, if any, taxes apply to your receipt, holding, or transfer of the Tokens and for reporting and paying such taxes in accordance with the laws of your jurisdiction;
* You are not relying on any representation or warranty, express or implied, not set forth in these Terms, and you have conducted your own due diligence in evaluating participation in the Airdrop;
* You are solely responsible for the security and management of your wallet and private keys;
* You will not use bots, engage in any Sybil attacks, or engage in any fraudulent or unfair conduct in connection with the Airdrop;
* Your participation in the Airdrop shall not constitute or involve the violation of any applicable laws;
* You possess sufficient knowledge and experience in financial and blockchain matters to evaluate the merits and risks of claiming and holding Tokens, and you have conducted your own independent investigation and analysis of the Tokens;
* You have not relied on any representation or warranty made by us or any of our affiliates or representatives other than as expressly set forth in these Terms; and
* You voluntarily and freely accept the risks associated with the use of blockchain technology in connection with the Airdrop, including without limitation smart contract vulnerabilities, transaction delays, and irreversible loss of funds.
### Limitation of Liability
WE SHALL NOT BE LIABLE TO YOU FOR SPECIAL, INDIRECT, CONSEQUENTIAL, OR INCIDENTAL LOSSES OR DAMAGES OF ANY KIND OR NATURE WHATSOEVER, INCLUDING BUT NOT LIMITED TO LOST PROFITS, LOST RECORDS OR DATA, LOST SAVINGS, LOSS OF USE OF FACILITY OR EQUIPMENT, LOSS BY REASON OF FACILITY SHUT-DOWN OR NON-OPERATIONS OF INCREASED EXPENSE OF OPERATIONS, OR OTHER COSTS, CHARGES, PENALTIES, OR LIQUIDATED DAMAGES, REGARDLESS OF WHETHER ARISING FROM BREACH OF CONTRACT, WARRANTY, TORT, STRICT LIABILITY OR OTHERWISE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH LOSS OR DAMAGE OR IF SUCH LOSS COULD HAVE BEEN REASONABLY FORESEEN. OUR LIABILITY FOR DAMAGES HEREUNDER, REGARDLESS OF THE FORM OF ACTION, SHALL NOT EXCEED US$100.
### Indemnification
YOU WILL DEFEND, INDEMNIFY AND HOLD HARMLESS US AND OUR OFFICERS, DIRECTORS, EMPLOYEES, AGENTS AND AFFILIATES FROM AND AGAINST ANY CLAIMS, DISPUTES, DEMANDS, LIABILITIES, DAMAGES, LOSSES, AND COSTS AND EXPENSES, INCLUDING, WITHOUT LIMITATION, REASONABLE LEGAL FEES ARISING OUT OF OR IN ANY WAY CONNECTED WITH YOUR VIOLATION OF THESE TERMS.
### Third Party Rights
Notwithstanding the absence of statutory provisions in the British Virgin Islands permitting third-party enforcement of contract terms, the parties to these Terms expressly agree that any person (or class of persons) identified in these Terms as being entitled to an indemnity or limitation or exclusion of liability (each a “Beneficiary”) shall have the right to enforce the relevant provisions of these Terms as if they were a party to it. The parties to these Terms may rescind, vary, or terminate these Terms (including any term conferring a benefit on any Beneficiary) without the consent of any Beneficiary, provided that such rescission, variation, or termination does not affect any accrued rights of a Beneficiary as at the date of such change.
### Disclaimers
We disclaim all warranties, express or implied, including merchantability, fitness for a particular purpose, and non-infringement. We do not guarantee that you will receive any Tokens, that the Tokens will have any monetary value, or that the Tokens will be listed on any exchange or usable in any application.
### Governing Law; Arbitration
These Terms and any dispute or claim (whether contractual or non-contractual) arising out of or in connection with them or their subject matter or formation (a “Dispute”) shall be governed by and construed in accordance with the laws of the British Virgin Islands.
Any Dispute shall be referred to and finally resolved by arbitration under the BVI IAC Arbitration Rules (the “Rules”), which Rules are deemed to be incorporated by reference into these Terms. The tribunal shall consist of a sole arbitrator appointed in accordance with the Rules. The seat and place of arbitration shall be Road Town, Tortola, British Virgin Islands. The language of the arbitration shall be English.
The award of the tribunal shall be final and binding upon the parties and may be enforced in any court of competent jurisdiction. Judgment on the award may be entered in any such court. Each party irrevocably waives any right it may have to object to the venue or to claim that the proceedings have been brought in an inconvenient forum.
### Markets In Crypto-Assets Regulation (MiCA) Information
Please see [spark.fi/mica](http://spark.fi/mica) for Spark’s crypto-asset white paper and other relevant information.
### Modifications
We may update these Terms at any time without notice. Continued participation after such changes constitutes acceptance.
**Spark Savings Vaults** are ERC-4626 yield-bearing vaults that let anyone deposit a
stablecoin and earn a continuously compounding savings rate, backed by the Sky
ecosystem and the Spark Liquidity Layer. Deposits mint a savings token (e.g.
`spUSDC`, `spUSDT`) whose value grows every second at the vault savings rate — no
staking, no lockups, withdraw any time.
This section is for teams who want to bring that yield into their own product:
a wallet, an exchange, a treasury tool, or any app where users hold stablecoins.
A full integration combines both of the pieces below.
### The two building blocks
:::tip[On-chain contracts — move funds]
Spark Vaults are standard [ERC-4626](https://eips.ethereum.org/EIPS/eip-4626)
vaults. Call `deposit` / `mint` to enter a position and `withdraw` / `redeem` to
exit — the same interface across every supported vault. The
**[Spark Vaults Smart Contracts integration guide](/integrators/spark-vaults-v2)** walks through
each flow, with copy-paste **[examples](/integrators/spark-vaults-v2-examples)** in
viem, ethers, and Solidity. For large redemptions that exceed idle liquidity,
[Savings Vault Intents](/dev/savings/savings-vault-intents) provide a request-based
withdrawal flow.
:::
:::tip[Savings Data API — display data]
The **[Savings Data API](/integrators/savings-api-reference)** is a read-only REST API
exposing current and historic savings data for the vaults — savings rate, TVL,
depositors, available liquidity, and collateral composition. Use it to render rates
and dashboards in your UI without running your own indexer or on-chain calls. The
machine-readable OpenAPI spec is published at
[`https://api.spark.fi/openapi.json`](https://api.spark.fi/openapi.json).
:::
### Comprehensive enough to build from a single prompt
These docs are written to be self-contained — for human and LLM readers alike. The
ERC-4626 flows, the Savings Data API, and the machine-readable
[OpenAPI spec](https://api.spark.fi/openapi.json) give a coding assistant everything
it needs to scaffold a working integration without any extra context.
As a quick proof point, we handed these docs to ChatGPT and asked it to build a small
Spark Savings app. It produced a working result in a single shot:
:::tip[See it for yourself]
**[Building a Spark Savings app in one prompt →](https://chatgpt.com/share/6a1d7b92-eefc-83eb-ab2c-682d327c1abd)**
A shared ChatGPT session that turns these docs into a functioning savings app — no
hand-holding, no SDK.
:::
### Savings data, ready to present
The Savings Data API gives you live and historical data about each vault — savings
rates, balances, the assets backing the vault, the liquidity behind it, and more —
so you can present Spark Savings to your users however you like. The views below
are just a few examples of what that data can power.
### Spark Logomark
### Spark Badge
### SPK Token
### Spark Products
#### Savings
#### sUSDS
#### sUSDC
#### Spark Liquidity Layer
#### SparkLend
### Colors
See [Brand Guidelines](#brand-guidelines) for color usage.
### Typography
See [Brand Guidelines](#brand-guidelines) for font usage.
#### Roobert
Primary typeface for Spark.
* License Required - [See here](https://displaay.net/typeface/roobert-collection/roobert/)
#### Inter
Secondary typeface for Spark.
Used for body text and captions.
* Free - [See here](https://fonts.google.com/specimen/Inter)
## SPK Cookie.fun Airdrop
The Spark SNAPS airdrop rewarded users who demonstrated significant participation in the Spark SNAPS campaign on the [Cookie.fun platform](https://cookie.fun/tokens/spark). The campaign initiative was aimed at driving community engagement and awareness. The campaign ran from May 22, 2025 5pm UTC to June 24, 2025 14:00 UTC.
### How many SPK tokens were allocated to the Cookie.fun campaign Airdrop?
The total SPK allocated to the Spark SNAPS airdrop was approximately 5 million SPK. It was distributed to the top 500 SNAPPERS in the Spark SNAPS campaign based on engagement metrics provided by Cookie.fun, with these top 500 SNAPPERS grouped by the top 25th percentile, mid 50th percentile and bottom 25th percentile.
Tokens were allocated to these three groups as follows, and were distributed to users within each group *pro rata* based on the user's total number of SNAPS relative to other users in the group:
* Top 25th percentile (users with 63.2-125.2 SNAPS): 2,255,425 total SPK
* Mid 50th percentile (users with 23.2-63.1 SNAPS): 2,012,651 total SPK
* Bottom 25th percentile (users with 5.7-23.1 SNAPS): 718,568 total SPK
### How did users qualify for the Spark SNAPS airdrop?
To qualify for the Spark SNAPS airdrop, in addition to meeting the criteria above and any other general eligibility criteria, users had to have also supplied an eligible wallet address to Cookie.fun during the campaign period.
### Claiming Deadline
The claiming period ran until December 17, 2025 at 14:00 UTC and has ended. Any SPK which remained unclaimed was returned to the ecosystem treasury.
### Important Notes
Airdrop amounts were determined based upon Cookie.fun engagement metrics. These determinations are final, per the [Airdrop Terms & Conditions](/airdrop/terms).
## SPK Ignition Airdrop
Spark ran an airdrop campaign to reward users who participated in various DeFi activities across multiple chains. The campaign consisted of two phases: the main Ignition airdrop and an optional Overdrive phase where users could boost their airdrop amount.
### How many SPK tokens are allocated to Ignition?
A total of 325,485,000 SPK tokens were allocated to the Ignition airdrop campaign. Tokens which remained unclaimed at the end of the Ignition claiming period were distributed in the Overdrive airdrop as specified in the Overdrive rules. [You can find more info on the Overdrive airdrop here](/airdrop/overdrive).
### How did users qualify for the Ignition airdrop?
Users could qualify for the Ignition airdrop by meeting one or more of the following criteria. Each criterion met earned users one "Ignition unit". Users' final SPK allocation was proportional to their total Ignition units relative to the units of all qualifying users.
#### Qualification Criteria
##### Stablecoin Holdings
* **USDS, sUSDS, sUSDC, sDAI, or SAI Holdings**
* Hold at least $1,000 total across any of these tokens on any of the snapshot dates
* Snapshot dates: April 15, 2023, April 15, 2024, April 15, 2025 - all 23:59:59 UTC
* Qualifying chains: Mainnet, Base, Arbitrum
* Possible units: One for each of the four listed tokens
* **xDAI Holdings**
* Hold at least 1,000 xDAI on any of the snapshot dates
* Snapshot dates: April 15, 2023, April 15, 2024, April 15, 2025 - all 23:59:59 UTC
* Qualifying chains: Gnosis
* Possible units: One
* **DAI Holdings**
* Hold at least $10,000 in DAI on any of the snapshot dates
* Snapshot dates: April 15, 2023, April 15, 2024, April 15, 2025 - all 23:59:59 UTC
* Qualifying chains: Mainnet, Base, Arbitrum, Optimism, Polygon
* Possible units: One
##### SparkLend Activity
* **SparkLend Supply**
* Supply over $100 in a single transaction into SparkLend
* Deadline: On or prior to April 15, 2025 23:59:59 UTC
* Qualifying chains: Mainnet, Gnosis
* Possible units: One
##### Lending Platform Activity
* **Aave Lending**
* Lend at least $5,000 in aggregate across USDS, sUSDS, USDT, USDC, USDe, sUSDe, DAI, or sDAI
* Snapshot date: March 15, 2025 23:59:59 UTC
* Qualifying chains: Mainnet, Base, Arbitrum, Polygon, Optimism, Gnosis
* Possible units: One
* **Morpho Lending**
* Lend at least $5,000 in aggregate across USDS, sUSDS, USDT, USDC, USDe, sUSDe, DAI, or sDAI
* Snapshot date: March 15, 2025 23:59:59 UTC
* Qualifying chains: Mainnet, Base, Polygon
* Possible units: One
* **Fluid Lending**
* Lend at least $5,000 in aggregate across USDS, sUSDS, USDT, USDC, USDe, sUSDe, DAI, or sDAI
* Snapshot date: March 15, 2025 23:59:59 UTC
* Qualifying chains: Mainnet, Arbitrum, Base, Polygon
* Possible units: One
##### Other DeFi Activities
* **Pendle PT, YT, or LP Holdings**
* Hold at least $5,000 in aggregate in Pendle PT, YT, or LP in top 3 markets by TVL on the snapshot date
* Snapshot date: March 15, 2025 23:59:59 UTC
* Qualifying chains: Mainnet
* Possible units: One
* **Ethena Holdings**
* Hold at least $5,000 in Ethena sUSDe or USDe
* Snapshot date: March 15, 2025 23:59:59 UTC
* Qualifying chains: Mainnet
* Possible units: One for each of the two listed tokens
* **Curve 3pool LP**
* Supply at least $5,000 as a Curve 3pool LP
* Snapshot date: March 15, 2025 23:59:59 UTC
* Qualifying chains: Mainnet
* Possible units: One
* **Pendle vePENDLE**
* Hold at least $5,000 in Pendle vePENDLE
* Snapshot date: March 15, 2025 23:59:59 UTC
* Qualifying chains: Mainnet
* Possible units: One
### Claiming Period
The claim period for Ignition airdrop tokens ran from June 17, 2025 - 08:00 UTC to July 29, 2025 - 14:00 UTC. The claiming period ended on July 29, 2025. Unclaimed SPK tokens were allocated to the Overdrive phase. Please see Overdrive rules for more details.
### Which networks qualified for the Ignition airdrop?
The Ignition airdrop rewarded activity across multiple networks, including:
* Ethereum Mainnet
* Base
* Arbitrum
* Optimism
* Gnosis
* Polygon
Note that only specific activities on a given network may have qualified for Ignition units. Please refer to the specific qualification criteria above for more details.
Claiming SPK was only possible on Ethereum Mainnet.
### Important Notes
* All qualifying amounts are denominated in USD and were calculated using Dune pricing at the time of the snapshot.
* Users who qualified for multiple criteria received more Ignition units.
* Each user's Ignition airdrop amount was proportional to their total Ignition units relative to the units of all qualifying users.
## SPK Airdrop
Spark airdropped SPK tokens to three main categories of users:
* [Pre-Farming](/airdrop/pre-farm): Based on lending/borrowing activity on SparkLend and Aave during the pre-farming period.
* [Spark Ignition](/airdrop/ignition) & [Overdrive](/airdrop/overdrive): Based on participation in specified DeFi activities on specific snapshot dates, with an option to boost rewards.
* [Layer3](/airdrop/layer3): Based on participation in Spark's Quests on the Layer3 platform.
You can read more about each campaign in the following pages, or by clicking the links above.
### Airdrop Status
The SPK airdrop has concluded. All claiming periods have ended, with the final claiming date being December 17th, 2025. The airdrop is no longer claimable. Do not trust any websites or platforms claiming to offer SPK tokens or access to claims. Beware of scammers and false SPK tokens.
### Eligibility
In addition to any eligibility requirements for a particular phase of the Airdrop, to have been eligible, you had to be at least 18 years of age and not an individual or entity subject to national or international sanctions or otherwise designated on any list of prohibited or restricted parties, including but not limited to the lists maintained by the United Kingdom, the United Nations, the European Union or its Member States, the United States, or other applicable government authority. Please read the [Spark Airdrop Terms and Conditions](/airdrop/terms) and the requirements for each airdrop phase for more information.
### Claiming Periods
The table below outlines all the claiming periods for all SPK airdrop campaigns. All claiming periods have now ended. Note times were in 24h UTC format.
| **Airdrop** | **Claiming starts** | **Claiming ends** |
| ----------- | --------------------------- | ----------------------------- |
| Ignition | June 17, 2025 - 08:00 UTC | July 29, 2025 - 14:00 UTC |
| Overdrive | August 12, 2025 - 14:00 UTC | December 17, 2025 - 14:00 UTC |
| Layer3 | June 17, 2025 - 08:00 UTC | December 17, 2025 - 14:00 UTC |
| Pre-farming | June 17, 2025 - 08:00 UTC | December 17, 2025 - 14:00 UTC |
| Cookie.fun | June 26, 2025 - 14:00 UTC | December 17, 2025 - 14:00 UTC |
### Important Notes
* The airdrop claiming period has ended. The claim interface is no longer available.
* Official announcements were made through the official X account of [Spark (@sparkdotfi)](https://x.com/sparkdotfi).
* Beware of scammers and fake claiming websites.
* You can find the full terms and conditions for the airdrop [here](/airdrop/terms).
### Markets In Crypto-Assets Regulation (MiCA) Information
Please see [spark.fi/mica](http://spark.fi/mica) for Spark's crypto-asset white paper and other relevant information.
## SPK Layer3 Airdrop
The Layer3 airdrop rewarded users who participated in Spark's learning campaign on the Layer3 platform. This initiative aimed to educate users about Spark's ecosystem.
### How many SPK tokens were allocated to the Layer3 campaign Airdrop?
The total SPK allocation for the Layer3 airdrop was 500,000 SPK, and was evenly distributed amongst all users who completed all four quests on Layer3.
### How did users qualify for the Layer3 airdrop?
To qualify for the Layer3 airdrop, users had to have completed all four of Spark's Quests on the Layer3 platform during the qualification period.
### Claiming Period
The claim period for Layer3 SPK tokens ran from June 17, 2025 - 08:00 UTC to December 17, 2025 - 14:00 UTC. The claiming period ended on December 17, 2025. Any unclaimed SPK tokens were returned to the ecosystem treasury.
### Could users still participate in the Layer3 Campaign?
No, the Layer3 campaign ran from March 7, 2025 to April 7, 2025. The campaign has ended.
## SPK Overdrive Airdrop
Overdrive was the second phase of the Ignition airdrop series, where Ignition claimants had an option to qualify for a second airdrop. The Ignition airdrop phase lasted from the airdrop date to six weeks after the airdrop date. After this period, Ignition recipients were no longer able to claim their airdrop. SPK which was unclaimed after that period was allocated for distribution to participants in Overdrive as follows. For simplicity, the following dates have the following IDs:
* `DATE_1`: July 29, 2025 - 14:00 UTC
* `DATE_2`: August 11, 2025 - 14:00 UTC
### How did users qualify for the Overdrive airdrop?
To qualify for Overdrive, users had to stake their Ignition SPK during the Overdrive period as explained below.
#### Official Overdrive Qualification Rules:
1. User must have claimed their Ignition airdrop before the claiming deadline.
2. Users had to *stake* *at least* *their total allocation of SPK from the Ignition airdrop* by `DATE_1` using the same wallet that qualified for the corresponding Ignition airdrop.
3. This staked SPK *had to remain staked* until `DATE_2`.
4. This staked SPK *could not be in cooldown at any point* from `DATE_1` to `DATE_2`.
5. The above rules only applied to the amount of SPK that was earned from the Ignition airdrop for a given wallet. Unstaking SPK that was earned in another way did not impact Overdrive eligibility.
6. Similarly, staking more SPK than was received in the Ignition airdrop did not translate to a higher Overdrive airdrop amount. The Overdrive amount was based on the user's Ignition airdrop amount only.
### What was Overdrive Boosting?
Users that qualified for Overdrive could boost their Overdrive airdrop amount by using Spark Savings during the Overdrive period.
#### Official Boost Qualification Rules:
1. Users had to have *at least* 1,000 USDS or USDC in Spark Savings associated with the same wallet they used to claim the Ignition airdrop by `DATE_1`.
2. This minimum amount had to *remain* in Spark Savings continuously from `DATE_1` to `DATE_2`.
3. Users that were *already saving* the minimum amount of USDS or USDC in Spark Savings before Overdrive began *did not have to take any action* and could still qualify if they met the two requirements above.
### How was Overdrive SPK distributed?
Overdrive SPK was distributed from the pool of unclaimed SPK from the Ignition phase to all qualifying users in the Overdrive phase proportional to how many "Overdrive units" they had.
Overdrive units were calculated as follows:
1. Base Units:
* Users received 1 "Overdrive unit" for each SPK token received in Ignition that was staked for the entire Overdrive period (`DATE_1` to `DATE_2`).
2. Boost Option:
* Users could double their Overdrive units by boosting as described above.
3. Max Amount:
* As a contingency measure for low airdrop participation, the max amount of SPK that each user could receive from their Overdrive airdrop was 10x the amount that they received from their Ignition airdrop.
* In this situation, any remaining SPK after the Overdrive airdrop was complete would go back to the Spark treasury.
Overdrive participants received SPK in an amount proportional to their Overdrive units relative to the Overdrive units of other participants, with a max of 10x their Ignition airdrop amount:
### When was the Overdrive period?
The Overdrive period ran from July 29, 2025 - 14:00 UTC to August 11, 2025 - 14:00 UTC.
### Claiming Period
The claim period for Overdrive SPK tokens ran from August 12, 2025 - 14:00 UTC to December 17, 2025 - 14:00 UTC. The claiming period ended on December 17, 2025. Any Overdrive SPK tokens which remained unclaimed were returned to the ecosystem treasury.
## SPK Pre-Farming Airdrop
Spark's pre-farming airdrop campaign rewarded users based on usage of SparkLend and AAVE on Ethereum mainnet. Select users of those platforms during the pre-farming period received an airdrop, depending on how much and how long they used either platform during specific periods, also known as "seasons." See further details on [qualification criteria](#how-do-i-qualify-for-the-spk-airdrop) for the airdrop, and the [different seasons](#season-1-aug-20-2023-may-20-2024) below.
### How much SPK is allocated to pre-farming users?
SPK for pre-farming is allocated as follows:
* Season 1 (Aug 20, 2023 - May 20, 2024):
* 130,434,783 SPK
* Season 2 pool (May 20, 2024 - June 16, 2025):
* SparkLend: 14,478,261 SPK per month (prorated on a per-second basis from May 2024 and onwards)
* Aave: 7,239,130 SPK per month (prorated on a per-second basis from May 2024 and onwards)
### How is SPK distributed to pre-farming users?
#### **Season 1**
* 80% of Season 1 SPK allocation is distributed *pro rata* to users borrowing DAI and 20% is distributed *pro rata* to users supplying ETH during the Season 1 time period.
* Season 1 calculations are based on the qualifying amount and total duration supplied.
:::info
**Note:** only activities on Ethereum mainnet are counted.
:::
#### **Season 2**
* SparkLend: 80% of Season 2 SparkLend allocation is distributed *pro rata* to users borrowing USDS or DAI and 20% is distributed *pro rata* to users supplying ETH during the Season 2 time period.
* Aave: Season 2 Aave allocation is distributed *pro rata* to users who supplied USDS into Aave during the Season 2 time period.
Season 2 calculations are done per block, based on the qualifying amount supplied in each block.
:::info
**Note:** only activities on Ethereum mainnet are counted.
:::
### Claiming Period
The claim period for pre-farming SPK ran from June 17, 2025 - 08:00 UTC until December 17, 2025 - 14:00 UTC. The claiming period ended on December 17, 2025. Any SPK which was not claimed during that period has been returned to the Spark ecosystem treasury.
### Excluded behaviors and "anti-cheat" formulas
To ensure a fair airdrop, certain behaviors disqualified users from the pre-farming airdrop, including:
* **SparkLend**: Lending sDAI while borrowing DAI or lending and borrowing ETH on the same account
* **Aave**: "stablecoin looping" (i.e., supplying USDS and borrowing DAI or USDS and supplying USDS again, effectively providing a highly leveraged USDS position)
Details on the anti-cheat formulas are below.
#### **SparkLend Anti-cheat formula**
Below is the anti-cheat formula applied to screen for excluded behavior on SparkLend (don't worry about this if you used the system legitimately):
`Airdrop = 80% * (DAI Borrows + USDS Borrows - sDAI Supplies * sDAI Liquidation Threshold - sUSDS Supplies * sUSDS Liquidation Threshold) + 20% * (ETH Supplies - ETH Borrows / ETH Liquidation Threshold)`
For clarity, here are some **valid examples:**
* ✅ Supply wstETH, Borrow USDS - USDS amount is included
* ✅ Supply rETH, Borrow USDS - USDS amount is included
* ✅ Supply wstETH, Borrow USDS, Swap USDS for sUSDS - USDS amount is included
* ✅ Supply ETH, Borrow USDS - Both ETH and USDS amounts are included in the airdrop
* ✅ Supply rETH, Supply ETH, Borrow USDS - Both ETH and USDS amounts are included in the airdrop
* ✅ Supply GNO, Borrow USDS - USDS amount is included
* ✅ Supply wstETH, Borrow DAI - DAI amount is included
* ✅ Supply rETH, Borrow DAI - DAI amount is included
* ✅ Supply wstETH, Borrow DAI, Swap DAI for sDAI - DAI amount is included
* ✅ Supply ETH, Borrow DAI - Both ETH and DAI amounts are included in the airdrop
* ✅ Supply rETH, Supply ETH, Borrow DAI - Both ETH and DAI amounts are included in the airdrop
* ✅ Supply GNO, Borrow DAI - DAI amount is included
* ✅ Supply ETH - ETH amount is included
* ✅ Supply ETH, Borrow wstETH - ETH amount is included
**Invalid examples:**
* ❌ Supply sUSDS, Borrow USDS - FORFEIT AIRDROP
* ❌ Supply sUSDS, Borrow DAI - FORFEIT AIRDROP
* ❌ Supply sDAI, Borrow USDS - FORFEIT AIRDROP
* ❌ Supply sDAI, Borrow DAI - FORFEIT AIRDROP
* ❌ Supply ETH, Borrow ETH - FORFEIT AIRDROP
* ❌ Supply wstETH, Borrow USDS, Supply sUSDS as Collateral - FORFEIT AIRDROP
* ❌ Supply wstETH, Borrow USDS, Supply sDAI as Collateral - FORFEIT AIRDROP
* ❌ Supply wstETH, Borrow DAI, Supply sDAI as Collateral - FORFEIT AIRDROP
* ❌ Supply wstETH, Borrow DAI, Supply sUSDS as Collateral - FORFEIT AIRDROP
**Note:** Borrowing DAI and depositing it into sDAI using the Savings feature of Spark is accepted and does not count against the airdrop. It is only penalized if you supply sDAI as collateral to borrow against.
#### Aave Anti-cheat formula
To prevent gaming the incentives through "stablecoin looping", meaning supplying USDS and borrowing DAI or USDS and supplying USDS again, effectively providing a highly leveraged USDS position, the following formula is used to discount such behavior:
`USDS Supplies - Sum_i(USDS+DAI Borrow Amount (in USD) / USDS+DAI Liquidation Threshold)`
## Spark Airdrop Terms and Conditions
These Spark Airdrop Terms and Conditions (“Terms”) govern your participation in Spark’s airdrop of the SPK token (“Airdrop”). The Airdrop is offered and administered solely by SPK Company Ltd. (hereinafter, “we,” “us,” or “our”). By participating in the Airdrop, you agree to these Terms. If you do not agree, you may not participate. These Terms apply in addition to any other rules, policies, procedures and/or other terms and conditions that may apply from time to time with respect to the Tokens.
### Rules and Eligibility
The Airdrop is being offered in multiple phases. More information about each phase may be found at [https://docs.spark.fi/airdrop](https://docs.spark.fi/airdrop), including eligibility criteria, rules of participation, claiming deadlines, and an explanation of how airdrop amounts are being calculated.
In addition to any eligibility requirements for a particular phase of the Airdrop, to be eligible, you must be at least 18 years of age and not an individual or entity subject to national or international sanctions or otherwise designated on any list of prohibited or restricted parties, including but not limited to the lists maintained by the United Kingdom, the United Nations, the European Union or its Member States, the United States, or other applicable government authority.
You may be disqualified from participation in the Airdrop without notice to you if we determine, in our sole discretion, that you have violated these Terms. In addition, we reserve the right to disqualify any participant, wallet address, or transaction that is, in our sole discretion, associated with: suspicious activity; illegal or prohibited conduct; a jurisdiction or individual subject to sanctions or other restrictions; or any wallet address or transaction identified as high risk by blockchain analytics providers. We may rely on third-party data, internal investigations, or any other information available to us in making such determinations, and our decisions shall be final and binding.
### No Purchase Necessary
Participation in the Airdrop is free. No payment or purchase is necessary.
### Claiming
Eligible participants may be able to claim SPK tokens (“Tokens”) based on criteria defined by us. You acknowledge and agree that our determination of your airdrop amount, if any, shall be final and you agree not to contest such determination. You acknowledge and agree that we have no obligation to provide you with any information explaining how we calculated your airdrop amount, if any. Without limiting the generality of the foregoing, you acknowledge that, in determining airdrop amounts, we may rely on data, metrics, or other information provided by third-party sources, including but not limited to wallet addresses, engagement metrics, or other eligibility criteria. We do not independently verify, audit, or validate such data, and we make no representations, warranties, or guarantees as to its accuracy, completeness, or reliability.
Access to claim the Airdrop requires a stable internet connection, a non-custodial wallet, and sufficient ETH to cover network fees on Ethereum mainnet. Participants are solely responsible for meeting these technical requirements and bearing any associated costs.
### Representations and Warranties
By participating in the Airdrop, you represent and warrant that:
* You are at least 18 years old;
* You are not an individual or entity subject to national or international sanctions or otherwise designated on any list of prohibited or restricted parties, including but not limited to the lists maintained by the United Kingdom, the United Nations, the European Union or its Member States, the United States, or other applicable government authority;
* You are solely responsible for determining what, if any, taxes apply to your receipt, holding, or transfer of the Tokens and for reporting and paying such taxes in accordance with the laws of your jurisdiction;
* You are not relying on any representation or warranty, express or implied, not set forth in these Terms, and you have conducted your own due diligence in evaluating participation in the Airdrop;
* You are solely responsible for the security and management of your wallet and private keys;
* You will not use bots, engage in any Sybil attacks, or engage in any fraudulent or unfair conduct in connection with the Airdrop;
* Your participation in the Airdrop shall not constitute or involve the violation of any applicable laws;
* You possess sufficient knowledge and experience in financial and blockchain matters to evaluate the merits and risks of claiming and holding Tokens, and you have conducted your own independent investigation and analysis of the Tokens;
* You have not relied on any representation or warranty made by us or any of our affiliates or representatives other than as expressly set forth in these Terms; and
* You voluntarily and freely accept the risks associated with the use of blockchain technology in connection with the Airdrop, including without limitation smart contract vulnerabilities, transaction delays, and irreversible loss of funds.
### Limitation of Liability
WE SHALL NOT BE LIABLE TO YOU FOR SPECIAL, INDIRECT, CONSEQUENTIAL, OR INCIDENTAL LOSSES OR DAMAGES OF ANY KIND OR NATURE WHATSOEVER, INCLUDING BUT NOT LIMITED TO LOST PROFITS, LOST RECORDS OR DATA, LOST SAVINGS, LOSS OF USE OF FACILITY OR EQUIPMENT, LOSS BY REASON OF FACILITY SHUT-DOWN OR NON-OPERATIONS OF INCREASED EXPENSE OF OPERATIONS, OR OTHER COSTS, CHARGES, PENALTIES, OR LIQUIDATED DAMAGES, REGARDLESS OF WHETHER ARISING FROM BREACH OF CONTRACT, WARRANTY, TORT, STRICT LIABILITY OR OTHERWISE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH LOSS OR DAMAGE OR IF SUCH LOSS COULD HAVE BEEN REASONABLY FORESEEN. OUR LIABILITY FOR DAMAGES HEREUNDER, REGARDLESS OF THE FORM OF ACTION, SHALL NOT EXCEED US$100.
### Indemnification
YOU WILL DEFEND, INDEMNIFY AND HOLD HARMLESS US AND OUR OFFICERS, DIRECTORS, EMPLOYEES, AGENTS AND AFFILIATES FROM AND AGAINST ANY CLAIMS, DISPUTES, DEMANDS, LIABILITIES, DAMAGES, LOSSES, AND COSTS AND EXPENSES, INCLUDING, WITHOUT LIMITATION, REASONABLE LEGAL FEES ARISING OUT OF OR IN ANY WAY CONNECTED WITH YOUR VIOLATION OF THESE TERMS.
### Third Party Rights
Notwithstanding the absence of statutory provisions in the British Virgin Islands permitting third-party enforcement of contract terms, the parties to these Terms expressly agree that any person (or class of persons) identified in these Terms as being entitled to an indemnity or limitation or exclusion of liability (each a “Beneficiary”) shall have the right to enforce the relevant provisions of these Terms as if they were a party to it. The parties to these Terms may rescind, vary, or terminate these Terms (including any term conferring a benefit on any Beneficiary) without the consent of any Beneficiary, provided that such rescission, variation, or termination does not affect any accrued rights of a Beneficiary as at the date of such change.
### Disclaimers
We disclaim all warranties, express or implied, including merchantability, fitness for a particular purpose, and non-infringement. We do not guarantee that you will receive any Tokens, that the Tokens will have any monetary value, or that the Tokens will be listed on any exchange or usable in any application.
### Governing Law; Arbitration
These Terms and any dispute or claim (whether contractual or non-contractual) arising out of or in connection with them or their subject matter or formation (a “Dispute”) shall be governed by and construed in accordance with the laws of the British Virgin Islands.
Any Dispute shall be referred to and finally resolved by arbitration under the BVI IAC Arbitration Rules (the “Rules”), which Rules are deemed to be incorporated by reference into these Terms. The tribunal shall consist of a sole arbitrator appointed in accordance with the Rules. The seat and place of arbitration shall be Road Town, Tortola, British Virgin Islands. The language of the arbitration shall be English.
The award of the tribunal shall be final and binding upon the parties and may be enforced in any court of competent jurisdiction. Judgment on the award may be entered in any such court. Each party irrevocably waives any right it may have to object to the venue or to claim that the proceedings have been brought in an inconvenient forum.
### Markets In Crypto-Assets Regulation (MiCA) Information
Please see [spark.fi/mica](http://spark.fi/mica) for Spark’s crypto-asset white paper and other relevant information.
### Modifications
We may update these Terms at any time without notice. Continued participation after such changes constitutes acceptance.