Project & Team
Description of Project
A narrative description of the purpose of the project is provided.
Acurast is redefining compute by utilizing billions of smartphones - no data centers required. This verifiable, scalable, and confidential compute network enables developers to run secure applications on decentralized infrastructure at scale, without compromising speed or privacy.
Acurast has already onboarded 270,000+ compute units worldwide, making it the most decentralized verifiable compute network available today. This compute powers mission-critical workloads with high-security and AI requirements - from REST APIs and webhooks to LLM inference and confidential data processing.
This isn't just another Compute protocol - it's a fundamental rethink of how the world computes. Instead of relying on data centers or even servers, Acurast harnesses the world's most abundant, powerful, and secure form of compute: the smartphone.
Known Project Team
For each existing entity: Labs/DevCo (e.g., Founder, CEO, CTO, COO), Foundation (e.g., President, Executive Director, CFO, COO), and DAO / onchain governance leadership (if applicable) list the: (a) full names, (b) official titles, (c) and prior experience of key team members. For any non-existent entity, explicitly mention it does not exist. External links may be included but they will not factor into the score.
Labs / DevCo
Full Name | Official Title | Prior Experience |
|---|---|---|
Lukas Schönbächler | Co-Founder | Mobile security expert, application engineering expert |
Foundation
Full Name | Official Title | Prior Experience |
|---|---|---|
Alessandro De Carli | Co-Founder | Distributed systems expert, Co-founder of AirGap, ex-Credit Suisse. |
Pascal Brun | Co-Founder | Crypto infra veteran, Co-founder of AirGap. |
DAO / Onchain Governance
Full Name | Official Title | Prior Experience |
|---|---|---|
NA | NA | NA |
DAO Structure
Provide a structured description of the DAO's governance, powers, and economic rights. If a DAO does not exist, state so. Address the lettered items below. Even if there is no DAO, there must be an answer to (d).
- (a) IP ownership & control — State what IP the DAO owns or controls (e.g., codebases/repos, trademarks/brands). Note any license if relevant.
- (b) Contract/admin powers — List on-chain or administrative authorities and limits: pause/upgrade roles (e.g., multisig pause), governance-executor authorities, and the method of authority for each (e.g., veto, majority, super-majority).
- (c) Locked-token rights (conditional) — If locking/staking for additional rights exists, explain the additional rights and what tokenholders can and cannot decide. If no locking mechanism exists, leave absent.
- (d) Current tokenholder governance rights and economic arrangements — If any, describe the current governance rights of tokenholders and any presently operative rights or arrangements relating to treasury actions, fee-routing, rewards, buybacks, or other protocol-controlled resources. If none, state that explicitly.
- (e) Control surface reliance — If any, briefly describe the anticipated or possible evolution of the protocol's governance/control model.
- (f) Dissolution authority — State who can dissolve/wind up the DAO and by what mechanism (e.g., on-chain vote threshold, board resolution of a legal wrapper).
(a) IP ownership & control
NA
(b) Contract/admin powers
There are no on-chain administrative authorities that can circumvent the Governance process.
(c) Locked-token rights (conditional)
ACU holders can amplify voting power trough conviction voting by locking ACU for longer periods, ACUs are locked immediately when a vote is cast, governance voting rights for staked tokens are enabled through the Acurast DAO. https://docs.acurast.com/acurast-protocol/governance/
(d) Current tokenholder governance rights and economic arrangements
The ACU Tokenholders can govern all parameters of the protocol including protocol upgrades.
(e) Control surface reliance
Full ownership over the Association.
(f) Dissolution authority
The DAO is in full control of its own dissoultion and that of the Community Treasury.
Primary Foundation
Do the following for the Primary Foundation, defined below. If the primary foundation does not exist, state that explicitly. Items (a)–(f) apply only if that entity exists; state explicitly that the entity doesn't exist. Definitions: The primary Foundation and DevCo can be explained as those entities which were directly/indirectly involved in the issuance of the native token at launch. If the original foundation/DevCo has been dissolved and in its place a "new foundation/DevCo" was created, then detail the "new foundation/DevCo".
- (a) Entity — Type and jurisdiction.
- (b) IP ownership & control — What IP the entity owns/controls (repos/code, trademarks/brand; license optional) and an explanation of any subsidiary entities.
- (c) Powers over DAO, treasury, protocol-controlled resources, and token administration — If any, describe the current powers over DAO governance, treasury actions, protocol-controlled resources (e.g. retained revenue), token administration, or reward parameters, and the method/threshold for each.
- (d) Powers over DevCo — Explain whether the Foundation can exert direct or indirect influence over decision-making of the Developer Company.
- (e) Contract/admin powers — Pause/upgrade/governance-executor authorities and the method/threshold for each (e.g., veto/majority/super-majority; "3/5 multisig").
- (f) Current economic arrangements and distribution policies — Describe any current governance-approved, contractual, or programmatic mechanisms, if any, by which protocol-controlled resources, treasury assets, fees, revenue, rewards, or token distributions may be directed to this entity, its equityholders, contributors, or other participants. If no such mechanism currently exists, state that explicitly. Do not discuss hypothetical future dividends, repurchases, or distributions unless formally adopted.
(a) Entity
Acurast Association is as a Swiss Association registered in Zug, Switzerland, with registration date 2022-05-10 and identifier CHE-334.860.841
(b) IP ownership & control
The Acurast Association controls the trademarks and the Acurast Github organization.
(c) Powers over DAO, treasury, protocol-controlled resources, and token administration
The Acurast Association Collective has the ability to create DAO referendas on the root tracks, these are as defined in the DAO-logic, subject to the token based voting. https://docs.acurast.com/acurast-protocol/governance
The Acuast Association DOES NOT have any additional control whatsoever outside of the DAO (Governance).
(d) Powers over DevCo
None
(e) Contract/admin powers
No additional power to pause, upgrade etc. outside of the DAO (Governance).
(f) Current economic arrangements and distribution policies
None
Primary Developer Company
Do the following for the Primary Developer Company, defined below. If the primary Developer Company does not exist, state that explicitly. Items (a)–(f) apply only if that entity exists; state explicitly that the entity doesn't exist. Definitions: The primary Foundation and DevCo can be explained as those entities which were directly/indirectly involved in the issuance of the native token at launch. If the original foundation/DevCo has been dissolved and in its place a "new foundation/DevCo" was created, then detail the "new foundation/DevCo".
- (a) Entity — Type and jurisdiction.
- (b) IP ownership & control — What IP the entity owns/controls (repos/code, trademarks/brand; license optional) and an explanation of any subsidiary entities.
- (c) Powers over DAO, treasury, protocol-controlled resources, and token administration — If any, describe the current powers over DAO governance, treasury actions, protocol-controlled resources (e.g. retained revenue), token administration, or reward parameters, and the method/threshold for each.
- (d) Powers over Foundation — Explain whether the Developer Company can exert direct or indirect influence over decision-making of the Foundation.
- (e) Contract/admin powers — Pause/upgrade/governance-executor authorities and the method/threshold for each (e.g., veto/majority/super-majority; "3/5 multisig").
- (f) Current economic arrangements and distribution policies — Describe any current governance-approved, contractual, or programmatic mechanisms, if any, by which protocol-controlled resources, treasury assets, fees, revenue, rewards, or token distributions may be directed to this entity, its equityholders, contributors, or other participants. If no such mechanism currently exists, state that explicitly. Do not discuss hypothetical future dividends, repurchases, or distributions unless formally adopted.
(a) Entity
The DevCo is a Swiss AG, a public limited company incorporated in Zug, Switzerland.
(b) IP ownership & control
None
(c) Powers over DAO, treasury, protocol-controlled resources, and token administration
None
(d) Powers over Foundation
None
(e) Contract/admin powers
None
(f) Current economic arrangements and distribution policies
None
Affiliated Protocol Contributor
Definition (for this section): An Affiliated Protocol Contributor (APC) is a non-issuer company - not the protocol's primary Foundation or DevCo - that materially contributes to the protocol's code, operations, governance, or funding. For example, Blockworks Advisory would be considered an APC of Ethena because it materially contributes to its operations through Ethena's risk council. Provide a structured description per APC. If no APCs exist, state that explicitly. Items below apply per APC; if an item isn't applicable to a given APC, leave it absent and note why briefly.
- (a) Identity & role — Legal name, entity type, jurisdiction, and role (e.g., core development, security, infrastructure, market making, operations).
- (b) Parameter control & scope — If any, what major protocol parameters the APC controls; include the method of authority (e.g., veto, majority, super-majority, "3/5 multisig"). If none, say so.
- (c) Contract/admin powers — If any, provide the pause/upgrade powers (e.g., multisig pause), governance-executor authorities and limitations; include the method/threshold for each. If none, say so.
- (d) Compensation and material economic arrangements — If any, protocol-generated resources or economic value is dynamically routed to the APC, describe the arrangement. Include the resource sources, routing mechanism, payment frequency, and duration. If no protocol resources or resources-linked economics are routed to the APC, state that explicitly.
(a) Identity & role
No Affiliated Protocol Contributor exists.
(b) Parameter control & scope
NA
(c) Contract/admin powers
NA
(d) Compensation and material economic arrangements
NA
Token Supply & Allocation
Initial Allocation
Download the Worksheet, enable macros, complete the Initial Allocation sheet, then use Convert To CSV to export the file for import here. To make edits after importing, update the worksheet, use Convert To CSV again, then re-import the new CSV.
Ticker | Date | Allocation Category Name | Recipient Type | Allocation % | Allocation Tokens | TGE Unlock % | TGE Unlock Tokens | Cliff Months | Cliff Unlock % | Linear Vesting Months | Cadence Months | Circulating Treatment | Notes on what each category is used for | If applicable: Contract / Wallet address |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
ACU | 20.01.2026 | Early Backers | Private / VC | 0.065 | 65000000 | 0 | 0 | 0 | 0 | 24 | 1 | Yes | Commitments allocated from seed and strategic investors who provided early financial and ecosystem support. | |
ACU | 20.01.2026 | CoinList Round | Community | 0.065 | 65000000 | 1 | 65000000 | 0 | 0 | 0 | 0 | Yes | Token allocation for the CoinList participants distributed via CoinList. | |
ACU | 20.01.2026 | Listing Incentives | Community | 0.05 | 50000000 | 1 | 50000000 | 0 | 0 | 0 | 0 | Yes | Drive ecosystem growth via campaigns. | |
ACU | 20.01.2026 | Early Compute Providers | Community | 0.065 | 65000000 | 0 | 0 | 3 | 0 | 44 | 1 | Yes | Participants of the Acurast test network earned testnet tokens for providing compute and helping to bootstrap the network. | |
ACU | 20.01.2026 | Community Activation | Community | 0.05 | 50000000 | 0 | 0 | 0 | 0 | 24 | 1 | Yes | Drive ecosystem growth via airdrops, testnet rewards, referral campaigns (e.g., Cloud Rebellion), and developer incentives. | |
ACU | 20.01.2026 | Cloud Rebellion Airdrop | Community | 0.01 | 10000000 | 0 | 0 | 0 | 0 | 24 | 1 | Yes | Participants earned points, these points made them eligible for the claim of the Airdrop. | |
ACU | 20.01.2026 | Community Treasury | Ecosystem | 0.24 | 240000000 | 0 | 0 | 3 | 0 | 24 | 1 | Yes | Fund future grants, governance proposals, and long-term protocol development through decentralized decision-making. | |
ACU | 20.01.2026 | Operational Funds | Treasury | 0.115 | 115000000 | 0 | 0 | 3 | 0 | 24 | 1 | Yes | Covers protocol operations, legal, infrastructure, partnerships, and ongoing business development needs. | |
ACU | 20.01.2026 | Liquidity Provision | Liquidity | 0.1 | 100000000 | 1 | 100000000 | 0 | 0 | 0 | 0 | Yes | Ensure sufficient exchange liquidity and market depth to support healthy token trading and price discovery. | |
ACU | 20.01.2026 | Team | Other | 0.24 | 240000000 | 0 | 0 | 6 | 0 | 36 | 1 | Yes | Incentivize long-term commitment, protocol development, and strategic guidance from core contributors. |
Vesting Insider Tokens
If there are not post-TGE token compensation plans, state explicitly they do not exist. If there are, state each of (A)–(B) below.
- (a) Post-TGE employee lock as % of total supply — State the current total amount of tokens locked or unvested attributable to post-TGE employees, expressed as a percentage of total supply.
- (b) Typical post-TGE vesting schedule — Describe the standard vesting terms used for post-TGE grants, including: cliff length (or "no cliff"), vesting frequency (e.g., monthly/quarterly), and total duration.
(a) Post-TGE employee lock as % of total supply
There are no Post-TGE employee locks.
(b) Typical post-TGE vesting schedule
Typical grants have a 24 months linear vesting scheme with a monthly unlock.
Disclosure of Token Advisory Billings
Disclose current token-based compensation for external advisors and service providers (e.g., legal, marketing, technical, growth) funded from the on-chain treasury. Do not disclose individual payments to advisors receiving fiat-only compensation.
- (a) Existence — Whether any such token-based payments or advisory commitments exist (or explicitly state that no token-based compensation for advisory commitments exist).
- (b) Total token allocation — The total token allocation across all advisory services.
- (c) Payer entity — The payer entity (e.g., Foundation, Labs/DevCo, DAO/treasury).
- (d) Description of advisory/services — A brief description of the advisory/services (e.g., "legal and regulatory advisory," "growth and BD support," "security advisory").
(a) Existence
No ongoing Token Advisor Billings exist.
(b) Total token allocation
NA
(c) Payer entity
NA
(d) Description of advisory/services
NA
KOL Marketing Activities
Disclose ongoing KOL/influencer relationships that partially or fully received tokens for payment. Do not need to disclose KOL/influencers that do not receive tokens for payment.
- (a) Existence & scope — State plainly whether KOLs receive tokens for payment, if none say so.
- (b) Usernames & roles — List usernames/handles (with platforms) for KOLs that received token-based compensation and describe the nature of their activities. Legal names are not required.
- (c) Token allocation & vesting/locks — Provide the aggregate token amount across all such arrangements and summarize vesting, lock, or release terms.
(a) Existence & scope
There were only two instances with KOLs where they received tokens for payment with a combined amount less than 100,000 ACU, these were done only based on KPIs and service agreements.
(b) Usernames & roles
- Nordic Crypto (Youtube and X), https://x.com/NordicMiner
Various Acurast Processors setups and how to get started guides e.g., https://www.youtube.com/watch?v=sGi1FQMHGvo - TheHobbyistMiner (Youtube and X), https://x.com/HobbyistMiner
Various Acurast Processors setups guides e.g., https://www.youtube.com/watch?v=u00fkMsWg08
(c) Token allocation & vesting/locks
100,000 ACU, 24 months linear
Labelled Unissued & Operational Token Wallets
For each wallet that holds Unissued Tokens or is essential to operations (e.g., foundation, operations, treasury, investor reserve), disclose:
- (a) A category label explaining the wallet's primary function.
- (b) chain the wallet is on.
- (c) The unique address of the wallet.
- (d) The mechanism of control (e.g., DAO, multisig).
- (e) One verification link to a blockchain explorer. Definition: Unissued Supply = tokens authorized by the contract but not yet issued to any party; where they sit (treasury or mint authority) does not change that they are unissued. For instance: if a token has a total supply cap of 1B, and 400M tokens have been issued to investors, the team, and users (whether vested or unlocked), then those 400M count as issued supply. The remaining 600M are authorized but unissued supply, even if they are already minted into a DAO treasury wallet.
Title | Primary Function | Chain | Address | Control Mechanism | Explorer Link |
|---|---|---|---|---|---|
All Tokens have been issued | NA | NA | NA | NA | NA |
Operational Funds | Treasury | Acurast Mainnet | 5EYCAe5iXhV27TdQGKANjpKWqMirf6zwK1wcMJnQLwWfQggS | Acurast Association Collective | |
Community Treasury | Ecosystem | Acurast Mainnet | 5EYCAe5jXu2x3jF1rfyz6MQUZUpgQb59Mk7tFCutXDL6aFYP | On-chain Governance | |
Community Activation | Community Activation | Acurast Mainnet | 5EYCAe5gXr27rgkx3s9NMoDEyGXzPHUEwLLV6SJZmrYWgv8B | Acurast Association Collective |
Transactions & Market Structures
Market Maker Agreements & Deals
Projects must disclose all material terms of market-making arrangements that affect token liquidity. If the project has no agreements or deals with market makers, state that explicitly; doing so earns full credit. For each market maker, include in a table:
- (a) Market maker's name — the market maker's name;
- (b) Token allocation or loaned amount — the token allocation or loaned amount as a percentage of total supply;
- (c) Duration/term of agreement — the duration/term of the agreement; and, where applicable,
- (d) Name of agreement structure — label the financial vehicle being used in the agreement (i.e. loan, option/call, retainer model) without describing trading strategy or expected outcomes. If the project has no agreements or deals with market makers, state that explicitly; doing so earns full credit. If no native tokens were loaned or allocated to market makers, state that explicitly; cash/fiat retainers or fees are not required for this item.
Market Maker Name | Token Allocation Committed | Term Duration | Structure Name |
|---|---|---|---|
3 Market Makers | 1.75% | 24 months | Structure and names under NDA |
CEX / DEX Agreements & Deals
Projects must disclose all material terms of centralized or decentralized exchange listings that affect token liquidity. For each listing, include in a table:
- (a) Exchange name / DEX pool — the exchange name (and, for DEX, the specific pool/pair);
- (b) Token allocation for listing — the token allocation supplied or committed for listing as a percentage of total supply;
- (c) Term Duration — the duration/term of any listing lockups, liquidity, or incentive programs; and, where applicable,
- (d) Native-token listing fees — whether any listing fees were paid in native tokens, with amounts (tokens or % of supply), recipients, and any vesting or lock terms tied to the partnership. If the project has no agreements or deals with CEX or DEX, state that explicitly; doing so earns full credit; cash/fiat fee amounts are not required for this item.
Exchange Name | Token Allocation Committed | Term Duration | Native Token Listing Fees |
|---|---|---|---|
Agreements under NDA | NA | undefined | NA |
Liquidity Deals and Market Activity
If a category does not exist or is not applicable, make that clear in plain language (no specific wording required).
- (a) Token repurchases or secondary-market accumulations (if any) — Source of funds, treatment (burn, treasury retention, POL, redistribution, or other), controller/approvals, and whether those tokens may be re-used, re-issued, or permanently removed from circulation.
- (b) Protocol-owned liquidity (POL) — Where deployed, total token or dollar size across deployments, controller, and unwind/exit policy.
- (c) Liquidity deals / purchased TVL — The total size across all deals, and where the capital participates - no counterparty names needed.
- (d) Token-secured loans/lines (incl. against unissued tokens) — Principal, gross position size, collateral, counterparties, and unwind/exit policy.
(a) Token repurchases or secondary-market accumulations (if any)
None
(b) Protocol-owned liquidity (POL)
24% of the total supply at Genesis are owned by the protocol Governance, see https://docs.acurast.com/discover/tokenomics#token-allocations
(c) Liquidity deals / purchased TVL
None
(d) Token-secured loans/lines (incl. against unissued tokens)
None
Resource Disclosures
Prior Token Sales & Fundraising
Disclose all prior token sales by the Project — including fundraising rounds, any material OTC sales to investors, and any discounted market-maker sales. For each sale, provide:
- (a) Series Name / Early-Stage Investment Instrument used (i.e. SAFT, STAMP, SAFE, SAFE+Token Warrant, etc.)
- (b) Date of sale (at least month & year).
- (c) Number of tokens sold (or % of total supply)
- (d) Vesting schedule If no prior sales occurred, state that explicitly (e.g., "No prior fundraising, OTC, or discounted MM sales have occurred.")
Series Name | Investment Vehicle | Date Of Sale | Number of tokens sold | Vesting Schedule |
|---|---|---|---|---|
Non-dilutive grants | Non-dilutive | 2023 - 2025 | 0 (no tokens) | None |
Seed Round | SAFT | 01.06.2023 | 32500000 | 24 months linear |
Strategic Round | SAFT | 01.06.2024 | 32500000 | 24 months linear |
Coinlist Round | SAFT | May 15–22, 2025 | 65,000,000 | None |
Operational Funding, Economic Flows, and Resource Provisioning
Provide a narrative description of the Project's material funding sources, economic flows, and operational provisioning, broken out by entity: Foundation, Lab/DevCo, and DAO. If an entity does not exist, state that explicitly. If an entity exists but does not pursue revenue-generating activity, state how it funds or provisions its operations.
- (a) Entity existence — Explicitly state whether each of Foundation, Lab/DevCo, and DAO exists.
- (b) Material sources of funding or economic inflows — For each existing entity, describe its primary sources of operational funding or economic inflows, if any (e.g., service fees, grants, donations, treasury reserves, token reserves, staking rewards, validator/sequencer income, partnership payments, retained revenue, or other protocol-related receipts). If none, state "none."
- (c) Operational use of resources — Briefly describe how those resources are generally used (e.g., development, operations, security, ecosystem support, grants, liquidity support).
- (d) Onchain Resource Usage — Provide links to public dashboards and token holder relations reports that help explain on-chain financial activity, treasury activity, fee flows, rewards, or other protocol-controlled resources. Make certain to explain what each link is for.
(a) Entity existence
- The Acurast Association is the "Foundation".
- The DAO exists as the onchain governance of ACU tokenholders, which controls the onchain treasury.
- A Swiss DevCo and multiple other entities are contracted by the Association for engineering, business development, operations, security, ecosystem support, legal and other roles. These entitites are not Association-controlled.
(b) Material sources of funding or economic inflows
Operational Funds - Association:
The Association has access to the operational allocation per the Tokenomics https://docs.acurast.com/discover/tokenomics#token-allocations, the capital raised from contributors and as any other individual or entity the possibility to request funds from the Treasury trough the on-chain Governance (DAO) process.
DevCos:
The Swiss DevCo and multiple other entities with service agreements are either contracted by the Association or receive grants through the on-chain treasury controlled by Governance.
On-chain Treasury:
15% of the 5% yearly protocol based inflation are assigned to the on-chain treasury controlled by the Governance process of the Acurast protocol (https://docs.acurast.com/processors/rewards/#staking-rewards-staked-compute-pool)
(c) Operational use of resources
- Operational Funds - Association: The Association uses the funds at its disposal for engineering, business development, operations, security, ecosystem support, legal.
- DevCos: Funded by the Association or the on-chain treasury for engineering, business development, operations, security, ecosystem support, legal.
- On-chain Treasury: The on-chain treasury funds are spendable through referendas created and voted on by the on-chain Governance, the treasury's iniative is to foster the Acurast ecosysem. Spending can range from development, operations, security, ecosystem support, grants, liquidity, marketing and more.
(d) Onchain Resource Usage
- Operational Funds - Association:
The opreation funds allocation assigned at Acurast Mainnet Genesis, have been assigned to the following address. https://hub.acurast.com/explorer/address/5EYCAe5iXhV27TdQGKANjpKWqMirf6zwK1wcMJnQLwWfQggS
This page shows the address's current ACU balance and full transfer history, so inflows and every outflow can be traced. - On-chain Treasury:
The on-chain treasury funds allocation assigned at Acurast Mainnet Genesis as well as the inflation rewards, have been assigned to the following address.
https://hub.acurast.com/explorer/address/5EYCAe5jXu2x3jF1rfyz6MQUZUpgQb59Mk7tFCutXDL6aFYP
This page shows the address's current ACU balance and full transfer history, so inflows and every outflow can be traced. - DevCos:
The Swiss DevCo and other contractors hold no protocol-controlled onchain resources. Payments to them appear as outflows from the Association and treasury addresses above.
Previous Exploits Affecting The Native Token
If any, list prior exploits or incidents that directly affected the token, token supply, tokenholder balances, token contract, minting controls, burn mechanics, or custody of token supply. This question is not asking about general protocol, application, or smart contract exploits unless the incident directly affected the native token itself. If no prior incidents, state this explicitly (e.g., "No exploits affecting tokenholders or protocol funds as of YYYY-MM-DD").
- (a) Date & component affected — Date (YYYY-MM or YYYY-MM-DD), chain(s)/component affected.
- (b) Exploit vector summary — Plain-language summary of the exploit vector (what the hack was).
- (c) Quantified impact — Quantified impact (assets/tokens affected or a clear "no loss of funds" statement).
- (d) Remediation/response taken — Remediation/response taken (patches, upgrades, governance actions, compensation).
- (e) Current status — Current status (resolved, in litigation, under investigation, refunded, etc.).
- (f) References (optional) — Link(s) to post-mortem/advisory/PR.
(a) Date & component affected
No exploits affecting tokenholders or protocol funds as of 2026-06-29
(b) Exploit vector summary
NA
(c) Quantified impact
NA
(d) Remediation/response taken
NA
(e) Current status
NA
(f) References (optional)
NA
[Optional] Offchain Foundation Or DevCo Income Statement
Provide a single income statement, expense summary, or comparable operating statement for the primary Foundation or Developer Company. A consolidated or entity-level presentation is acceptable. Balance Sheet and Statement of Cash Flows may be included but are not required. This item is intended to provide transparency into offchain operating resources and expenditures only.
Line Item | Amount |
|---|---|
NA | NA |
This Token Transparency Filing is provided for general informational purposes only. Blockworks reviews completeness only and does not verify or warrant the accuracy of individual answers. Acurast is solely responsible for the content, accuracy, and legality of its disclosures.