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
Stablecoins are not yet a complete alternative to traditional banking. Users can hold and transfer stablecoins, but everyday spending, reliable financial accounts, portable credit history and access to real-world borrowing still depend heavily on banks and other centralized institutions.
(b) Operational priorities
Avici’s near-term priorities are stablecoin-powered cards, internet-native accounts and savings products. Longer-term priorities include a portable trust score and onchain credit.
(c) High-level project overview
Avici is a Solana-based distributed internet banking project that combines stablecoin wallets, cards, financial accounts and related financial tools. Over time, Avici aims to provide portable financial identity and real-world lending.
(d) Primary token functions
AVICI is the project’s ownership coin powered by Metadao. AVICI may be staked to activate proposals. Holding AVICI does not provide equity or an automatic dividend, revenue distribution or redemption right. Any future distribution of revenue or treasury assets would require a successful decision-market proposal.
(e) Control surface reliance
Governance uses futarchy, where proposals are evaluated through conditional pass and fail markets. The governance model, treasury policies and token parameters may evolve through future approved proposals.
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 |
|---|---|---|
Sitaram Kakarlamudi | Co-founder & CEO | Previously built Librty, formerly Higin, a blockchain gaming infrastructure company backed by NFX and Polygon Ventures. |
Abhishek Tiwari | Co-founder & COO | Previously built Librty and, before that, a decentralized freelancing platform using smart-contract-based automatic settlements. |
Varun Lohade | Co-founder & founding engineer | Previously build Librty as a mobile dev |
Foundation
Full Name | Official Title | Prior Experience |
|---|---|---|
No separate foundation exists. | Not applicable | Not applicable |
DAO / Onchain Governance
Full Name | Official Title | Prior Experience |
|---|---|---|
Sitaram Kakarlamudi | Initial Member and Princeps | Co-founder and CEO of Avici Inc and initial member of the DAO’s legal wrapper. |
DAO Structure
Provide a structured description of the DAO's governance, powers, and economic rights. If a DAO does not exist, state so for each sub question. Even if there is no DAO, there must be an answer to (d). Address the lettered items below.
- (a) IP ownership & control — State what IP the DAO owns or controls (e.g., codebases/repos, trademarks/brands). Note any license if relevant.
- (b) Contract/admin powers — List on-chain or administrative authorities and limits: pause/upgrade roles (e.g., multisig pause), governance-executor authorities, and the method of authority for each (e.g., veto, majority, super-majority).
- (c) Locked-token rights (conditional) — If locking/staking for additional rights exists, explain the additional rights and what tokenholders can and cannot decide. If no locking mechanism exists, leave absent.
- (d) Current tokenholder governance rights and economic arrangements — If any, describe the current governance rights of tokenholders and any presently operative rights or arrangements relating to treasury actions, fee-routing, rewards, buybacks, or other protocol-controlled resources. If none, state that explicitly.
- (e) Control surface reliance — If any, briefly describe the anticipated or possible evolution of the protocol's governance/control model.
- (f) Dissolution authority — State who can dissolve/wind up the DAO and by what mechanism (e.g., on-chain vote threshold, board resolution of a legal wrapper).
(a) IP ownership & control
Jester DAO LLC, owns all contributed project IP and assets, including the Avici brand, website, social accounts, GitHub repositories, logo and related technology. IP created by Avici Inc while providing services to the DAO also belongs to Jester DAO LLC. If an assignment cannot legally take effect, the agreements provide the DAO LLC with an exclusive, perpetual and worldwide license.
(b) Contract/admin powers
Ordinary governance approval: Avici uses MetaDAO decision markets. Permissionless proposals require 1,500,000 AVICI in aggregate stake to activate. The proposal period is 72 hours, with TWAP recording beginning after the first 24 hours. An ordinary proposal passes only when the final pass-market time-weighted average price exceeds the fail-market TWAP by more than 3%.
Governance execution and token administration: The Futarchy program acts through Avici’s DAO program-derived address to approve successful proposals in the DAO’s Squads multisig. Squads then executes the approved transaction under its execution checks. The DAO address is the sole voting member; a separate permissionless account can initiate and execute transactions but cannot approve them. AVICI mint authority is held by the DAO treasury vault.
Routine spending authority: The DAO’s Squads spending-limit account authorises two wallet addresses: 5XmgUdxfKBfyH8RjYdxYSegdQHLqWqU2NG1SZznv9D7g and G7qs9MUFquwnSFtrDU6261KtovKRg8GS4s6bFbmLiBiQ. Either address can independently authorise a transfer with its signature, without a separate governance proposal or additional multisig approval. The individual controllers of these addresses have not been independently verified.
The configured spending limit is 100,000 USDC in aggregate per 30-day period, shared between both authorised wallets. Transfers are limited to the remaining allowance from treasury vault index 0. No destination-address restriction is configured, and no separate per-transaction cap applies beyond the remaining allowance. Separately, the Services Agreement imposes an annualised expenditure cap of $1.2 million unless mutually approved otherwise. This contractual cap is distinct from the onchain 30-day spending limit.
Pause and freeze: No dedicated global pause authority was identified in the reviewed Futarchy source code. AVICI’s token mint has no freeze authority. These findings do not remove the ability to change governance functionality through a program upgrade.
Upgrade authority: The Futarchy program’s upgrade authority is MetaDAO’s Squads vault, 6awyHMshBGVjJ3ozdSJdyyDE1CTAXUwrpNMaRGMsb4sf. Its controlling multisig currently requires approval from three of six voting members and has no configured timelock. MetaDAO identifies Organization Technology L.L.C. as directing this multisig. Authorised upgrades can change program logic and administrative controls.
Proposal blocking and cancellation: The reviewed production source designates administrator address CWGawadYU8CzRVBecnJymNw97H7E3ndDinV5sMzesgY2. A signature from this address authorises removal of a draft proposal or cancellation of an active, pending proposal. Cancellation resolves the pending proposal as failed. These functions do not themselves apply to already-finalised proposals. The code does not require a tokenholder vote or an objective finding of malicious conduct for these actions. Any additional internal approval process for this administrator has not been confirmed.
Additional administrative execution: The reviewed source permits MetaDAO’s multisig to authorise a separate Squads proposal-approval process. That path requires the multisig’s approval threshold and is available only when the DAO is in spot-market state with no active optimistic proposal. The designated administrator can also execute approved Squads transactions under those state restrictions and Squads’ transaction-execution checks.
MetaDAO describes intervention as intended for extreme scenarios, but that stated purpose is not a technical restriction limiting upgrades or administrative actions to malicious proposals. Onchain account settings were verified; descriptions of instruction behaviour are based on published source code, without a completed source-to-deployed-binary verification.
(c) Locked-token rights (conditional)
AVICI has no token-locking mechanism that grants additional voting, governance, revenue or treasury rights. Separately, a proposal must accumulate 1,500,000 AVICI in permissionless stake before it can enter the decision-market process. Multiple tokenholders may contribute toward this requirement, and the tokens are returned after the proposal goes live, with no slashing or long-term lockup.
(d) Current tokenholder governance rights and economic arrangements
AVICI holders can presently create proposals, contribute tokens toward proposal activation, and participate in conditional pass/fail markets. Through successful proposals, governance can direct treasury expenditure, token issuance, protocol-owned liquidity, governance parameters and the management or disposition of DAO-owned IP and other assets. Outcomes are determined by market prices rather than a one-token-one-vote ballot. Holding AVICI alone does not confer ownership of DAO assets or an individual withdrawal right.
A separate, approved team reward arrangement exists under AVICI-001, authorising up to 8,240,000 performance-based AVICI tokens subject to specified milestones and release restrictions. No standing fee distribution, holder staking reward, dividend, treasury-redemption or AVICI buyback programme is identified in the reviewed agreements and approved proposals. Any new holder distribution or buyback would require decision market approval.
(e) Control surface reliance
Avici DAO currently relies on MetaDAO decision-market governance for treasury actions, token issuance and other material protocol decisions. The governance framework may evolve through successful decision-market proposals as the system matures, including changes to proposal thresholds, execution processes, treasury controls and token parameters. MetaDAO currently retains an emergency override capability while its system is in beta; that dependency may be reduced or removed as the governance infrastructure matures. No such change can be made unilaterally by Avici Inc. or the development team.
(f) Dissolution authority
Voluntary dissolution of Jester DAO LLC is authorized through the Futarchic Mechanism under Article X of its Operating Agreement. Any person may submit a dissolution proposal. To activate an ordinary permissionless proposal, participants must collectively stake 1,500,000 AVICI. The proposal runs for 72 hours, with TWAP recording beginning after 24 hours, and passes only if the final pass-market TWAP exceeds the fail-market TWAP by more than 3%. Approval is determined by this market outcome rather than a majority ballot of tokenholders.
Following approval, the LLC’s members implement the dissolution and winding-up, using specifically authorised agents where appropriate.Dissolution and winding-up remain subject to applicable Marshall Islands law, including circumstances where the law independently requires dissolution.
Primary Foundation
For the Primary Foundation do the following independently. If a Foundation does not exist, state so for each sub question. Items (a)–(f) apply only if that entity exists; state explicitly that the entity doesn't exist. Definition: The primary Foundation can be explained as the entity which is directly involved in the issuance of the native token at launch.
- (a) Entity — Type and jurisdiction.
- (b) IP ownership & control — What IP the entity owns/controls (repos/code, trademarks/brand; license optional)
- (c) Powers over DAO, treasury, protocol-controlled resources, and token administration — If any, describe the current powers over DAO governance, treasury actions, protocol-controlled resources (e.g. revenue), token administration, or reward parameters, and the method/threshold for each.
- (d) Powers over DevCo — Explain whether the foundation can exert direct or indirect influence over decision-making of the DevCo.
- (e) Contract/admin powers — Pause/upgrade/governance-executor authorities, and the method/threshold for each (e.g., veto/majority/super-majority).
- (f) Current economic arrangements and distribution policies — Describe any current governance-approved, contractual, or programmatic mechanisms, if any, by which protocol-controlled resources, treasury assets, fees, revenue, rewards, or token distributions may be directed to this entity, its equityholders, contributors, or other participants. If no such mechanism currently exists, state that explicitly.
(a) Entity
No separate foundation exists. Therefore, items (a)–(f) are not applicable. The project’s primary legal wrapper is Jester DAO LLC, a Marshall Islands DAO LLC, rather than a foundation.
(b) IP ownership & control
No Primary Foundation exists.
(c) Powers over DAO, treasury, protocol-controlled resources, and token administration
No Primary Foundation exists.
(d) Powers over DevCo
No Primary Foundation exists.
(e) Contract/admin powers
No Primary Foundation exists.
(f) Current economic arrangements and distribution policies
No Primary Foundation exists.
Primary DevCo
For the Primary DevCo do the following independently. If an entity does not exist, state that explicitly across each sub-question. Items (a)–(f) apply only if that entity exists; state explicitly that the entity doesn't exist. Definition: The primary DevCo can be explained as the entity which is directly involved in the issuance of the native token at launch.
- (a) Entity — Type and jurisdiction.
- (b) IP ownership & control — What IP the entity owns/controls (repos/code, trademarks/brand; license optional)
- (c) Powers over DAO, treasury, protocol-controlled resources, and token administration — If any, describe the current powers over DAO governance, treasury actions, protocol-controlled resources (e.g. revenue), token administration, or reward parameters, and the method/threshold for each.
- (d) Powers over Foundation — Explain whether the DevCo can exert direct or indirect influence over decision-making of the Foundation.
- (e) Contract/admin powers — Pause/upgrade/governance-executor authorities and the method/threshold for each (e.g., veto/majority/super-majority; "3/5 multisig").
- (f) Current economic arrangements and distribution policies — Describe any current governance-approved, contractual, or programmatic mechanisms, if any, by which protocol-controlled resources, treasury assets, fees, revenue, rewards, or token distributions may be directed to this entity, its equityholders, contributors, or other participants. If no such mechanism currently exists, state that explicitly. Do not discuss hypothetical future dividends, repurchases, or distributions unless formally adopted.
(a) Entity
The Primary DevCo exists. Avici Inc. is a Delaware C-Corporation incorporated under the laws of Delaware, United States, and serves as the project’s primary development and operating company.
(b) IP ownership & control
The Primary DevCo exists and is Avici Inc. Avici Inc. owns no Avici project repositories, code, smart contracts, technical documentation, trademarks, brand names, logos, project websites, social-media accounts, or other project intellectual property. It does not independently control those assets. Any access or administrative control it has over the Avici-Labs GitHub organisation, codebase, website, or brand accounts is limited to performing services for Jester DAO LLC and is exercised on Jester DAO LLC’s behalf. Under the Services Agreement, all intellectual property created by Avici Inc. while performing those services is owned by Jester DAO LLC. Jester DAO LLC’s Operating Agreement lists the Avici-Labs GitHub organization, website, social accounts, and logo mark as contributed DAO assets. Avici Inc. has no identified subsidiaries.
(c) Powers over DAO, treasury, protocol-controlled resources, and token administration
The Primary DevCo exists and is Avici Inc. Its operating role and compensation are governed by the Services Agreement and the limited monthly allowance described in 5(f). The reviewed agreements grant Avici Inc. no additional unilateral, joint, delegated, conditional or approval-dependent powers over DAO governance, treasury policy, protocol-controlled resources, token issuance or reward parameters. Avici Inc. cannot bind Jester DAO LLC. Authority exercised by an individual as a DAO member or authorized treasury operator is separate from authority held by Avici Inc.
(d) Powers over Foundation
No Primary Foundation exists; therefore, this question is not applicable.
(e) Contract/admin powers
The Primary DevCo exists and is Avici Inc. Avici Inc. holds no contract or administrative powers over the DAO or protocol. Specifically, it has no pause, upgrade, governance-executor, mint, freeze, veto, or multisig authority, whether unilateral, joint, delegated, conditional, or approval-dependent. Accordingly, no method or threshold applies to Avici Inc. for any such authority.
(f) Current economic arrangements and distribution policies
Jester DAO LLC pays Avici Inc. for development and operating services under the Services Agreement dated October 13, 2025. Sections 2.1–2.4 provide for direct costs plus a markup of no more than 25%, subject to a minimum monthly base fee of $100,000, payable in advance in US dollars or stablecoin equivalent. The base fee may be adjusted by mutual agreement. Section 2.6 caps the annualized rate of expenditure at $1.2 million; expenses above that amount require mutual approval.
The $100,000 operating allowance formed part of the initial launch terms and treasury configuration. No separate passed decision-market proposal approving the initial allowance has been identified in the reviewed records. The DAO’s current Squads spending limit permits an aggregate 100,000 USDC per 30-day period, as described in 3(b).
Separately, the approved AVICI-001 proposal establishes a performance-based team reward arrangement of up to 8,240,000 AVICI, subject to its milestones and release restrictions.
Token Supply & Allocations
Initial Allocation
Download the Worksheet, enable macros, complete the Initial Allocation sheet, then use Convert To CSV to export the file for import here. To make edits after importing, update the worksheet, use Convert To CSV again, then re-import the new CSV.
Ticker | Date | Allocation Category Name | Recipient Type | Allocation % | Allocation Tokens | TGE Unlock % | TGE Unlock Tokens | Cliff Months | Cliff Unlock % | Linear Vesting Months | Cadence Months | Circulating Treatment | Notes on what each category is used for | If applicable: Contract / Wallet address |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
AVICI | 2025-10-18 | Public ICO | Public / Sale | 0.7751937984496124 | 10000000 | 1 | 10000000 | 0 | 0 | 0 | 1 | No | Distributed pro rata to MetaDAO public-sale participants; 100% unlocked at TGE with no time-based vesting. Team and Foundation allocation at TGE: 0 AVICI. Source: https://docs.avici.org/avici-dao/token-sale-and-supply | |
AVICI | 2025-10-18 | Futarchy AMM Liquidity | Market Structure | 0.15503875968992248 | 2000000 | 1 | 2000000 | 0 | 0 | 0 | 1 | No | Protocol-controlled liquidity allocated to the Futarchy AMM at TGE; no time-based vesting. Source: https://docs.avici.org/avici-dao/token-sale-and-supply | |
AVICI | 2025-10-18 | Meteora Liquidity | Liquidity | 0.06976744186046507 | 900000 | 1 | 900000 | 0 | 0 | 0 | 1 | No | Protocol-controlled liquidity allocated to the Meteora pool at TGE; no time-based vesting. Source: https://docs.avici.org/avici-dao/token-sale-and-supply | |
AVICI | 2025-10-18 | |||||||||||||
AVICI | 2025-10-18 | |||||||||||||
AVICI | 2025-10-18 | |||||||||||||
AVICI | 2025-10-18 | |||||||||||||
AVICI | 2025-10-18 | |||||||||||||
AVICI | 2025-10-18 | |||||||||||||
AVICI | 2025-10-18 | |||||||||||||
AVICI | 2025-10-18 | |||||||||||||
AVICI | 2025-10-18 | |||||||||||||
AVICI | 2025-10-18 | |||||||||||||
AVICI | 2025-10-18 | |||||||||||||
AVICI | 2025-10-18 |
Airdrop Process
State the project's airdrop status plainly, and back it up:
- Never conducted and none planned for TGE: state so plainly.
- Planned but not yet executed: state the target user segments (e.g., "stakers of X," "Aave users") and the allocation method (e.g., proportional to balance or net position), and commit to publishing a recipient wallet list in a public channel and providing it to Blockworks quarterly until the initial TGE airdrop is fully completed.
- Already executed: state the covered user segments and the allocation method, and point to a per-address source such as CSV/TSV/JSON files, a Dune table, a full Merkle dump, GitHub repo files embedding per-address allocations, or RPC endpoints that expose claim/amount data; explorer links alone do not count.
Never did an airdrop or promised any Airdrop or have plans to do so in the future.
Transactions & Market Structures
Market Maker Agreements & Deals
Projects must disclose all material terms of market-making arrangements that affect token liquidity. If the project has no agreements or deals with market makers, state that explicitly. For each market maker, include in a table:
- (a) Market maker's name — the market maker's name;
- (b) Token allocation or loaned amount — the token allocation or loaned amount as a percentage of total supply;
- (c) Duration/term of agreement — the duration/term of the agreement; and, where applicable,
- (d) Name of agreement structure — label the financial vehicle being used in the agreement (i.e. loan, option/call, retainer model).
If no native tokens were loaned or allocated to market makers, state that explicitly; cash/fiat retainers or fees are not required for (b).
Market Maker Name | Token Allocation Committed | Term Duration | Structure Name |
|---|---|---|---|
None — no market maker agreements |
Exchange Agreements & Deals
Projects must disclose all material terms of centralized or decentralized exchange listings that affect token liquidity. For each listing, include in a table:
- (a) Exchange name / DEX pool — the exchange name (and, for DEX, the specific pool/pair);
- (b) Token allocation for listing — the token allocation supplied or committed for listing as a percentage of total supply;
- (c) Term Duration — the duration/term of any listing lockups, liquidity, or incentive programs; and, where applicable,
- (d) Native-token listing fees — whether any listing fees were paid in native tokens, with amounts (tokens or % of supply), recipients, and any vesting or lock terms tied to the partnership.
If the project has no agreements or deals with CEX or DEX, state that explicitly; doing so earns full credit; cash/fiat fee amounts are not required for this item.
Exchange Name | Token Allocation Committed | Term Duration | Native Token Listing Fees |
|---|---|---|---|
None |
Financial Disclosures & Risks
Prior Token Sales & Fundraising
Disclose all prior token sales by the Project — including fundraising rounds, any material OTC sales to investors, and any discounted market-maker sales. For each sale, provide:
- (a) Series Name;
- (b) Early-Stage Investment Instrument used (i.e. SAFT, STAMP, SAFE, SAFE+Token Warrant, etc.);
- (c) Date of sale (at least month & year);
- (d) Number of tokens sold (or % of total supply);
- (e) Vesting schedule.
If no prior sales occurred, state that explicitly (e.g., "No prior fundraising, OTC, or discounted MM sales have occurred.").
Series Name | Investment Instrument | Date Of Sale | Number of tokens sold | Vesting Schedule |
|---|---|---|---|---|
no prior funding or OTC or SAFTs occurred. Project was boostrapped |
Previous Exploits Affecting The Native Token
If any, list prior exploits or incidents that directly affected the token, token supply, tokenholder balances, token contract, minting controls, burn mechanics, or custody of token supply. This question is not asking about general protocol, application, or smart contract exploits unless the incident directly affected the native token itself. If no prior incidents, state this explicitly (e.g., "No exploits affecting tokenholders or protocol funds as of YYYY-MM-DD").
- (a) Date & component affected — Date (YYYY-MM or YYYY-MM-DD), chain(s)/component affected.
- (b) Exploit vector summary — Plain-language summary of the exploit vector (what the hack was).
- (c) Quantified impact — Quantified impact (assets/tokens affected or a clear "no loss of funds" statement).
- (d) Remediation/response taken — Remediation/response taken (patches, upgrades, governance actions, compensation).
- (e) Current status — Current status (resolved, in litigation, under investigation, refunded, etc.).
- (f) References — Link(s) to post-mortem/advisory/PR.
(a) Date & component affected
Avici has not experienced any known exploits, hacks, or security incidents affecting the protocol or AVICI token as of the filing date. ie. 21st August 2026
(b) Exploit vector summary
n/a
(c) Quantified impact
n/a
(d) Remediation/response taken
n/a
(e) Current status
n/a
(f) References
n/a
Material Risk Factors (Regulation, Technology, Token Economics)
Describe material risk factors across the three categories below. Each category includes prompts to address at a minimum.
-
(a) Regulatory, Legal & Tax Risks — Describe how evolving laws and regulations could affect the project by answering, at a minimum, questions like:
-
Impact of Regulatory Change on TGE and Listings: (If applicable) How could evolving or conflicting laws and regulations affect your ability to complete the TGE, deliver tokens to purchasers, and list or maintain the token on trading venues in key jurisdictions?
-
Entity-Level Regulatory Impact: (If applicable) How could regulatory or legal changes impact your core entities (Foundation, DevCo, DAO, affiliated service providers), including enforcement actions, licensing requirements, or forced changes to structure or operations?
-
Tokenholder Tax Treatment: (If applicable) What uncertainties exist around how tokenholders may be taxed, and make clear that tokenholders are responsible for understanding their own tax obligations?
-
Jurisdictional & User Access Restrictions: (If applicable) If the project restricts access for certain jurisdictions or user types (e.g., U.S. persons, sanctioned countries, retail vs. professional), what are those restrictions and what risks do they create for users and for the project?
-
(b) Protocol, Technology & Security Risks — Describe risks to network and contract reliability, correctness, and safety by answering, at a minimum, questions like:
-
Bugs and Design Flaws: (If applicable) What bugs, design flaws, or implementation errors could exist in your core protocol code, smart contracts, and any bridges, rollups, or oracles that you depend on, and how could these lead to loss of funds or disruption of the protocol?
-
Security Measures & Their Limitations: (If applicable) What security measures have you taken (audits, formal verification, bug bounties), and what types of failures might these measures still fail to detect or prevent?
-
(c) Token Economics, Unlocks & Incentive Risks — Describe how the token's economic design and supply schedule could affect holders by answering, at a minimum, questions like:
-
Critical Economic Assumptions: (If applicable) Which economic assumptions (e.g., staking yields, fee revenue, liquidity incentives, MEV capture, demand for blockspace) are critical for protocol security, utility, and governance, and what happens if those assumptions fail?
-
Governance Control over Monetary Policy & Rewards: (If applicable) To what extent can governance change monetary policy, fee parameters, or reward allocations (e.g., inflation rate, treasury flows, incentive programs), and how could such changes adversely affect tokenholders?
(a) Regulatory, Legal & Tax Risks
AVICI’s TGE has been completed through MetaDAO’s permissionless smart contracts, with no team allocation at launch. Regulatory or legal changes concerning digital assets, securities, commodities, sanctions, AML/KYC, consumer protection or taxation could restrict transfers or trading, cause trading venues or service providers to discontinue support, reduce liquidity, or impose additional registration, licensing, disclosure or compliance requirements on future issuance or distributions.
Jester DAO LLC, Avici Inc. and affiliated service providers may be affected by new licensing, reporting, sanctions, tax or operational requirements, enforcement actions, or conflicting laws. These developments could increase costs, restrict jurisdictions or user groups, require structural or operational changes, or suspend particular services. No Primary Foundation exists.
Tax treatment of acquiring, holding, staking, transferring, trading or disposing of AVICI varies by jurisdiction and may change. Each tokenholder is responsible for determining and complying with their own tax obligations and should obtain independent advice.
The AVICI token protocol is permissionless and does not administer KYC or AML checks for holding, transferring or trading AVICI. Users remain responsible for compliance with applicable laws and sanctions. Separately, Avici products, wallets, trading venues and other third-party providers may restrict access based on residence, sanctions status or eligibility. Such restrictions may change and could reduce access, liquidity or token utility.
(b) Protocol, Technology & Security Risks
AVICI uses Solana’s standard SPL Token program. Treasury actions, future token issuance and key protocol decisions depend on MetaDAO’s decision-market governance programs. The system also depends on Solana, conditional markets and TWAP calculations, DEX liquidity pools, wallets and other third-party infrastructure. Bugs, design flaws, implementation errors, outages, compromised dependencies, market manipulation or insufficient liquidity could cause incorrect governance outcomes, failed transactions, loss of access or funds, or protocol disruption.
Avici Inc. and the development team have no independent signer, pause, upgrade, mint, freeze, veto or governance-executor rights, reducing unilateral-action and team-key risks. Relevant MetaDAO programs are public and have undergone third-party security audits. MetaDAO has also stated that its team can override decision markets in extreme scenarios while the system remains in beta. Public code and audits do not guarantee correctness and may not identify economic-design flaws, integration failures, new attack methods or failures in Solana or third-party services. No audit or decentralized system eliminates all technical or security risk.
(c) Token Economics, Unlocks & Incentive Risks
AVICI’s economic model depends on continued product adoption, sufficient DEX and decision-market liquidity, and market prices that provide reliable governance signals. Weak adoption, thin liquidity, concentrated participation, manipulation or inaccurate pricing could reduce utility, impair governance outcomes or adversely affect AVICI’s market value.
AVICI had no team allocation at launch and has no automatic inflation or scheduled emissions. Its supply is not permanently capped: a successful decision-market proposal may authorize new issuance, treasury expenditure, rewards, incentives or other economic-policy changes. Avici Inc. and the development team cannot make those changes unilaterally. Governance-approved issuance or treasury actions could dilute holders, redirect resources, change incentives or increase volatility.
AVICI-001 authorizes up to 8,240,000 performance-based team tokens. Tokens are earned only if specified 60-day TWAP price milestones are achieved; unearned tokens are not minted, and earned tokens cannot be accessed before January 3, 2029. If earned and issued, those tokens will increase supply and dilute existing holders. Any future distribution of revenue or treasury assets likewise requires a successful decision-market proposal.
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. Avici is solely responsible for the content, accuracy, and legality of its disclosures.