A stronger
foundation.

Abstract

Creating a token is straightforward. Establishing credible controls over the funds and authorities behind it is a separate problem.

Veyra proposes a launch workflow that pairs token creation with a project treasury, explicit spending policies, and a public team vesting schedule. These controls would be enforced by on-chain programs rather than by a website or a promise from a founder.

A further research track explores post-quantum authorization for narrowly defined vault actions. The objective is to reduce reliance on a single classical signing key for project custody, while preserving clear recovery and operating procedures.

Design principles

Enforcement over assurances

A treasury rule should be enforceable by the program controlling the funds.

Visible authority

Users should be able to inspect who can spend, change a policy, upgrade a program, or release an allocation.

Explicit security scope

A protection claim must identify the assets, actions, assumptions, and failure modes it covers.

Usable key operations

Key rotation, recovery, and signer coordination are part of the security design.

System architecture

The proposed architecture separates presentation, token creation, custody policy, and authorization. A launch provider would create the token; Veyra’s programs would govern only the assets and authorities explicitly assigned to them.

Project treasuries would use program-derived custody addresses. Each treasury would reference a policy account containing its spending limits, allowed recipients, delay settings, signer requirements, and policy revision. A separate vesting account would define each team allocation.

The token launch adapter remains undecided. Compatibility with a provider’s fees, launch mechanics, and migration behavior must be verified before integration. Merely launching through Veyra would not place all token supply or market liquidity under Veyra’s custody.

Launch lifecycle

1. Configure

   Define token details, team allocations, treasury recipients, withdrawal limits, and signer requirements.

2. Review

   Show the exact proposed transactions, custody addresses, permissions, fees, and selected network.

3. Authorize

   Request explicit wallet approval. Simulate transactions where supported and reject failed preconditions.

4. Establish controls

   Create the required policy and vesting accounts and transfer designated assets to their custody.

5. Verify

   Read back confirmed on-chain state. Display transaction receipts and identify any incomplete steps.

Whether these steps can be atomic depends on the chosen launch provider and transaction constraints. If multiple transactions are required, the interface must preserve progress and avoid presenting a partially configured project as protected.

Treasury policy

The intended treasury model constrains withdrawals before funds leave custody. Policies would be asset-specific and evaluated against chain time and persistent program state.

A spending cap alone does not prevent theft: an authorized malicious signer could repeatedly withdraw up to the limit. Delays and allowlists reduce specific risks but do not establish whether a project is honest or viable.

Team vesting

Team tokens would be held in a vesting program with an allocation, beneficiary, start time, cliff, and end time. A linear schedule could calculate vested units as:

Here A is the allocation, s the start, and e the end. Claimable units equal vested units minus previous claims. The implementation must use integer arithmetic, define rounding, require e > s, and disclose whether the schedule is revocable.

Post-quantum authorization

Post-quantum signatures are designed to withstand attacks from both classical computers and sufficiently capable quantum computers. NIST has standardized ML-DSA and SLH-DSA digital signatures. Their existence does not establish that either is suitable for this product’s on-chain execution budget.^[1]

An existing Solana research implementation uses Winternitz one-time signatures for a lamports vault. It is a relevant reference for feasibility, not a security endorsement or proof that Veyra has implemented equivalent protection.^[2]

Candidate authorization flow

A proposed hybrid vault would require conventional signer approval and a post-quantum signature over the same canonical action. The signed payload would bind the network, program identity, treasury address, recipient, asset, amount, policy revision, expiry, nonce, and next key commitment. This is intended to prevent a valid signature being reused for a different action or deployment.

For a one-time signature construction, accepting an action must consume the current commitment and install a fresh commitment atomically. Reusing a one-time key can undermine its security. Concurrent signing, interrupted transactions, backups, and rollback behavior therefore need explicit design and testing.

Recovery without a bypass

A classical-key-only recovery path could defeat the intended post-quantum property. Recovery must be evaluated under the same threat model as ordinary withdrawals, including lost keys, compromised signers, unavailable relayers, and governance changes.

Security boundaries

The treasury layer would protect only assets it actually controls. It would not make Solana consensus, standard wallets, token trading, external protocols, or an entire token quantum-resistant.

Security review must cover arithmetic, replay protection, account substitution, cross-program calls, token-program compatibility, denial of service, emergency controls, and every upgrade or recovery authority. Public monitoring should expose policy changes and pending withdrawals without implying a guarantee of safety.

Economics

The proposed business model is service-based: disclosed launch fees and optional treasury tooling. Fee levels, recipients, and collection mechanisms remain undecided.

No platform token is required by the current architecture. This paper does not establish a token supply, staking scheme, revenue distribution, buyback policy, or investment return. Project token economics would be specified separately by each creator.

Implementation roadmap

Progress should be measured against working implementations and published evidence. No delivery dates or audit commitments are asserted in this version.

References

1. NIST. Post-Quantum Cryptography.

   Standardization context for ML-DSA and SLH-DSA.

2. Blueshift. Solana Winternitz Vault.

   Open-source reference for one-time signature authorization of a lamports vault.