Smart Contract Architecture
1. Vault Staking Contract Design
Lock/Unlock Logic:
User calls lock_tokens(amount, duration) — tokens transferred to program-owned escrow account
Lock period tracked by absolute slot number at time of deposit + duration in slots
Unlock only executable after current_slot >= unlock_slot
Early exit: disabled by default; future governance vote could enable with penalty fee
Reward Calculation:
reward = principal × APR × (elapsed_slots / slots_per_year)
slots_per_year ≈ 157,680,000 (at ~0.5s per slot target)
APR tier assigned at deposit time and locked for the duration
Rewards accumulated per epoch, claimable at any time without breaking lock
2. Commerce Protocol On-Chain Flow
User initiates purchase → $UCHN deducted from wallet
↓
Program verifies balance + calculates fee split
↓
Merchant payment settled (stablecoin or $UCHN)
↓
Fee: X% burned, Y% to treasury, Z% to staker pool
↓
Cashback (if applicable) credited to user in $UCHN
No KYC is required because the protocol operates at the token level, the user's identity is never involved, only their wallet address and token balance.
3. SPL Token Authority Structure
Authority
Status
Controller
Mint authority
Revoked post-TGE
No one. Supply is permanently fixed
Freeze authority
Revoked post-TGE
No one
Program upgrade authority
Multisig
Core team multisig wallet
Treasury
Multisig
Core team + advisors
Revoking mint and freeze authority at TGE is a rug-pull mitigation — no party can create new tokens or freeze user funds after launch.
4. Guardian Threshold Signature Scheme (M-of-N)
Social recovery uses an M-of-N multisig model:
User selects N guardians (recommended: 3–5)
Recovery requires M approvals (recommended: M = ceil(N/2) + 1)
Guardian addresses stored in a program-derived account (PDA) tied to the user's wallet
Recovery transaction includes a time delay (e.g., 48 hours) to allow the original owner to cancel if unauthorized
Example: 3-of-5 guardian setup
5 guardians designated
Any 3 can initiate a recovery
48-hour cancellation window before execution
5. Dead Man's Switch: On-Chain Inheritance Implementation
User registers beneficiary address + inactivity_threshold (e.g., 365 days)
↓
Heartbeat transactions reset the inactivity counter
↓
If no heartbeat for inactivity_threshold slots:
↓
Beneficiary can claim assets via claim_inheritance() instruction
↓
Assets transferred from user's escrow to beneficiary address
The heartbeat can be any valid on-chain transaction from the wallet, normal usage inherently resets the timer.
Last updated
Was this helpful?