Properties

What the contract is and isn't.

A public constraint sheet for the stake.one staking vault. What's hardcoded, what's bounded, and what isn't shipped yet. Mechanism-first; no narrative.

1. What the contract cannot do

The most defensible properties of stake.one are structural facts about what the bytecode does not contain. Each item below is enforced by the absence of a code path, not by a policy.

  • Cannot raise the fee. FEE_BPS = 100 is a Solidity constant in the contract bytecode. No proxy, no upgrade path.
  • Cannot transfer your vault tokens. Vault tokens are non-ERC-20 and have no transfer() function. The only way out is withdraw() from your own address.
  • Cannot stop being non-custodial. Funds at all times either belong to a depositor (via their vault tokens) or are queued for withdrawal to a pre-configured receiver.
  • Cannot be paused for withdrawals. Even if depositsPaused = true and emergencyMode = true, the withdrawal claim path remains open.
  • Cannot be upgraded. No proxy, no delegatecall-based admin slot, no UUPSUpgradeable.
  • Cannot pay the owner more than the 0.1% protocol fee share. The protocol fee accrues inside the immutable vault contract. There is no privileged compound-bounty path.
  • Cannot delegate to a validator outside the approved set. The approved-validator list is governed by 7-day timelock; new additions are public for 7 days before they take effect.

2. Immutable contract rules

  • 1% fee, hardcoded as a Solidity constant. The 0.9% caller bounty + 0.1% protocol fee split is also constant.
  • No proxy. The bytecode is final at deploy.
  • Non-transferable vault tokens. Internal bookkeeping only; not ERC-20.
  • No admin keys for funds. Owner has governance powers (validator weights, pause, emergency mode) but cannot unilaterally move user funds.
  • Permissionless compounding. Any vault depositor can call compound() and receive 0.9% of the vault's total pending rewards as a bounty.
  • Withdrawals route to a pre-configured receiver, not msg.sender. Caller pays gas; funds flow to the request's pre-set address.
  • Two-step ownership via OpenZeppelin Ownable2Step. Accidental ownership hand-off is impossible.

3. Operational safeguards

  • transferWithdrawalRequest pattern. If a key is compromised, the owner of a pending withdrawal can redirect it to a clean address before the unlock. Mechanism is permissionless and on-chain; first-mover wins (no admin override).
  • Local plaintext key copy for operational wallets, on a non-browser host. Provides a recovery path against MetaMask-class compromises (counter to typical hardware-wallet-only doctrine).
  • Multi-host operational redundancy. Compound-caller and validator operations run on a dedicated host with periodic state sync. The compound caller is not a privileged role — any depositor can call compound(); we publish an open-source script as one example.
  • Public timelock queue. Every governance change is on-chain for 7 days before it takes effect. See /timelocks.

4. Governance + timelock

  • 7-day timelock on all weight changes, validator additions/removals, protocol fee withdrawal changes, and emergency-mode toggles.
  • Public visibility from the moment a change is queued. See /timelocks for the live queue.
  • Owner can cancel a queued change but cannot amend it or skip the delay.
  • The owner cannot change the fee (it's a constant) or move funds (no admin path).
  • Two-step ownership: any owner change requires acceptance by the recipient address.

5. Verify it yourself

Every vault property listed on this page is queryable from any public RPC. The commands below read live values from the Harmony deployment.

# Vault state
cast call 0x061A7e7e317AcE450940D5aD3372Db0b7C205dE4 'totalManagedAssets()(uint256)' --rpc-url https://api.harmony.one
cast call 0x061A7e7e317AcE450940D5aD3372Db0b7C205dE4 'totalShares()(uint256)' --rpc-url https://api.harmony.one
cast call 0x061A7e7e317AcE450940D5aD3372Db0b7C205dE4 'pricePerShare()(uint256)' --rpc-url https://api.harmony.one

# Your own position
cast call 0x061A7e7e317AcE450940D5aD3372Db0b7C205dE4 'sharesOf(address)(uint256)' <YOUR_ADDRESS> --rpc-url https://api.harmony.one

# Validator pool
cast call 0x061A7e7e317AcE450940D5aD3372Db0b7C205dE4 'getValidatorList()(address[])' --rpc-url https://api.harmony.one
cast call 0x061A7e7e317AcE450940D5aD3372Db0b7C205dE4 'totalWeight()(uint32)' --rpc-url https://api.harmony.one

All vault state is queryable without permission. No backend, no API.

Note: the contract field pricePerShare is the on-chain name for what this page calls the redemption rate.

6. Current operational limits

Factual inventory of what is and isn't shipped today.

  • No formal third-party audit shipped yet. The contract is open-source on GitHub; readers can verify the bytecode + source themselves. Audit funding is a deliberate later-stage decision, not an oversight.
  • No bug bounty program shipped yet. Same rationale.
  • Single-operator validator team. Two validators in the active pool (IPH and Validator.ONE) are operated by the same team. Disclosed on /validators. The dual-validator approach reduces single-operator risk under Harmony's EPOS election mechanism but does not eliminate it.
  • No KYC, no whitelist, no allow-list. Anyone can deposit; anyone can compound(); anyone can withdraw.
  • Solo-developer build. The contract was deployed by a single engineer. The constraint set above (no admin keys, no upgrade path, public timelock) is the structural mitigation for the lack of an audit.

7. Where to look next

This page is a snapshot of structural facts about the deployed bytecode and current operating posture. The contract source is the source of truth; if anything on this page conflicts with the on-chain bytecode, the bytecode wins.