SYS / 001YOUR SOL. INSIDE YOUR RULES.
A SOL vault with withdrawal limits, delays and guardian checks you configure.
A compromised key can still spend an enabled instant allowance.
01BEFORE YOU NEED THEM
Your signature is the beginning of a withdrawal.
Your on-chain policy determines what happens next.
Per-transaction limits.
A rolling instant budget.
A separate request.
Configured guardian checks.
A visual explanation of the mechanism. Not a real vault configuration.
02VALUE IN. A RECEIPT OUT.
SOL enters the on-chain reserve. Non-transferable secSOL in your wallet represents the net amount after the configured deposit fee.
Not a second spendable balance. Not a tradable token. No yield is implied. These amounts and the fee are illustrative.
ONE POSITION. MATCHING BACKING AND RECEIPTS.
03SAME WALLET. DIFFERENT BOUNDARIES.
Put rules around your vaulted SOL.
Keep using the funds you leave outside it.
Trade with the funds outside your vault. Your wallet signs the swap; no vault withdrawal takes place.
Funds outside the vault keep ordinary wallet risk. Vaulted SOL and secSOL cannot be traded directly.
04WHEN A KEY IS COMPROMISED
A valid signature still meets the instant rules. But the allowance you leave available is still exposed.
2.00 SOL direct RejectedAbove the example per-transaction cap. No pending request is created.
0.20 SOL direct PermittedA separate, smaller attempt can pass. This SOL could be lost.
EXAMPLE POLICY
0.25 SOL / instant transaction · 0.50 SOL rolling budget
Resets after 24h without an instant withdrawal.
The permitted example assumes no other enabled check blocks it. Instant recipients are not protected by the trusted-destination check.
9.80 secSOL remaining
05A DIFFERENT PATH
The owner signs a separate protected withdrawal request.
Its amount and recipient are fixed. Its review window begins.
Cutaway illustration—not an unlocked vault. A compromised owner key can also submit a request. Enabled trusted destinations are checked on this protected path.
06PEOPLE, NOT MAGIC
Guardians check the request. They can approve it—or respond when something is wrong.
With a 24h delay and a 2-of-3 threshold configured, both conditions must be met before the owner can redeem.
Protection depends on your settings and guardian availability. Notifications are advisory, not a guaranteed alarm or automatic threat detector.
THREE GUARDIANS · A TWO-VOTE THRESHOLD · ILLUSTRATIVE ONLY
07THE DELIBERATE EXIT
After the owner signs, 2.00 secSOL is burned and 2.00 SOL goes to the fixed recipient. Your remaining receipt balance stays in your wallet.
The earlier 0.20 SOL loss remains. Receipt burn and SOL transfer are atomic.
The card swipe is illustrative, not a bearer key. The owner still signs after all configured checks.
08LESS TRUST IN A SINGLE MOMENT
SecureYourSOL adds rules around how a SOL position can leave its reserve. Understand both the controls and their limits before you use it.
A per-transaction cap and rolling budget bound instant exits. The budget resets only after a full window since the last instant withdrawal; it does not refill gradually. A compromised key can spend the available allowance. A separate daily limit is optional.
When enabled, protected requests record an amount and recipient, wait through a delay, and require configured guardian approvals. A rejected instant exit does not automatically enter this path.
SOL is held in a shared authority reserve with per-user on-chain accounting. The chamber is a visual metaphor, not a separate segregated reserve. Program and upgrade-authority trust remain part of the security model.
Guardians must be available. Notifications can fail. Established-policy changes follow review and timelock rules. Recovery resets security and can replace guardians; it does not transfer ownership to a new wallet.
Keep day-to-day activity in your wallet. Apply withdrawal rules to the SOL you choose to vault.
| Workflow | Ordinary wallet | Multisig account | Wallet + SecureYourSOL |
|---|---|---|---|
| Everyday activity | Your wallet signs. | Account rules apply; configured spending allowances may avoid a full vote. | Your wallet signs for funds outside the vault. No vault guardian vote. |
| Moving held funds | The wallet signature authorizes spending. | The account’s approval threshold and enabled controls apply. | Vault withdrawals follow your instant limits or protected-request rules. |
| What stays separate | No additional vault boundary. | A separate daily wallet can coexist with the multisig. | Funds outside the vault retain ordinary wallet risk. secSOL is a receipt, not trading liquidity. |
Multisig implementations differ. For example, Squads supports spending limits ↗ and timelocks ↗. The distinction here is the personal-vault workflow—not exclusive ownership of these controls.
Hackathon demo. Test SOL only. Not an independent audit, mainnet launch approval, or guarantee against loss.
Independent security review, reproducible build and deployment verification, multisig authority setup, operational testing, and a release review remain required. This devnet demo does not establish that those gates are complete.
The current devnet mint uses frozen, non-transferable receipts. Standalone receipt transfers and burns are blocked; authorized vault redemptions manage thawing and burning atomically. Older test mints do not provide the same receipt protection. Program and upgrade-authority trust still apply.