KasCoven Vaults FAQ

A KasCoven Vault is a Kaspa UTXO protected by covenant logic.

Instead of relying only on a wallet signature, the vault contains rules enforced by Kaspa consensus. These rules determine when the locked KAS may be spent, where it may be sent, and which authorization is required.

The vault is non-custodial. KasCoven and any server involved cannot take ownership of the funds or bypass the covenant conditions.

No. A vault address is not a wallet. A normal wallet address is derived from a private key. A vault address is derived from the covenant script and represents its spending rules—not a new private key.

Creating a vault does not generate another seed phrase, hidden wallet, private key, account or derivation path. The address can exist without its own private key because spending authority is defined by the covenant script.

The creation transaction provides the relationship. It spends KAS from your connected wallet into the covenant address and records the owner, beneficiary, vault address, covenant script, timing and permitted spending conditions.

Where required, the covenant also demands a signature from the existing owner or beneficiary wallet when it is opened.

No. Wallet signing happens inside Kaspire or Kasware. KasCoven receives only the resulting signed transaction.

KasCoven never needs your seed phrase, private key, wallet password or recovery phrase. Never enter these secrets into the website or recovery tool.

Expiration makes the vault spendable. It does not automatically create or broadcast a transaction. Kaspa validates submitted transactions; it does not autonomously move funds at a particular DAA score.

1. KasCoven locates the current vault UTXO.
2. It constructs the permitted opening transaction.
3. The connected wallet authorizes it when required.
4. The transaction is broadcast.
5. Kaspa verifies the covenant.
6. The KAS reaches the permitted address.

Some party must monitor the vault and broadcast a valid transaction. Fully automatic execution would require an external service, a continuously running wallet or a previously signed transaction.

• A service without the private key cannot provide a required signature.
• A service holding the key would undermine self-custody.
• A long-lived pre-signed transaction can become unsuitable as fees and network conditions change.
• A monitoring service introduces another infrastructure dependency.

KasCoven therefore keeps final authorization with the user’s wallet.

The network fee can generally be deducted from the KAS held by the vault. The relevant owner or beneficiary wallet authorizes the current fee, so the receiving amount is the vault balance minus the accepted network fee.

The recovery file is a map to the vault—not a wallet backup. It contains public technical context such as vault type, name, address, owner or beneficiary, creation outpoint, redeem script, unlock conditions, DAA values and protocol version.

It contains no seed phrase, private key, wallet credentials or control over the funds. Someone seeing it may learn vault details, but still cannot bypass the covenant or required wallet signatures.

Each address is derived from its covenant configuration. Changing the beneficiary, owner key, unlock condition, inactivity period or protocol version can produce a different script and therefore a different address.

This creates a new covenant—not a new wallet.

The vault and its KAS remain on Kaspa. Its context can be reconstructed when the creation transaction and current UTXO can be found.

KasCoven uses browser records, the server-side vault index, public address history and current Kaspa UTXOs. Recovery without an export may be slower and more dependent on historical indexing, so the file remains a useful independent path.

No. Browser storage is only a convenience cache. The actual KAS is held by a covenant UTXO on Kaspa.

Only local convenience records are removed. The on-chain vault, funds and conditions remain unchanged. Reconnect the same wallet and scan the index and available Kaspa history to rediscover active vaults.

A recovery export is still recommended because it reduces reliance on one browser, deployment or history provider.

Connect the same owner wallet or relevant beneficiary wallet. KasCoven can search for vaults associated with that address, or you can import the recovery file directly.

A different account or derivation address is a different Kaspa address and cannot be assumed to represent the original participant.

The website does not hold the KAS and is not part of consensus. Clone the public repository, run it locally or deploy a mirror, open the recovery tool, connect Kaspire or Kasware, then import or scan and construct the permitted transaction.

Recovery still requires access to a Kaspa node or API providing the necessary UTXO and transaction data.

Yes, when it provides the required endpoints and historical data. Users do not necessarily need their own node.

Public services can have rate limits, outages, incomplete history, changing APIs or indexing delays. A private node and indexer offer greater independence but are not mandatory.

Pruning does not delete an unspent vault UTXO from Kaspa consensus. Active UTXOs must remain available for validation.

What may disappear is convenient access to old creation history and metadata. Persistent indexes, history APIs, browser records and recovery files provide alternative discovery paths. Pruning affects discoverability—not ownership or covenant validity.

No. The address and recovery metadata are public, but a spend must satisfy every covenant rule.

• the required DAA score or sequence lock;
• the pinned destination and transaction structure;
• the owner or beneficiary signature where required;
• and the permitted covenant branch.

Kaspa nodes execute the script and reject invalid transactions.

It holds KAS until a specified Kaspa DAA score. Before that score an opening transaction is invalid; afterwards the owner can authorize and broadcast the permitted transaction.

Displayed days, hours, minutes and seconds are estimates. The consensus DAA score is authoritative.

It has an owner and beneficiary. The owner may send a pulse that recreates the covenant and starts a new inactivity window. If no pulse arrives and the sequence lock expires, the beneficiary can claim through the beneficiary branch.

The beneficiary address is committed to the covenant and cannot simply be replaced.

Kaspa covenant timing is enforced using consensus values such as DAA scores and sequence locks. Wall-clock dates are estimates for human convenience. The browser clock is never authoritative.

No. Once accepted, the covenant commits its beneficiary, owner key, unlock condition, spending branch and destination constraints on Kaspa. The website cannot rewrite them.

Changing rules requires a new transaction that the existing covenant already permits.

Protect the wallet recovery phrase according to the wallet’s instructions, and export each vault’s KasCoven recovery file separately.

Neither backup replaces the other.

The vault is not stored inside the website, browser, recovery file or a hidden wallet. The KAS is stored in a covenant-controlled UTXO on Kaspa.

The website discovers the UTXO and constructs valid transactions. The wallet supplies authorization where required. Kaspa consensus makes the final decision.