VRF depositor-as-keyholder custody
The Rédeas Vault
The Rédeas VaultSHEET VAULT·05
Drawn byThe Architect
DisciplineCustody · VRF
StatusDesign
ScaleNot to scale (N.T.S.)
◆Written to inform, not to sell. No hype, no false promises — just a clear, honest account of how Chronimy works, built to read well on any device.
Rédeas Vault · The Problem
Crypto
Fundraising
Is Broken.
Every year, billions are lost not because projects fail to build — but because the people who funded them had no structural control over the money they contributed.
$4.6BLost to rug pulls in 2024 alone
53%Of all crypto projects since 2021 are now dead
12 daysAverage time for a rug pull to unfold in 2024
92%Of successful rug pulls used anonymous founders
Architecture Note
Chronimy is four core modules + Module 5 auxiliary workstream shipping eleven products on a shared identity layer.
Each phase from Nebula onwards delivers visible product moments. The four core modules + Module 5 auxiliary workstream are the brand. The eleven products are the shipping calendar:
- Module 1 — Verify Yourself (Nebula): Get-to-Green · Trust Codes + Free Mini Card · Enhanced Profile · Full Profile request flow
- Module 2 — Transact Safely (Pulsar): Pay Me · Verified Marketplace · Chronimy Verify B2B (4a)
- Module 3 — Trust at Scale (Supernova): Mobile Native · Trust-Locked Asset Vault · DAO Governance Activation · Enterprise API + Browser Extensions + Wall of Shame (4b)
- Module 4 — Verify Others (Pulsar 4a + Supernova 4b): cross-cutting B2B verification layer for websites
- Module 5 — Anti-Phishing App Monitoring (workstream tracked separately): real-time phishing detection in Chronimy app, cross-checked against Verify B2B registry and Wall of Shame
Every revenue-line product is locked. Every viral / governance / distribution product enables a revenue line elsewhere. No product is dropped — eleven shipping moments across three years.
From The Architect
On Deinstitutionalisation
"Deinstitutionalisation means moving people out of institutions that have stopped looking after them, and into communities that actually do. That's the dictionary definition. It's what closed the old asylums in the 1970s and gave people their lives back. Chronimy is the same idea, for the world we're living in now."
Rédeas Vault is that principle applied to the specific failure above. Crypto fundraising as it exists today is an institution that has stopped serving the people it was built to serve. Every failure mode documented in this paper shares one structural flaw — the people who provide the capital have no control over it after they contribute. Rédeas moves the keys back to the contributors. The vault is community-controlled by design. The founder cannot pull the rug, because the founder has no access to the rug in the first place. That is what deinstitutionalisation looks like in code.
— The Architect, Chronimy Holdings AG · April 2026
The Scale
The Numbers Behind the Losses
These are not edge cases or outliers. The collapse of contributor capital in crypto fundraising is systemic, predictable, and structurally enabled by the way every existing fundraising mechanism is designed.
Rug Pulls — Hard and Soft
Founders drain liquidity and disappear. Or they stay, reduce involvement, and slowly sell their allocation while the community watches the price collapse. Both are enabled by the same structural flaw: founder control over pooled capital.
$4.6B · 2024
Insider Token Concentration
The LIBRA token saw 82% of supply concentrated in insider wallets. Within hours, $87M was withdrawn, triggering an 85% price collapse. 251,000 contributors lost money. The mechanism was legal. The structure made it possible.
$251M · Single event
AI Whitepapers and Fake Audits
27% of rug pull scams in 2024 featured AI-generated whitepapers and fabricated audit reports. The barrier to creating a convincing fundraising document is now effectively zero. Due diligence by contributors is increasingly impossible.
27% of cases · 2024
Broken Liquidity Promises
Liquidity locking promises were broken in 45% of rug pull cases in the last 12 months. Projects promise locked liquidity, contributors invest on that basis, and the promise is discarded. Smart contracts do not enforce promises — only code enforces code.
45% promises broken
Why Projects Fail
The Eight Failure Modes — All Share One Root Cause
Research across the full crypto failure landscape identifies eight recurring failure patterns. They appear distinct. They share a single structural origin.
01
Intentional fraud — exit scams and rug pulls
Founders raise funds with no intention of building. The treasury is fully accessible from day one. Exit is a function of timing and audacity, not opportunity.
65% of all DeFi scams in 2024 · Chainalysis
02
Soft abandonment — founders reduce involvement
The project was genuine. The founders lost motivation, found better opportunities, or ran out of capital. Contributors have no mechanism to recover remaining funds or redirect the project.
35% increase in soft rug pulls · 2024–2025
03
Poor tokenomics — insider concentration and dump
Pre-allocated insider wallets hold disproportionate supply. Vesting schedules are too short or non-existent. Insiders sell into community buying pressure. Price collapses. Community disperses.
Most common pre-rug signal · on-chain data
04
No product-market fit — hype without utility
The project raised on narrative rather than demonstrated demand. When hype fades and utility fails to materialise, contributors have no recourse and no mechanism to recover uncommitted funds.
53% of all projects since 2021 now dead · CoinGecko
05
Fraudulent documentation — fake audits and AI whitepapers
With AI tools, creating convincing project documentation requires minutes. Fake audit certificates, AI-generated technical whitepapers, and fabricated team credentials are now routine.
27% of 2024 rug pulls · fabricated documentation
06
Financial mismanagement — poor spend discipline
Founders with legitimate intentions spend raised capital inefficiently. Marketing budgets are wasted. Development costs overrun. By the time the community notices, the treasury is depleted and the project cannot deliver.
07
Regulatory collapse — unregistered securities exposure
Projects launch without adequate legal analysis. Regulatory enforcement forces shutdown, exchange delisting, or founder liability. Contributors lose access to their funds during legal proceedings.
62% of 2024 SEC crypto cases — unregistered securities
08
Collusion — pre-arranged insider coordination
Founders and early wallets coordinate pre-launch positioning. The raise is designed to benefit a pre-selected group at the expense of the broader contributor pool. Community members are the exit liquidity, not the beneficiaries.
The Root Cause
Every Failure Mode Has
One Common Cause.
In every case above — fraud, abandonment, mismanagement, collusion — the enabling condition is identical. The people who provided the capital had no structural control over it after they contributed. The founders held the keys. The contributors held hope.
The structural failure
"The people who finance innovation have no structural control over the funds they provide. Rédeas Vault is built to change that — not through policy, not through promises, but through code."
Click Next Below to continue — The Protocol
Chronimy makes every reasonable effort to ensure the accuracy of the information in these materials. Given their volume and the pre-launch, evolving nature of the project, we cannot guarantee that every detail is complete, current, or error-free. Nothing here is a warranty of accuracy; figures, projections, and structures are subject to change, verification, and professional sign-off. This is not financial, legal, or tax advice.
‹ Back to site
Legal Disclaimer
This document is provided for informational purposes only. It does not constitute financial, legal, investment, or tax advice. It is not an offer to sell or solicitation to buy any security or financial instrument.
CNMY is a utility token. It is designed to function as a utility token under the FINMA and MiCA frameworks in which Chronimy Holdings AG operates. Formal legal opinion (W9 — qualified external legal counsel) is a hard pre-launch gate. It has not been registered under the US Securities Act 1933, FSMA 2000, MiCA, or any other securities regime.
Not available to US persons (Regulation S, Rule 902(k)), UK residents, Canadian residents, or Chinese residents. Geographic exclusion is enforced architecturally — at IP, KYC document, and platform layer — and is permanent constitutional policy.
Forward-looking statements, projections, and modelled outcomes are illustrative only, based on internal assumptions, and may differ materially from actual results.
Per-Phase Rédeas Vault — Canonical
Every phase has its own Rédeas Vault and its own Schedule B, agreed and published before the phase opens. Phase contributors hold the keys — 14 keyholders selected by Chainlink VRF across two groups (A public, B undisclosed) from the depositor set of that phase, split into two groups (A public, B undisclosed), with a 4-of-7 per group threshold (8 of 14) required for any release. No phase funds can cover prior phase shortfalls or future phase costs.
Each Schedule B carries two release categories. Category 1 — Operational Expenses: pre-approved phase costs (development milestones, legal, audits) released in tranches against proof-of-work, requiring keyholder threshold approval. Category 2 — Phase Reserve: remaining capital held until the phase module is delivered and verified, then released by keyholder vote on completion.
This is the per-phase application of the Rédeas core claim: contributors deposit, random selection designates contributor wallets as keyholders, threshold approval governs release, and clawback returns funds if conditions fail. The mechanism repeats with a fresh keyholder set for every phase.
The Protocol
What Rédeas Vault Is
Rédeas Vault is a smart contract protocol that puts the people who fund a project in cryptographic control of the funds they contribute — from the moment of deposit until the final release. Not policy. Not promises. Code.
Three sentences
Rédeas Vault is a deployable smart contract protocol where contributors deposit funds and become the cryptographic guardians of what they contributed — no founder accesses the capital without their approval.
Randomly selected contributors become keyholders using on-chain verifiable randomness — they cannot be predicted, pre-selected, or manipulated.
Every release requires a community visibility period and binding cryptographic approval from the keyholder set — and contributors can vote to return uncommitted funds proportionally at any time.
How It Works
The Deployment and Contribution Flow
1
Founder Deploys the Vault
The founder deploys a Rédeas Vault instance with three immutable parameters set at deployment: the designated project wallet address (where all released funds must go), the keyholder selection interval (every Nth depositor), and the keyholder threshold (X-of-Y approvals required). None of these can be changed after deployment.
Designated wallet is hardcoded — no post-deployment redirection possible
2
Pre-Raise Module Completion
Before the fundraising round opens, the founder lists discrete work modules — specific, defined tasks required to form and launch the project — available for purchase. Each module includes an AI-guided prompt and delivery specification. The raise cannot open until all modules are purchased and the completed work delivered and verified.
Fundraise is gated on real work being completed first
3
Contributors Deposit and Contribute Content
Contributors deposit USDC into the vault. Every contributor also submits one piece of original content — an article, analysis, or perspective about the project — verified before their contribution is fully registered. This is a protocol requirement, not optional.
Content submitted and verified before deposit is accepted into the vault
4
Keyholders Selected by On-Chain Randomness
Every Nth depositor triggers a Chainlink VRF request — a provably fair, tamper-proof, on-chain random number. The output assigns that depositor as a keyholder. They cannot predict their selection, and neither can the founder. Their own funds are in the vault they will guard.
Selection is provably random — no manipulation possible at any stage
5
Keyholder Onboarding and Test Signature
Selected keyholders receive immediate notification and are guided through a mandatory onboarding flow: what a keyholder is, how to sign a transaction, and a test signature on a zero-value transaction. Keyholder status is only confirmed after the test signature completes successfully. If a keyholder fails within 72 hours, the next depositor in sequence is selected.
6
Release Requests — With Receipts
When the founder needs funds, they submit a release request specifying the purpose label (domain registration, patent filing, legal fees, development payment etc.), the amount, and supporting documentation — invoices, receipts, quotes. This is visible to all contributors immediately.
7
Dual-Gate Approval
Two things must happen simultaneously for any release to execute. First: a 48-hour community visibility period where all contributors can see the request and documentation. Second: binding cryptographic approval from the required number of keyholders (4-of-7 from each group (8 of 14) for Genesis Vault releases). Both must be satisfied. Neither can override the other. If keyholders refuse, funds stay locked.
Neither gate alone is sufficient — both required every time
The Selection Mechanism
Why On-Chain Randomness Changes Everything
The depositor-as-keyholder selection mechanism is what separates Rédeas Vault from every existing fundraising protocol. The selection cannot be predicted, gamed, or reversed.
How Chainlink VRF Selection Works
Chainlink VRF (Verifiable Random Function) is a provably fair source of randomness built for smart contracts. When the Nth deposit triggers a VRF request, the Chainlink oracle generates a random number along with a cryptographic proof of how that number was produced. The proof is published on-chain. Anyone can verify the selection was random and unmanipulated. The selected depositor's wallet address is registered as an active keyholder. Their funds remain in the vault alongside every other contributor's. They have the most direct financial incentive to guard the vault honestly — their own money depends on it.
Cannot be predicted
No one — including the founder — can know in advance which depositor will be selected. The VRF output is unpredictable by design.
Cannot be manipulated
The cryptographic proof published on-chain verifies the randomness was not tampered with at any stage of the selection process.
Cannot be reversed
Once a keyholder is selected and the proof is published, the selection is permanent and immutable. No admin function can override it.
Self-aligned by design
Keyholders have their own capital in the vault. Their financial interest and their governance responsibility are identical. No external incentive is needed.
The Release Mechanism
How Funds Move — Every Time
Founder submits
Purpose label + amount + supporting receipts/invoices uploaded to the vault's public record
↓
48hr visibility
All contributors see the request immediately. Community observation period — cannot be shortened
↓
Keyholders review
Each keyholder independently reviews the documentation and decides to approve or refuse
↓
Threshold reached
8-of-14 keyholders (4-of-7 per group, two groups of 7) submit cryptographic approval on-chain — binding, immutable, public
↓
Release executes
Funds transfer only to the pre-set designated project wallet. No other destination is possible.
If keyholders refuse — or if fewer than 4-of-7 in either group approve within the voting window — the funds remain locked. The founder can submit a revised request with additional documentation. The community observes the entire process at every stage.
The Refund Mechanism
When Contributors Choose to Stop
Contributors are not locked into a project indefinitely. If the project fails to perform, deceives its contributors, or simply does not deliver — the contributor body can vote to return the uncommitted funds proportionally.
How the Proportional Refund Works
Any keyholder can propose a refund motion. The motion goes to a vote of all contributors — one contributor, one vote, regardless of contribution size. If a majority of contributors approve, the smart contract calculates and distributes the remaining vault balance proportionally to every contributor's original deposit address automatically.
Example: A project raises CHF 500,000. The founder spends CHF 50,000 on legitimate documented expenses (10%). Contributors vote to refund. The remaining CHF 450,000 minus the protocol fee is distributed. A contributor who deposited CHF 1,300 receives approximately CHF 1,170 back — 90% of their original contribution. The protocol fee is deducted from the pool before distribution, not from any individual contributor directly.
Click Next Below to continue — The Innovations
Chronimy makes every reasonable effort to ensure the accuracy of the information in these materials. Given their volume and the pre-launch, evolving nature of the project, we cannot guarantee that every detail is complete, current, or error-free. Nothing here is a warranty of accuracy; figures, projections, and structures are subject to change, verification, and professional sign-off. This is not financial, legal, or tax advice.
‹ Back to site
The Innovations
What Makes Rédeas Vault Structurally Different
Contributor-controlled fund approval in blockchain fundraising has existed since 2018 — Vitalik Buterin's DAICO model introduced contributor-voted release and refund mechanics. What Rédeas Vault adds is a set of specific mechanisms not found in any prior protocol, academic paper, or open-source implementation identified in prior art research. Each one addresses a structural weakness in every existing approach.
Four Distinct Innovations
Each One Independently Novel
Every existing fundraising protocol with contributor approval uses either pre-selected signers (multi-signature model) or token-weighted voting across all holders (DAICO model). Rédeas Vault randomly selects cryptographic signers from within the depositor pool itself, using on-chain verifiable randomness that cannot be predicted, manipulated, or reversed by any party — including the founder.
Why this matters
Pre-selected signers can be chosen for their willingness to cooperate. Token-weighted voting can be dominated by the largest holders. Random VRF selection from the depositor set means the keyholder composition is unknown to the founder at deployment — and to everyone else. The selected keyholders have their own money in the vault, giving them direct financial alignment with every governance decision they make.
No prior art found in any protocol, paper, or implementation
All existing contributor governance systems use token-weighted voting — larger holders have proportionally more influence, creating governance dominated by the wealthiest participants and vulnerable to 51% attacks. Rédeas Vault restricts all votes to the original depositor registry, with one vote per depositor regardless of contribution size. Only wallets appearing in the original deposit record can vote on any decision.
Why this matters
Token-weighted voting rewards capital concentration with governance concentration. One-depositor-one-vote means the contributor who deposited CHF 500 has identical governance weight to one who deposited CHF 50,000. The collective judgment of the contributor community — not its wealthiest members — governs every release and refund decision.
No prior art found — distinct from all token-weighted precedents
All existing protocols use a single approval mechanism — either a community vote or a multisig threshold. Rédeas Vault requires both simultaneously: a mandatory 48-hour community visibility period during which all contributors can observe the release request and supporting documentation, combined with binding cryptographic approval from the keyholder set. Neither can substitute for the other.
Why this matters
A single-gate system can be bypassed more easily than a dual-gate system. The community visibility period creates a public record of every release request and allows any contributor to raise concerns. The keyholder approval is the binding cryptographic mechanism. Social transparency and cryptographic enforcement working together is structurally distinct from any single-gate precedent in the space.
No prior art found — simultaneous dual-gate not found in any protocol
No existing fundraising protocol requires contributors to perform and deliver real work as a condition of participation. In Rédeas Vault, every contributor submits verified original content — an article, analysis, or perspective about the project — before their deposit is registered. Pre-raise, the founder's work modules must be purchased and completed by buyers before the vault opens. Contributors are active participants, not passive observers.
Why this matters
The content requirement produces a real, commercially valuable output for the project as a byproduct of every participation event. A project with 150 contributors generates 150 verified, indexed content pieces before public launch. The modules system ensures the project has real, documented formation work completed before a single contribution is accepted. Participation is earned through contribution of effort, not only capital.
No prior art found — no protocol found requiring labour as participation condition
The Module System
Work Before Raise — The Pre-Raise Module Architecture
Before a single deposit can enter the vault, the project must demonstrate that real formation work has been completed. The founder lists discrete, purchasable work modules and the fundraising round cannot open until all modules are purchased, completed, and deliverables verified.
📋
What a Module Is
A discrete, defined task representing one element of project formation. Each includes an AI prompt, delivery specification, and acceptance criteria. Examples: patent research, domain strategy, legal structure analysis, brand development.
🔒
The Gating Mechanism
The vault contribution period cannot open until every listed module shows a completed and verified delivery record. The smart contract enforces this — no deposits accepted until the condition is met.
👤
Who Buys Modules
Anyone — not only eventual contributors. Module buyers complete real, paid work. They deliver verified outputs and receive payment. They may or may not go on to contribute to the vault.
📄
After Modules — SEO Articles
When all modules are purchased and delivered, every contributor submits one original AI-assisted article about the project from their own unique perspective. These are indexed and form the project's initial organic content base before public launch.
Example Module List — Project Formation
M1
Patent landscape research — identify prior art across the primary claim areas and produce a written analysis with sources
M2
Domain namespace analysis — identify available domains across eight TLDs and recommend an acquisition strategy
M3
Legal structure comparison — evaluate three corporate structure options and produce a written recommendation
M4
Competitor analysis — identify ten closest competitors, map their funding models and token structures
M5
Community platform analysis — evaluate five platforms for contributor engagement and produce a recommendation
Prior Art Landscape
What Exists vs. What Rédeas Vault Adds
The general concept of contributor-governed fund release has existed since 2018. The specific mechanisms below were not found in any prior implementation across protocols, academic publications, or open-source code repositories.
Contributor fund approval. DAICO (2018): ✓. Juicebox: ✓. multi-signature wallet: —. Rédeas Vault: ✓.
Contributor refund vote. DAICO (2018): ✓. Juicebox: ✓. multi-signature wallet: —. Rédeas Vault: ✓.
VRF random keyholder selection. DAICO (2018): —. Juicebox: —. multi-signature wallet: —. Rédeas Vault: ✓.
Depositor-only equal-weight voting. DAICO (2018): —. Juicebox: —. multi-signature wallet: —. Rédeas Vault: ✓.
Dual-approval gate. DAICO (2018): —. Juicebox: —. multi-signature wallet: —. Rédeas Vault: ✓.
Mandatory labour contribution. DAICO (2018): —. Juicebox: —. multi-signature wallet: —. Rédeas Vault: ✓.
Pre-raise module purchase system. DAICO (2018): —. Juicebox: —. multi-signature wallet: —. Rédeas Vault: ✓.
Hardcoded designated wallet. DAICO (2018): —. Juicebox: —. multi-signature wallet: ✓. Rédeas Vault: ✓.
Intellectual Property Status
The four novel mechanisms described in this section — VRF depositor-keyholder selection, depositor-only equal-weight voting, dual-approval gate architecture, and mandatory labour contribution — are the subject of a patent protection in preparation by the protocol licensor. The module purchase system is included as an additional claim. No portion of the novel protocol architecture may be reproduced or implemented without a licence agreement.
Chronimy makes every reasonable effort to ensure the accuracy of the information in these materials. Given their volume and the pre-launch, evolving nature of the project, we cannot guarantee that every detail is complete, current, or error-free. Nothing here is a warranty of accuracy; figures, projections, and structures are subject to change, verification, and professional sign-off. This is not financial, legal, or tax advice.
‹ Back to site
Technical Architecture
Smart Contract Design
Rédeas Vault is a non-upgradeable Solidity smart contract deployable on EVM-compatible chains. All core parameters are set at deployment and cannot be modified by any party afterwards. The contract governs deposits, keyholder selection, releases, and refunds without any administrator override capability.
Deployment Parameters — Immutable After Deployment
address public designatedWallet;
uint256 public keyholderInterval;
uint256 public keyholderThreshold;
uint256 public timelockPeriod;
uint256 public refundWindow;
Keyholder Selection — VRF Flow
function requestKeyholderSelection() internal {
requestId = COORDINATOR.requestRandomWords(
keyHash, subscriptionId, requestConfirmations,
callbackGasLimit, numWords
);
}
function fulfillRandomWords(uint256 _id, uint256[] memory _words) internal override {
uint256 index = _words[0] % depositorCount;
keyholders[depositors[index]] = true;
}
Release Gate — Both Conditions Required Every Time
function executeRelease(uint256 requestId) external {
require(block.timestamp >= requests[requestId].timelockExpiry,
);
require(requests[requestId].approvals >= keyholderThreshold,
);
payable(designatedWallet).transfer(requests[requestId].amount);
}
Chain Support
Where Rédeas Vault Can Deploy
Rédeas Vault is a chain-agnostic patent claim — the pattern works on any EVM-compatible network where verifiable randomness is available. Chronimy's own deployment is on Polygon PoS only. The chains listed below are alternatives available to other projects licensing the pattern; Chronimy itself does not operate on any chain other than Polygon PoS.
Chronimy Deployment
Polygon PoS
Chronimy's only deployment chain. Low gas, fast finality, full Chainlink VRF v2.5 support, native USDC.
VRF✓ Chainlink VRF v2.5
USDC✓ Native Circle USDC
Gas~$0.01 per transaction
Pattern-Compatible (Other Projects)
Ethereum
Pattern compatible — full VRF v2.5 support. Higher gas suits larger raise sizes. Chronimy does not deploy on Ethereum.
VRF✓ Chainlink VRF v2.5
USDC✓ Native Circle USDC
Secondary
BNB Chain
Large Asia-Pacific user base. Full Chainlink VRF v2.5 support.
VRF✓ VRF v2.5
USDC✓ Available
Secondary
Avalanche / Arbitrum
Both EVM-compatible with full VRF v2.5 support. Arbitrum provides L2 efficiency on Ethereum.
VRF✓ VRF v2.5
USDC✓ Native on both
Optional Trust Layer
Custodian Integration for the Designated Wallet
The designated project wallet hardcoded at deployment can optionally be a regulated custodian-managed address. This adds an independent institutional layer above the vault's own keyholder mechanism. The custodian applies their own approval process before any outgoing payment leaves their system.
How it works technically: The vault sends released funds to the designated wallet address. That address can be custodian-managed. The custodian then applies their internal policy engine — whitelisted destinations, spend limits, multi-approver requirements — before any payment executes outward. The smart contract needs no modification. The custodian layer sits entirely outside the contract and requires no code changes.
MPC Institutional
institutional custody
Most widely used institutional MPC custody. No single complete key ever exists. Policy engine for granular spend rules. Full DeFi integration. API-based.
Suited to larger raises, exchange-scale projects. Annual fee ~$100K+. Integration: 2–4 weeks developer work.
MPC Institutional
BitGo
Oldest institutional custodian. MPC wallet infrastructure. Well-documented API. Polygon PoS including Polygon and Ethereum.
Suited to institution-grade custody needs. Internationally accessible. US-headquartered.
FINMA Regulated Swiss Bank
Sygnum Bank
Swiss FINMA-regulated bank with full digital asset custody. Relationship-based rather than API-heavy. Suited to Swiss AG & Stiftung structures.
Best for Swiss corporate structures. Adds institutional Swiss banking credibility.
Regulated EU/EEA — Bank Custody
A regulated bank
EU/EEA-regulated bank with digital asset services and CHF distribution capability. Compatible with multi-layer custody structures.
Best for CHF distribution layer and EU/EEA-regulated structures.
Integrating a Custodian — Four Steps
1
Open an account with the chosen custodian. Complete their onboarding — identity verification, business documentation, compliance review. Timeline: typically two to six weeks depending on institution.
2
Receive the custodian-provided wallet address for your project. This address is controlled by their key management infrastructure, not a personal private key.
3
Use this address as the designated wallet when deploying the vault contract. No contract modification required — the vault sends to whatever address is hardcoded at deployment.
4
Configure the custodian policy engine — destination whitelisting, spend limits, approval workflows. The institutional layer now governs all outgoing payments independently of the vault mechanism.
Security Design
Attack Vectors and Mitigations
Every smart contract system has attack surfaces. The following were identified during protocol design — each has a structural mitigation built into the architecture.
Keyholder collusion. Risk: Subset of keyholders coordinate to approve a fraudulent release. Mitigation: 4-of-7 per group threshold (8 of 14) combined with mandatory 48hr public visibility. Community observation makes collusion visible. Random VRF selection means keyholders are strangers — coordination requires identifying and reaching randomly selected unknown individuals..
VRF manipulation. Risk: Bad actor deposits at precise Nth interval to influence keyholder selection. Mitigation: Chainlink VRF generates a cryptographic proof with every output published on-chain. Result cannot be known before fulfilment — deposit timing has zero effect on selection outcome..
Sybil voting attack. Risk: Fake accounts inflate community poll votes to create false consensus. Mitigation: Community poll is transparency and observation layer only. The binding gate is keyholder cryptographic threshold. Poll manipulation has no effect on whether funds actually release..
Keyholder wallet compromise. Risk: Keyholder private key stolen and used to sign fraudulent release. Mitigation: 4-of-7 per group threshold (8 of 14) — one compromised wallet cannot reach threshold alone. Hardware wallet use recommended in onboarding flow. 72-hour automatic backup selection if keyholder fails to confirm..
Smart contract exploit. Risk: Undiscovered vulnerability allows direct fund extraction. Mitigation: Dual professional audit mandatory before any deployment. Non-upgradeable design means no post-deployment modification is possible. No admin override functions exist in the contract..
Founder wallet compromise. Risk: Founder wallet stolen — attacker submits fraudulent release request. Mitigation: All releases require full keyholder approval regardless of who submits the request. Designated wallet is immutable — funds can only reach the pre-set address even if approval were obtained..
Audit Requirements
Mandatory Before Any Live Deployment
No Rédeas Vault contract may be deployed in production without completing a full professional smart contract audit. This is a non-negotiable protocol requirement — not a recommendation.
Primary Audit Scope
Full contract logic review — VRF integration, keyholder selection, dual-gate release, refund calculation, designated wallet enforcement. Reentrancy, overflow, and access control analysis throughout.
Independent Second Audit
A second independent firm audits the same scope. Single-audit deployments are not acceptable given the VRF integration complexity and keyholder mechanics involved.
VRF Integration Verification
Specific review of the Chainlink VRF v2.5 integration — subscription management, callback handling, and the depositor-index mapping used for keyholder assignment.
VRF Subscription Funding & Maintenance
Subscription owner: Chronimy Holdings AG (operating company sub-account on the Glass Treasury). Funding source: Security & Compliance allocation (2% of post-launch profit per the 10-way split) — covers all on-chain operational fees including Chainlink VRF subscription LINK top-ups. Pre-launch: funded from Aurora raise via the Glass Treasury operational sub-account. Failure mode: if the VRF subscription is depleted or paused, keyholder selection halts — contributions can still be deposited but no NEW keyholder selections occur until the subscription is replenished. Mitigation: subscription balance monitored on-chain; auto-alerts to Guardian Council Security seat if balance drops below 14-day operational reserve; manual top-up authorised by Guardian Council 4-of-7 from the Security & Compliance allocation. Long-term: Guardian Council reviews VRF provider redundancy at each phase open — alternative VRF providers (drand, Pyth Entropy) under technical evaluation as backup architecture for Pulsar+ phases.
Testnet First — Always
Full functional testing on the target chain's testnet environment before mainnet deployment — covering keyholder selection, release requests, refund scenarios, and backup keyholder activation.
Keyholder Onboarding
Making Any Contributor a Functional Keyholder
VRF selection may assign keyholder status to contributors with no prior blockchain experience. The onboarding flow converts any depositor into a capable keyholder — or selects a backup automatically within 72 hours.
1
Selection Notification
Immediate notification by email and in-app. Explains what a keyholder is, what it means for their contribution, and what they will be asked to do.
2
Five-Screen Walkthrough
What a keyholder is and why it matters. What they will be asked to approve. How to connect a wallet step by step. How to sign a transaction — video and text format. How to get help if needed.
3
Test Signature — Zero-Value Transaction
Keyholder must successfully sign a zero-value test transaction before status is confirmed. Proves signing capability before any real vote is required.
4
Status Confirmed On-Chain
Keyholder status registered on-chain. Notifications sent when release requests are submitted and voting windows open.
5
72-Hour Automatic Backup
If the test signature is not completed within 72 hours, the contract automatically selects the next depositor in sequence. No manual process required.
Chronimy makes every reasonable effort to ensure the accuracy of the information in these materials. Given their volume and the pre-launch, evolving nature of the project, we cannot guarantee that every detail is complete, current, or error-free. Nothing here is a warranty of accuracy; figures, projections, and structures are subject to change, verification, and professional sign-off. This is not financial, legal, or tax advice.
‹ Back to site
The Fee Model
Simple. Transparent. Charged on Release.
Rédeas Vault operates on a straightforward fee structure. A deployment fee is paid once. A protocol licence fee is deducted automatically from each release as it executes. No hidden charges, no recurring subscriptions, no token required to use the protocol.
Rédeas Vault Fee Structure — Per Deployment
Deployment feePaid once when the vault contract is deployed
CHF 500
Protocol licence fee on each releaseDeducted from the released amount at execution — paid to the protocol licensor
0.5%
Protocol licence fee — refund scenarioNon-refundable from the pool in any contributor-voted refund
0.5% of total raised
Smart contract audit costExternal — mandatory before live deployment. Not paid to Rédeas Vault.
~CHF 15,000–30,000
The 0.5% protocol fee applies only to amounts actually released from the vault. If a project raises CHF 1,000,000 and releases CHF 300,000 before a contributor refund vote, the fee applies only to the CHF 300,000 released. In the refund, the 0.5% of total raised is retained by the protocol before the remaining balance is distributed proportionally to contributors.
Market Context
Protocol Revenue at Scale
The total addressable market is the global crypto fundraising market — USD $16.1 billion in verified raises in 2024 across ICOs, IDOs, and private rounds. The following scenarios model Rédeas Vault protocol revenue at different penetration levels. Projections assume 60% of raised capital is released before project lifecycle ends — a conservative assumption.
Conservative
5%
5% of global crypto raises processed through Rédeas Vault
~CHF 2.4M gross protocol revenue
Mid-Case
15%
15% of global raises — reasonable at three years post-launch
~CHF 7.3M gross protocol revenue
Optimistic
30%
Category standard — comparable to Safe multisig adoption rates
~CHF 14.5M gross protocol revenue
Market size basis: CryptoRank 2024 Fundraising Report — $16.1B total crypto fundraising in 2024. Revenue projections are illustrative estimates based on fee model assumptions and are not financial forecasts or guarantees.
Deploying a Vault
How a Project Deploys Rédeas Vault
The deployment process is designed to be accessible to any project founder with basic blockchain familiarity. The Rédeas Vault dashboard guides founders through each step from licence registration to vault going live.
1
Licence Registration
Project registers under the Rédeas Vault licence, completes the standard agreement, and pays the CHF 500 deployment fee. Identity verification of the project founder is required before deployment access is granted.
2
Audit Completion
Project completes dual professional audit of their vault deployment. The audit report must be provided before the deployment access key is issued. This step is mandatory — no exceptions.
3
Parameter Configuration
Founder sets the designated project wallet address, keyholder interval, keyholder threshold, and raise target. The dashboard previews all parameters for review and confirmation before deployment.
4
Module List Publication
Founder publishes the pre-raise module list — discrete work tasks available for purchase. The vault contribution period is locked until all modules show verified completion records.
5
Contract Deployment
Contract deploys to the chosen chain. The vault address is generated and published. The project contribution page goes live showing the vault address, parameters, and module completion status.
6
Vault Opens for Contributions
Once all modules are verified complete, the vault opens. Contributors deposit, complete their content contribution requirement, and keyholder selection begins automatically at the configured interval.
The Bottom Line
"We are not asking you to trust us
with your money. We are asking
you to trust the contract.
Read it first."
Rédeas Vault was built because the people who fund projects deserve structural control over the money they contribute. Not policy. Not promises. Code that cannot be overridden, rewritten, or bypassed — by anyone.
Important Notice
This document is a technical and product specification for the Rédeas Vault protocol. It does not constitute financial advice, investment advice, or legal advice of any kind. The novel mechanisms described in this document are the subject of patent protection in preparation and are the intellectual property of the protocol licensor. Unauthorised reproduction of the protocol architecture is prohibited. All participants should obtain qualified legal and financial advice specific to their jurisdiction before participating in any vault deployment.
Chronimy makes every reasonable effort to ensure the accuracy of the information in these materials. Given their volume and the pre-launch, evolving nature of the project, we cannot guarantee that every detail is complete, current, or error-free. Nothing here is a warranty of accuracy; figures, projections, and structures are subject to change, verification, and professional sign-off. This is not financial, legal, or tax advice.
‹ Back to site