Project & Team
Description of Project
Provide a concise narrative that clearly states each of (a)–(e) below.
- (a) Problem the project solves — The problem the project is solving.
- (b) Operational priorities — Provide a high-level description of how the project expects to support ongoing development and operations over time.
- (c) High-level project overview — How the project works at a high level.
- (d) Primary token functions — The primary functions of the token (e.g. gov participation).
- (e) Control surface reliance — If any, briefly describe the anticipated or possible evolution of the protocol's governance/control model.
(a) Problem the project solves
Arweave is a permanent, decentralized data storage network designed to address data impermanence, censorship, and centralized control over information. The protocol's stated founding motivation is the preservation of knowledge in a form that cannot be altered, deleted, or controlled by any single entity.
(Source: Motivation | Arweave Docs, Arweave Lightpaper)
(b) Operational priorities
Arweave operates a storage-first architecture in which miners store replicated data, prove access to historical blocks through Succinct Proofs of Random Access, quote upload pricing, and split transaction fees between active miners and a protocol-level storage endowment. Adjacent infrastructure — including gateways, bundlers, and the AO compute layer — handles data distribution, upload scaling, and higher-level compute and application interfaces. Ongoing development is conducted by Minimum Spanning Technologies Ltd., the UK-incorporated company behind the protocol.
(Source: Protocol | Arweave Docs, Arweave Yellow Paper)
(c) High-level project overview
Arweave is a global peer-to-peer network that permanently stores multiple replicated copies of uploaded data using a blockweave structure — a variant of blockchain in which each block links to both the previous block and a randomly selected prior block. Consensus is achieved through a mining mechanism combining Succinct Proofs of Random Access and a Verifiable Delay Function. Users pay an upfront storage fee that is deposited into the storage endowment, which then disburses rewards to miners over time to incentivize long-term data preservation.
(Source: Protocol | Arweave Docs, Arweave Yellow Paper)
(d) Primary token functions
AR is the network's native token. It functions as the unit of payment for data upload fees, miner compensation, contributions to the storage endowment, and balance transfers between network participants.
(Source: HTTP API | Arweave Docs, Arweave Yellow Paper)
(e) Control surface reliance
Arweave does not operate a DAO or foundation-administered governance layer for routine parameter changes. Protocol evolution occurs through a fork-based social governance model in which miners and node operators signal adoption of software updates. Node operators exercise local discretion over content policies via their own Shepherd configurations or by loading a published content blacklist maintained by the ArweaveTeam GitHub account. The protocol's published governance principles describe protocol changes as requiring broad stakeholder consent rather than a standing tokenholder vote.
(Source: Fair Forks Paper, Principles of the Arweave Network, Transaction Blacklist | Arweave Docs)
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 |
|---|---|---|
Sam Williams | CEO and Co-Founder, Minimum Spanning Technologies Ltd. | PhD candidate in Computer Science, University of Kent (did not complete); Assistant Lecturer, University of Kent (2014–2017); developed the HydrOS distributed operating system; mentor at Techstars; technical advisor at Minespider; voting member at LAG Foundation |
William Jones | Co-Founder and CTO, Minimum Spanning Technologies Ltd. (July 2017–August 2018; departed) | PhD candidate in distributed systems and graph theory, University of Kent; AI and Machine Learning Lead at Embecosm from August 2019 |
Jesper Noehr | CTO | Founder and CEO of Bitbucket (acquired by Atlassian); founder of Upvest |
Sebastian Campos Groth | COO | Early-stage venture capital, business development, and project management background; co-author of official Arweave lightpaper |
Arweave / Minimum Spanning Technologies Ltd. does not publish a formal executive directory on arweave.org. The following individuals are identified through official published papers, The Org, Crunchbase, and public reporting.
Labs / DevCo — Minimum Spanning Technologies Ltd. (see table rows)
(Source: Sam Williams — The Org, William Jones — The Org, Sam Williams — IQ.wiki, CoinStats Arweave, Arweave Lightpaper)
Foundation
The project does not operate a foundation entity. No foundation was established as part of the AR token launch or subsequent operations. Ecosystem support functions are administered by Minimum Spanning Technologies Ltd. directly through grant programs including Arweave Grants and Arweave Boost.
(Source: Arweave: Get Funded, Arweave Medium — $8.3M Announcement)
DAO / Onchain Governance
The project does not operate a DAO or maintain a formal onchain governance leadership structure for the AR protocol. Protocol evolution occurs through a fork-based model. No standing DAO officer roster exists.
(Source: Fair Forks Paper, Principles of the Arweave Network)
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) Value accrual & holder rights — If any, describe the current rights of tokenholders over revenue distribution and the treasury.
- (e) Dissolution authority — State who can dissolve/wind up the DAO and by what mechanism (e.g., on-chain vote threshold, board resolution of a legal wrapper).
(a) IP ownership & control
The IP ownership of Arweave protocol code and the arweave.org brand is not publicly documented. Based on corporate records, Minimum Spanning Technologies Ltd. (company number 10889544, incorporated in England) is the most likely owner of protocol IP, but no public license filing or IP assignment document has been identified.
(b) Contract/admin powers
The project does not have a DAO executor or multisig governance layer with protocol-wide administrative powers. Node operators independently configure trusted peers for bootstrap connectivity, apply local content policies through Shepherd, and may load the ArweaveTeam NSFW blacklist. Protocol upgrade adoption occurs through software deployment and network-level miner consensus, not a standing admin authority. The arweave-standards GitHub repository serves as a public forum for standards discussion without binding governance authority.
(Source: Trusted Peers | Arweave Docs, Transaction Blacklist | Arweave Docs, GitHub — arweave-standards)
(c) Locked-token rights (conditional)
Not applicable. No AR locking or staking mechanism granting tokenholders additional governance rights exists at the protocol level.
(d) Value accrual & holder rights
AR tokenholders hold no formal claim to protocol revenue, treasury assets, or governance distributions. AR functions as the network's payment unit, with transaction fees directed to miners and the storage endowment. No DAO-governed revenue distribution mechanism exists.
(Source: HTTP API | Arweave Docs, Protocol | Arweave Docs)
(e) Dissolution authority
Not applicable. The project does not operate a DAO legal wrapper with a documented dissolution mechanism.
The Arweave protocol does not operate a DAO. There is no on-chain governance mechanism through which AR tokenholders vote on protocol parameters, treasury actions, or contract upgrades. The answers below reflect this structure.
Primary Foundation
For the Primary Foundation do the following independently. If an entity 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 are directly involved in the issuance of the native token at launch.
- (a) Entity — Type and jurisdiction.
- (b) IP ownership & control — What IP the entity owns/controls (repos/code, trademarks/brand; license optional) 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. revenue), token administration, or reward parameters, and the method/threshold for each.
- (d) Powers over DevCo — Explain whether the foundation can exert direct or indirect influence over decision-making of the DevCo.
- (e) Contract/admin powers — Pause/upgrade/governance-executor authorities and the method/threshold for each (e.g., veto/majority/super-majority; "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 project does not operate a primary foundation entity. No foundation was directly involved in the issuance of AR at launch or in subsequent token administration. Items (a) through (f) do not apply.
(Source: Arweave: Legal Policies, Arweave: Get Funded)
Primary Dev Co
For the Primary DevCo do the following independently. If an entity 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 are directly involved in the issuance of the native token at launch.
- (a) Entity — Type and jurisdiction.
- (b) IP ownership & control — What IP the entity owns/controls (repos/code, trademarks/brand; license optional) 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. revenue), token administration, or reward parameters, and the method/threshold for each.
- (d) Powers over Foundation — Explain whether the DevCo can exert direct or indirect influence over decision-making of the Foundation.
- (e) Contract/admin powers — Pause/upgrade/governance-executor authorities and the method/threshold for each (e.g., veto/majority/super-majority; "3/5 multisig").
- (f) Current economic arrangements and distribution policies — Describe any current governance-approved, contractual, or programmatic mechanisms, if any, by which protocol-controlled resources, treasury assets, fees, revenue, rewards, or token distributions may be directed to this entity, its equityholders, contributors, or other participants. If no such mechanism currently exists, state that explicitly. Do not discuss hypothetical future dividends, repurchases, or distributions unless formally adopted.
(a) Entity
The primary DevCo is Minimum Spanning Technologies Ltd., the UK-incorporated private limited company through which AR was issued and protocol development is conducted.
Minimum Spanning Technologies Ltd. is a private limited company incorporated in England and Wales on 28 July 2017 (company number 10889544). Its registered address is International House, London, EC3V 3NG, United Kingdom. The company operates under the trade name Arweave.
(Source: Companies House record via companyinformation.co.uk, Arweave: Legal Policies)
(b) IP ownership & control
The specific IP assets owned or licensed by Minimum Spanning Technologies Ltd. — including the arweave.org codebase, brand trademarks, and protocol repositories — are not publicly documented in any filed IP assignment, trademark registration, or open-source license identified in public sources. The ArweaveTeam GitHub organization hosts protocol repositories but does not publish a governing IP ownership or license statement.
(c) Powers over DAO, treasury, protocol-controlled resources, and token administration
No DAO exists. Minimum Spanning Technologies Ltd. does not administer protocol-controlled treasury resources or reward parameters through any disclosed on-chain mechanism. The company issues grants and ecosystem funding directly from its operating resources, as evidenced by the Arweave Grants and Arweave Boost programs.
(Source: Arweave Medium — $8.3M Announcement)
(d) Powers over Foundation
Not applicable. No foundation entity exists.
(e) Contract/admin powers
No public disclosure identifies specific multisig keys, admin wallet addresses, or upgrade authority mechanisms held by Minimum Spanning Technologies Ltd. over the Arweave protocol. The company maintains the ArweaveTeam GitHub organization, through which official node software is published.
(f) Current economic arrangements and distribution policies
No governance-approved, contractual, or programmatic mechanism by which protocol fees or treasury assets are directed to Minimum Spanning Technologies Ltd. or its equityholders has been publicly disclosed. The storage endowment and mining reward distributions are protocol-level and not directed to the DevCo by design — however, any off-chain fee arrangements or equity dividend structures involving the company are not addressed in public sources.
Token Supply & Allocations
Initial Allocation
Disclose launch and initial supply details in a single initial allocation schedule covering the token's launch. Include: (a) Launch supply totals — the total number of tokens issued at launch, the total number of tokens locked at launch or the total number of tokens unlocked at launch; (b) Recipient categories & use of funds — the recipient categories with brief explanations as to how the category will use the tokens so an auditor can distinguish each bucket; (c) Initial price per token (if applicable) — the initial price per token at TGE. If the token launched via a liquidity bootstrapping mechanism, auction, or other price-discovery process rather than a fixed offering price, describe that mechanism and the final market set price instead. If no fixed price was set, state so; (d) Ticker / market symbol — the ticker/market symbol; (e) Total supply & supply regime — the total supply and whether the supply is fixed (if not explain inflation rate or deflation rate); (f) Initial vesting / release schedules — the initial vesting/release schedules (identify which categories/recipients are subject to vesting and the high-level timing logic).
Launch Supply Totals | Recipient Categories & Use of Funds | Initial Price per Token | Ticker / Market Symbol | Total Supply & Supply Regime | Initial Vesting / Release Schedules |
|---|---|---|---|---|---|
55,000,000 AR were created in the genesis block at network launch on 8 June 2018. An additional 11,000,000 AR are introduced gradually as block mining rewards over time, establishing a hard maximum supply of 66,000,000 AR. The public record does not disclose a separate locked-versus-unlocked schedule for the genesis block tokens at launch. (Source: Arweave Yellow Paper, CoinMarketCap — Arweave) | The following allocation breakdown is sourced from CoinMarketCap's summary of publicly disclosed distribution data: | The public token sale conducted in June 2018 priced AR at $0.73 USD per token. The sale ran from 1 June 2018 to 6 June 2018, with a hard cap of $8.7 million. The ICO raised approximately $8.7 million. A pre-sale event in August 2017 preceded the public sales; the per-token price for that event is not publicly disclosed in sources reviewed here. (Source: CoinCodex — Arweave ICO, IQ.wiki — Arweave, businessmodelcanvastemplate.com — Arweave History) | AR (Source: Arweave Yellow Paper) | The maximum supply is 66,000,000 AR. The supply is effectively fixed at this ceiling. The 55,000,000 genesis tokens are fully issued. The remaining 11,000,000 AR enter circulation gradually as block mining rewards; as of 4 June 2026, circulating supply stands at approximately 65,652,466 AR. AR is not a deflationary token — no burn mechanism exists — but the storage endowment sequesters a portion of transaction fees from active circulation, releasing them to miners over time. (Source: Arweave Yellow Paper, KuCoin AR Price) | The team allocation (13% of initial supply) is subject to a five-year lock-up with 20% released annually. The future project use allocation (26.5% of initial supply) is subject to the same five-year lock-up structure with 20% released annually. No vesting terms for the pre-sale, private sale, public sale, or advisor allocations are disclosed in public sources reviewed here. (Source: CoinMarketCap — Arweave, IQ.wiki — Arweave) |
Airdrop Process
Address each of the following sub-items based on the project's airdrop status. If a sub-item does not apply to the project's situation, state that explicitly.
- (a) Planned but not yet executed airdrop — If the project has planned but not yet airdropped, commit to publishing a recipient wallet list in a public channel and provide it to Blockworks quarterly until the initial TGE airdrop is fully completed. Additionally, generally state the possible target user segments (e.g., "stakers of X," "Aave users") and the allocation method (e.g., proportional to ve-balance or net position).
- (b) Executed airdrop — If the project has already airdropped, point to a per-address source such as CSV/TSV/JSON files, a Dune table, a full Merkle dump, GitHub repo files embedding per-address allocations, or RPC endpoints that expose claim/amount data; explorer links alone do not count. Additionally, clearly state covered user segments (e.g., "stakers of X," "Aave users") and the allocation method (e.g., proportional to ve-balance or net position).
- (c) No airdrop planned or conducted — If the project does not plan to conduct an airdrop for TGE and has never conducted one, state so plainly (e.g., "We have never conducted an airdrop to date and do not plan to execute one").
(c) No airdrop planned or conducted
Arweave has never conducted a token airdrop for AR and does not plan to execute one. The AR token distribution model consists of the genesis block allocation, pre-sale and public token sales, and gradual mining reward issuance. No airdrop recipient list, allocation methodology, or planned airdrop has been identified in public sources.
(Source: Arweave Yellow Paper, CoinMarketCap — Arweave)
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.
Minimum Spanning Technologies Ltd. has not publicly disclosed any market-making agreements involving AR token loans, call options, or retainer arrangements. No market maker agreement terms, counterparty names, or token loan amounts are identified in public sources.
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.
Minimum Spanning Technologies Ltd. has not publicly disclosed the material terms of any centralized or decentralized exchange listing agreements, including any token allocations for listing, listing fee payments in AR, or associated lockup or incentive programs.
Financial Disclosures & Risks
Prior Token Sales & Fundraising
Disclose all prior token sales by the Project — including fundraising rounds, any material OTC sales to investors, and any discounted market-maker sales. For each sale, provide: (a) Series Name; (b) Early-Stage Investment Instrument used (i.e. SAFT, STAMP, SAFE, SAFE+Token Warrant, etc.); (c) Date of sale (at least month & year); (d) Number of tokens sold (or % of total supply); (e) Vesting schedule. If no prior sales occurred, state that explicitly (e.g., "No prior fundraising, OTC, or discounted MM sales have occurred.").
Series Name | Investment Vehicle | Date Of Sale | Number of tokens sold | Vesting Schedule |
|---|---|---|---|---|
Pre-sale (token) | Not publicly disclosed | August 2017 | 10.8% of initial supply | Not publicly disclosed |
ICO / Public Sale — Part 1 | Not publicly disclosed | May 2018 | 7.1% of initial supply | None disclosed |
ICO / Public Sale — Part 2 | Not publicly disclosed | June 2018 | 1.1% of initial supply (20.6% total including prior sales) | None disclosed |
Equity / Token Round (Seed) | Not publicly disclosed | November 2019 | Not publicly disclosed | Not publicly disclosed |
Equity / Token Round (Series A) | Not publicly disclosed | March 2020 | Not publicly disclosed | Not publicly disclosed |
The following equity and token fundraising events are identified in public sources. The specific legal instruments used (e.g., SAFT, SAFE, token warrant) are not publicly disclosed in sources reviewed here.
Amount raised and investors disclosed in the source table (no matching columns in this schema):
- Pre-sale (token), August 2017 — Amount Raised: Not publicly disclosed; Investors: Not publicly disclosed
- ICO / Public Sale — Part 1, May 2018 — Amount Raised: Included in ICO total; Investors: Public / community
- ICO / Public Sale — Part 2, June 2018 — Amount Raised: ~$8.7M total ICO raise; Investors: Arrington XRP Capital, 1kx, Coefficient Ventures, Benjamin Kong
- Equity / Token Round (Seed), November 2019 — Amount Raised: $5,000,000; Investors: a16z Crypto (lead), Union Square Ventures, Multicoin Capital
- Equity / Token Round (Series A), March 2020 — Amount Raised: $8,300,000; Investors: Andreessen Horowitz, Union Square Ventures, Coinbase Ventures
(Source: CoinMarketCap — Arweave, IQ.wiki — Arweave, CoinTelegraph — $5M Round, Arweave Medium — $8.3M, businessmodelcanvastemplate.com — Arweave History)
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.
No exploits affecting AR tokenholders or protocol funds have been identified in public sources as of 2026-06-17. The official Arweave release notes document software and operational incidents — including desync fixes, coordinated-mining failures, double-signing detection race conditions, and chunk-handling regressions — but the official release record states that no funds were at risk in connection with any of these incidents.
(Source: Arweave Release Notes N.2.9.5, Releases — ArweaveTeam/arweave — GitHub)
Material Risk Factors (Regulation, Technology, Token Economics)
Describe material risk factors across the three categories below. Each category includes prompts to address at a minimum.
- (a) Regulatory, Legal & Tax Risks — Describe how evolving laws and regulations could affect the project by answering, at a minimum, questions like:
- Impact of Regulatory Change on TGE and Listings: (If applicable) How could evolving or conflicting laws and regulations affect your ability to complete the TGE, deliver tokens to purchasers, and list or maintain the token on trading venues in key jurisdictions?
- Entity-Level Regulatory Impact: (If applicable) How could regulatory or legal changes impact your core entities (Foundation, DevCo, DAO, affiliated service providers), including enforcement actions, licensing requirements, or forced changes to structure or operations?
- Tokenholder Tax Treatment: (If applicable) What uncertainties exist around how tokenholders may be taxed, and make clear that tokenholders are responsible for understanding their own tax obligations?
- Jurisdictional & User Access Restrictions: (If applicable) If the project restricts access for certain jurisdictions or user types (e.g., U.S. persons, sanctioned countries, retail vs. professional), what are those restrictions and what risks do they create for users and for the project?
- (b) Protocol, Technology & Security Risks — Describe risks to network and contract reliability, correctness, and safety by answering, at a minimum, questions like:
- Bugs and Design Flaws: (If applicable) What bugs, design flaws, or implementation errors could exist in your core protocol code, smart contracts, and any bridges, rollups, or oracles that you depend on, and how could these lead to loss of funds or disruption of the protocol?
- Security Measures & Their Limitations: (If applicable) What security measures have you taken (audits, formal verification, bug bounties), and what types of failures might these measures still fail to detect or prevent?
- (c) Token Economics, Unlocks & Incentive Risks — Describe how the token's economic design and supply schedule could affect holders by answering, at a minimum, questions like:
- Critical Economic Assumptions: (If applicable) Which economic assumptions (e.g., staking yields, fee revenue, liquidity incentives, MEV capture, demand for blockspace) are critical for protocol security, utility, and governance, and what happens if those assumptions fail?
- Governance Control over Monetary Policy & Rewards: (If applicable) To what extent can governance change monetary policy, fee parameters, or reward allocations (e.g., inflation rate, treasury flows, incentive programs), and how could such changes adversely affect tokenholders?
(a) Regulatory, Legal & Tax Risks
(a) Impact of regulatory change on TGE and listings
Arweave completed its token generation event in July 2018. Future regulatory changes in key jurisdictions — including the United States, EU member states, and jurisdictions where AR is actively traded — could affect the ability of exchanges to continue listing AR or require Minimum Spanning Technologies Ltd. to alter how it describes or administers the protocol. The company has not publicly disclosed a jurisdiction-specific listing compliance strategy.
(Source: Arweave: Legal Policies)
(b) Entity-level regulatory impact
Minimum Spanning Technologies Ltd. operates arweave.org and processes user data under GDPR-oriented privacy policies. Evolving privacy regulation, consumer protection enforcement, or virtual asset service provider licensing requirements in the UK, EU, or other jurisdictions could affect the company's website operations, grant programs, and protocol development activities. The company has not publicly disclosed its approach to VASP compliance or any regulatory licensing it holds.
(Source: Arweave: Legal Policies, Privacy Policy | Arweave Docs)
(c) Tokenholder tax treatment
Arweave has not published guidance on the tax treatment of AR for tokenholders. Tax classification of AR — as property, a commodity, a security, or otherwise — varies by jurisdiction and is subject to change. Tokenholders are responsible for understanding and complying with their own applicable tax obligations.
(Source: Arweave: Legal Policies)
(d) Jurisdictional and user access restrictions
Arweave's legal materials require users to comply with applicable laws in their own jurisdictions when storing personal or confidential data on the network. No tokenholder jurisdiction-blocking matrix for AR purchases or transfers is disclosed in public sources. Users in jurisdictions where AR may be classified as a regulated financial instrument are responsible for determining whether their use of the protocol or token is permissible.
(Source: Arweave: Legal Policies)
(b) Protocol, Technology & Security Risks
(a) Bugs and design flaws
Arweave's technology risk surface encompasses mining-logic bugs, coordinated-mining failures, syncing stalls, VDF client issues, validation defects, desync conditions, and storage-replica handling regressions, all of which are documented in the official GitHub release notes. The protocol relies on trusted peer configurations, external or self-run VDF infrastructure, and optional local content blacklisting tools, meaning defects or misconfiguration across any of these layers can degrade service quality independently of any centralized admin function.
(Source: Releases — ArweaveTeam/arweave — GitHub, Trusted Peers | Arweave Docs, VDF | Arweave Docs)
(b) Security measures and their limitations
The Arweave protocol uses storage-oriented cryptography and RandomX-based data packing as core security mechanisms. The RandomX project has completed four independent security audits without identifying critical vulnerabilities. Despite these measures, official Arweave release notes document post-design implementation bugs and operational failures that required patches, confirming that audit coverage does not eliminate ongoing implementation risk.
(Source: Arweave Lightpaper, GitHub — tevador/RandomX, Releases — ArweaveTeam/arweave — GitHub)
(c) Token Economics, Unlocks & Incentive Risks
(a) Critical economic assumptions
Arweave's token economics depend on sustained storage demand, continued miner participation under the fee-and-endowment incentive model, and the storage endowment retaining sufficient purchasing power as storage hardware costs evolve over time. The protocol's economic model explicitly relies on Kryder+-style declining storage cost assumptions to ensure the endowment can fund future miner payouts. If storage demand declines, miners exit the network, or storage cost trajectories diverge materially from model assumptions, the long-term economics supporting permanent data preservation could weaken.
(Source: Protocol | Arweave Docs, Arweave Yellow Paper)
(b) Governance control over monetary policy and rewards
No tokenholder voting mechanism exists for routine AR monetary policy changes. Protocol evolution — including any changes to block reward schedules, fee structures, or mining parameters — occurs through software forks and network-level adoption by miners and node operators. Material changes to the reward structure can arise from software evolution without a formal tokenholder approval process, and no supermajority threshold or veto mechanism constrains such changes.
(Source: Fair Forks Paper, Principles of the Arweave Network, Protocol | Arweave Docs)
This Token Transparency Filing is provided for general informational purposes only and does not verify or warrant the accuracy of individual answers.