Skip to main content

Vultisig

Vultisig — a reference card for a crypto project: what the product does and how verifiable the project’s key claims are; also — alignment with the Decentralized AI thesis (DecAI Fit).

Vultisig — a seedless MPC/TSS wallet/vault for multi‑chain self‑custody, token (symbol: VULT) on Ethereum.

Disclaimer

Important: this page is a reference overview of the project. Within DecAIHub, we separately record a verification based on open sources within the AI thesis (what is real AI/onchain/why a token, and which sources this is based on).
This is not financial advice and not a recommendation to buy/sell/hold any asset. We do not assess price, returns, or entry/exit timing.
Conclusions are based on publicly available materials found as of the verification date. The absence of confirmation does not imply the absence of the technology.

TL;DR (for readers who are not into AI)

  • What it is: an open‑source wallet/vault “at the multisig level”, but without a seed phrase — the keys are never assembled, signing is done via threshold signatures (TSS/MPC).
  • Who it’s for: ordinary users, DAOs/multisig operators, as well as developers who want to automate operations (there is an SDK/CLI).
  • Why onchain/token: onchain is the chains where the user’s assets reside; the VULT token is used mainly for discounts/payments/staking in the ecosystem (marketplace/plugins), but the wallet as such does not require the token by virtue of self‑custody.

How it works (very briefly)

  1. The user does: creates a Vault (Fast Vault — 2‑of‑2 with a co‑sign server; Secure Vault — N‑of‑M with several of their own devices).
  2. The system does: distributes “shares” across devices; when signing a transaction, the devices jointly create a signature (TSS/MPC) without assembling a single private key.
  3. The user gets: a multi‑chain wallet that can send/swap assets across different networks, with a stronger security model than single‑sig.
  4. Where the blockchain is: assets remain on their native networks (Bitcoin/Ethereum/Solana/etc.), while Vultisig only generates signatures for transactions.
  5. Token role (if any): the VULT token provides discounts/access/payment options and staking mechanics in the ecosystem (especially the marketplace); the basic wallet can be used without VULT.

Quick links: AI thesis fit

Project passport

Field Value
Project name Vultisig
Also known as (aliases) Vultisig Wallet; Vultisig Vault; $VULT
Logo (logo) ../assets/164_vultisig_logo.svg
Token symbol (ticker) VULT
Category Wallet | Infra | MPC/TSS
Primary chain (chain) Ethereum
Type EVM
Network status mainnet
Consensus (consensus) PoS (Ethereum)
Launch date (launch_date) 2025‑10 (the public launch of the VULT token is described in the documentation)
Project status (status) active
Token (standard) ERC-20
Token contract 0xb788144DF611029C60b859DF47e79B7726C4DEBa
Token model (token_type) utility (payments + staking + governance (planned))
Max supply 100,000,000 VULT (per docs/etherscan), but the contract has mint() (additional issuance by the owner is possible)
Issuance fixed claimed; burn for certain fee mechanics is claimed in the marketplace
Tokenomics (tokenomics, brief) swap fee discounts by tier; VULT is used for fees/registration/staking in the Marketplace
Governance company → a transition to governance on staked VULT is planned
Admins/keys token contract: onlyOwner functions (mint, setLaunchListContract, setNameAndTicker, etc.); the product’s keys are not described
Audit yes (audit of the core TSS library; audit of DKLS23)
Bug bounty yes (responsible disclosure; up to $50k)
Team (team) claimed that the project is “built by the founders of THORChain”
Funding (investors/funding) $2.4M initial funding LP investors (per the token launch docs)
AI component (ai_component) none (AI automation infrastructure/SDK)
Use‑case (use_case) seedless MPC/TSS multichain vault
DecAI Fit — AI thesis fit 0/6 — no AI reality and no AI intent (ai_score=0)
DecAI Fit component summary 0 / 1 / 2 / 3
Last verified 2026-02-11

General project overview

Vultisig is an open‑source “vault/wallet” (Vault) that tries to provide multisig security without the UX complexity of multisig and without seed phrases. It is based on threshold signature schemes (TSS) and MPC: the signature is assembled in a distributed way from several “shares”, while a single private key is never created.

Note on networks (passport normalization): the passport lists Ethereum as the primary chain (per the VULT token). The product itself is a multi‑chain wallet/SDK, so the “multi‑chain” context remains in the text.

The project emphasizes multi‑chain: a single vault setup can serve different network families (UTXO/EVM/BFT/EdDSA). There are Fast Vault (2‑of‑2 with the Vultisig co‑sign server) and Secure Vault (several of the user’s own devices) modes.

Features/modules

  • Seedless vault: vault shares instead of a seed phrase.
  • TSS/MPC signing: the signature is created by a threshold protocol, without assembling the key.
  • Multi‑chain: support for dozens of chains (Bitcoin/Ethereum/Solana/Cosmos, etc.).
  • Fast Vault / Secure Vault: different models of availability and autonomy.
  • SDK/CLI: tools for automation and “agentic” scenarios (including for AI agents as external programs).
  • Marketplace/plugins (partially/in rollout): a claimed ecosystem of extensions featuring “plugins and AI agents”.

Typical scenarios

  • Scenario 1 (user): creates a Secure Vault on 2–3 devices → gets a signing model more resistant to phishing/leaks compared to single‑sig.
  • Scenario 2 (team/DAO): uses a vault as an “operational treasury” → splits access among participants without a classic multisig contract.
  • Scenario 3 (developer/automation): creates a vault via the SDK/CLI and signs/sends transactions programmatically → builds bots/scripts/agents on top of self‑custody.

Getting started (wallet/network)

  • What you need: the Vultisig app (iOS/Android/desktop) or the extension; for Secure Vault — at least 2 devices.
  • Network/chain: you choose the network/assets you manage (multi‑chain).
  • Fees: standard gas of the chosen network; for swap functions in the app, a fee (50 bps) and discounts for holding VULT are claimed.

Architecture/tech (non‑AI)

  • Components: client applications + TSS protocols (including DKLS23) + infrastructure for Fast Vault (VultiServer) and session coordination (relay).
  • Participant roles: owner(s) of shares (the user’s devices), the co‑sign server (in Fast Vault), developers/plugins/SDK integrators.
  • Where logic runs: signing — offchain (MPC/TSS); execution — onchain on the chosen network.
  • Dependencies: the chosen blockchains and their RPCs; for swaps — external integrations/routers (THORChain/1inch/LiFi are mentioned in the docs as quote sources).

Token/economics (expanded, no forecasts)

  • Token utility: discounts on in‑app swap fees by tier (based on the amount of VULT in the Vault), the option to pay VULT for marketplace services/plugin registration, and a claimed staking/lock to boost the share in fee distribution.
  • Protocol necessity drivers: basic storage/signing in Vultisig does not require VULT, but the marketplace layer and discounts are tied to VULT (including the burn of registration fees).
  • Who pays fees: users pay the gas of the chosen network; additionally, they may pay fees in the app (swap/marketplace) — as claimed.
  • Where fees go: part is claimed as ecosystem revenue and VULT buyback; some fees in the marketplace are claimed to be burned.
  • Issuance/burn: a supply of 100,000,000 is claimed; in the marketplace, a burn of registration fees is claimed.
  • Security/incentive mechanisms: staking/lock (to increase the fee share) is claimed for developers; governance via staked VULT is claimed as a plan.
  • Distribution and token issuance schedule: the docs have a tokenomics/allocations/vesting section (as images); in text — there is a breakdown by category (investors/treasury/team/community/merge).
  • Treasury: the treasury is mentioned in the tokenomics; onchain addresses/the treasury multisig are not given on these pages.

Governance

  • Who makes decisions: currently — the team; a gradual transition to community governance on staked VULT is claimed.
  • How protocol parameters change: via releases of the apps/infrastructure; the governance mechanics are described as future.
  • Where decisions are discussed/made: GitHub/Discord/X/Medium.
  • Keys/multisig: no public links to the composition/threshold of the infrastructure management keys were found in the reviewed pages.

Security and incidents

  • Audits: an audit of the core TSS library (Kudelski Security, 2024) and an audit of DKLS23 (Trail of Bits, 2024; via Silence Laboratories) are mentioned.
  • Bug bounty: yes (reward up to $50,000 by severity; responsible disclosure).
  • Incidents: not listed in the reviewed sources.
  • Threat model: the key risk is the compromise of several devices/shares, risks of the co‑sign server in Fast Vault (the 2‑of‑2 model with a server), risks of supply/owner control of the token (mint/list settings at launch).

Project status and timeline

  • Current status: an active product (multi‑platform wallet).
  • Key releases/milestones: the token launch and communication principles are described in the docs; the security page is updated regularly.
  • Roadmap: no general roadmap section is listed; the Marketplace part is explicitly marked as “not yet fully rolled out”.

Ecosystem/integrations

  • Integrations: an extension for dApp connections; SDK/CLI; swap integrations (THORChain/1inch/LiFi in the agent docs).
  • Partners: third‑party projects/networks are mentioned in the docs and on the website; confirmed investors/funds are not listed in the reviewed sources (apart from the LP investors amount).
  • Where it’s actually used: “trusted by thousands of users” is claimed on the website; there are no targeted case studies with metrics.

AI component of the project

  • What is real AI here? Essentially, AI as a technology (models/inference/training) is not used; wording like “AI Agent era” and the “For AI Agents” section describe the SDK/CLI for automating the wallet with external programs/agents.
  • What is truly onchain? Assets and transactions — on the underlying blockchains (multichain). There is a VULT token on Ethereum (ERC‑20).
  • Why is a token needed? The ecosystem claims discounts, payments and staking/lock in the Marketplace and future governance; at the same time, the wallet’s basic self‑custody functionality does not depend on VULT.
  • Red flags (based on the information found): AI‑washing — medium (the term “AI agents” can be misleading); onchain‑washing — low (the wallet obviously works on top of blockchains); token‑washing — medium (a lot of utility is claimed, some of it “coming later”, and the contract has mint() for the owner).

DecAI Fit component summary

  • DecAI Fit: 0/6 — no AI reality and no AI intent (ai_score=0)
Component Level Score
AI reality low 0
Onchain necessity low 1
Token necessity medium 2
Evidence Tier‑1 present 3
Details

AI reality

AI_0 — AI intent (Tier‑1 roadmap) (1/0)

  • AI_0 (decision): 0
  • Claim (one line): the project does not claim the introduction of AI models into the product; it is about “AI agents” as users of the SDK/CLI.
  • Evidence: Tier‑1 — https://docs.vultisig.com/agent
  • Why sufficient / why not (one line): the source describes an integration for AI agents, but this is not a claim about an AI module of its own.
  • Conflict note (if any): —

AI_1 — what the AI does (1/0)

  • AI_1 (decision): 0
  • Claim (one line): there is no AI module (the wallet implements MPC/TSS, and the “agents” are external programs).
  • Evidence: Tier‑1 — https://docs.vultisig.com/
  • Why sufficient / why not (one line): the documentation describes TSS/MPC and vault flows, not AI.
  • Conflict note (if any): —

AI_2 — demos/examples (1/0)

  • AI_2 (decision): 0
  • Claim (one line): there is no demo of an AI model (there are examples of SDK calls for agent automation).
  • Evidence: Tier‑1 — https://docs.vultisig.com/agent
  • Why sufficient / why not (one line): this is an example of an API integration, not a demonstration of AI inference/quality.
  • Conflict note (if any): —

AI_3 — metrics/quality (1/0)

  • AI_3 (decision): 0
  • Metrics: —
  • Context (version/date/how measured): —
  • Evidence: Tier‑1 — https://docs.vultisig.com/agent
  • Why sufficient / why not (one line): there are no AI metrics, since there is no AI component.
  • Conflict note (if any): —

AI_4 — tech description/architecture/versions (1/0)

  • AI_4 (decision): 0
  • Claim (one line): the MPC/TSS architecture and agent tools are described, but not AI models.
  • Evidence: Tier‑1 — https://docs.vultisig.com/ ; https://docs.vultisig.com/agent
  • Why sufficient / why not (one line): the technical description relates to cryptography/the wallet, not to AI.
  • Conflict note (if any): —

Onchain necessity

OC_1 — contracts/addresses/chain (1/0)

  • OC_1 (decision): 1
  • Chain: Ethereum
  • Addresses/identifiers: VULT token: 0xb788144DF611029C60b859DF47e79B7726C4DEBa
  • Evidence: Tier‑1 — https://etherscan.io/token/0xb788144DF611029C60b859DF47e79B7726C4DEBa
  • Why sufficient / why not (one line): the token’s onchain contract exists and is verified on the explorer.
  • Conflict note (if any): —

OC_2 — onchain beyond just a token (1/0)

  • OC_2 (decision): 0
  • What useful logic is onchain: the core of Vultisig is offchain MPC/TSS signing; the reviewed sources do not single out separate protocol onchain contracts (other than the token).
  • Evidence: Tier‑1 — https://docs.vultisig.com/
  • Why sufficient / why not (one line): onchain is used as the “place of transaction execution” of the chosen chains, but Vultisig’s own onchain logic is not shown by addresses.
  • Conflict note (if any): —

OC_3 — onchain is critical (1/0)

  • OC_3 (decision): 0
  • “Replace the blockchain” test: the product is designed to manage assets on blockchains; without a blockchain there are no “assets” or transactions, but this does not make Vultisig an onchain protocol — it is a client/infrastructure.
  • Evidence: Tier‑1 — https://docs.vultisig.com/
  • Why sufficient / why not (one line): onchain here is the transaction execution environment of the chosen networks; Vultisig’s own onchain logic (other than the token) is not confirmed by addresses.
  • Conflict note (if any): —

Token necessity

TK_0 — no token (1/0)

  • TK_0 (decision): 0
  • Claim (one line): the project has a token, VULT, on Ethereum (ERC‑20).
  • Evidence: Tier‑1 — https://docs.vultisig.com/vult-token/vult ; https://etherscan.io/token/0xb788144DF611029C60b859DF47e79B7726C4DEBa
  • Why sufficient / why not (one line): the token is described in the official documentation and visible in the explorer.
  • Conflict note (if any): —

TK_1..TK_4 (1/0)

TK_1 — payment for the service (1/0)

  • TK_1 (decision): 1
  • Claim (one line): in the Marketplace, users will be able to pay VULT instead of USDC and receive discounts; developers pay registration fees in VULT.
  • Evidence: Tier‑1 — https://docs.vultisig.com/vult-token/vult/marketplace-utility
  • Why sufficient / why not (one line): a specific payment/fee mechanism in the token is described, although some parameters are “still being determined”.
  • Conflict note (if any): there is an option to pay in USDC → the token is not strictly necessary.

TK_2 — incentives/collateral/penalties (1/0)

  • TK_2 (decision): 1
  • Claim (one line): staking/lock of VULT to increase the developer’s fee share and receive discounts; burning VULT as part of the anti‑spam registration mechanics.
  • Evidence: Tier‑1 — https://docs.vultisig.com/vult-token/vult/in-app-utility ; https://docs.vultisig.com/vult-token/vult/marketplace-utility
  • Why sufficient / why not (one line): discount tiers and lock conditions (with parameters) are spelled out, as well as the burn of registration fees.
  • Conflict note (if any): some mechanisms are “later”/“still being determined”.

TK_3 — governance (1/0)

  • TK_3 (decision): 1
  • Claim (one line): a transition to governance voting using staked VULT is claimed.
  • Evidence: Tier‑1 — https://docs.vultisig.com/vult-token/vult/governance-utility
  • Why sufficient / why not (one line): this is a Tier‑1 intent/design, but not a confirmed working governance module.
  • Conflict note (if any): “exact governance structure… decided in the near future”.

TK_4 — token is replaceable (1/0)

  • TK_4 (decision): 1
  • Claim (one line): some functions (Marketplace) explicitly allow payment in USDC instead of VULT, and the basic wallet works without the token — so the token is replaceable overall.
  • Evidence: Tier‑1 — https://docs.vultisig.com/vult-token/vult/marketplace-utility ; https://docs.vultisig.com/vult-token/vult
  • Why sufficient / why not (one line): a payment alternative (USDC) is described, which reduces the “necessity” of VULT.
  • Conflict note (if any): —

Evidence (table)

Tier Source What it proves
Tier‑1 https://docs.vultisig.com/ what Vultisig is: seedless MPC/TSS vault, Fast/Secure vault, multi‑chain
Tier‑1 https://www.vultisig.com/ high‑level description of the product and vault modes
Tier‑1 https://docs.vultisig.com/help-and-legal/security security model + links to audits + bug bounty
Tier‑1 https://docs.vultisig.com/agent SDK/CLI for agent automation (not AI inference)
Tier‑1 https://docs.vultisig.com/vult-token/vult the VULT token: network/contract/utility/tokenomics
Tier‑1 https://docs.vultisig.com/vult-token/vult/in-app-utility discounts on in‑app swap fees by VULT holding tier
Tier‑1 https://docs.vultisig.com/vult-token/vult/marketplace-utility VULT as fee/payment/stake/lock and burn mechanics in the Marketplace
Tier‑1 https://docs.vultisig.com/vult-token/vult/governance-utility the intent to use staked VULT for governance
Tier‑1 https://docs.vultisig.com/vult-token/launch token launch parameters and LP funding ($2.4M)
Tier‑1 https://etherscan.io/token/0xb788144DF611029C60b859DF47e79B7726C4DEBa onchain data of the token and the verified contract (including mint() for the owner)

No comments to display

Back to top