What Is Onchain Security? Code, Keys, Oracles and Response
Quick answer. Onchain security is the set of controls that limit what the blockchain will execute for your protocol. It covers contract code, admin roles and the keys behind them, upgrades, oracle and contract dependencies, and the monitoring and response that catch misuse.
Video transcript
A blockchain runs any valid transaction your code and permissions allow. It never checks who meant it, or why.
Onchain security is the set of controls that limit what the chain will execute for your protocol. A signer's key lives offchain, but the role it holds is onchain.
It spans contract code, roles and keys, upgrades, oracles and dependencies, and monitoring and response.
Code is the outer wall. Ethereum's developer docs recommend layered testing and independent review, but audits will not catch every bug.
Admin powers can mint, pause or upgrade with no bug at all. SEAL's multisig baseline: at least three distinct signers, a threshold of fifty percent or more, hardware wallets, and independent verification.
Oracles matter too. In Guardian's RAAC audit, a vault path accepted stale NFT appraisals, a Low finding marked Resolved. Across Guardian's public work, 115 of 321 reports mention oracles, a measure of review coverage, not exploits.
Monitoring shows when the boundary is tested. Watch role changes, upgrades, large transfers, oracle deviations and multisig signer changes, and give every alert an owner.
Offchain security covers what builds, signs or shows transactions: frontends, APIs, cloud and DNS. The two meet at the signer, and neither covers the other.
Read the full guide, or talk to Guardian. Managed Security monitors your contracts on every block, watches domains, DNS and cloud, and an engineer responds around the clock.
Onchain Security Defined
A blockchain runs any valid transaction your code and permissions allow. It does not check who meant it, or why.
So for a founder the question is narrow: what can your contracts be made to do, and by whom?
Onchain security is the set of preventive, detective and response controls that limit what deployed contracts, privileged roles, oracle inputs and upgrades can make the chain execute.
There is no single standard definition. We draw the line at execution: a control is onchain if it changes what a transaction can do once it lands.
Where a control runs does not decide it. A signer's key lives on a device offchain, but the role it holds, and the damage it can do, is onchain.
| Surface | Question it answers | Core controls |
|---|---|---|
| Contract code | What can any caller make it do? | Tests, fuzzing, independent review |
| Roles and keys | Who can call privileged functions? | Scoped roles, multisigs, execution delays |
| Upgrades | Who can replace the code? | Timelocks, multisigs, review of every change |
| Oracles and dependencies | What outside data does it trust? | Freshness checks, bounds, failure modes |
| Monitoring and response | How fast is misuse seen and stopped? | Owned alerts, documented responses, tested delivery |
Contract Security
The code is the outer wall. Anyone can call a public function, with any input, in any order.
Ethereum.org recommends layering unit and property tests, static analysis, fuzzing and, where it fits, formal verification, then independent review. Ethereum.org
It is also direct about limits: audits will not catch every bug. They add a round of review; they do not certify the code.
Write the invariants before the review. A rule such as the vault never owing more than it holds gives fuzzers and auditors a target.
Treat fixes and upgrades as new code. Each gets the same review as launch, and the invariant suite runs again.
Our smart contract security guide sets out seven layers, from design to monitoring, and what each one catches.
Keys and Admin Powers
Privileged functions are part of the code. Whoever can call them can mint, pause, upgrade or move funds with no bug at all.
OpenZeppelin's Ownable gives one owner account exclusive access to protected functions. OpenZeppelin notes that production projects tend to outgrow it. OpenZeppelin
AccessControl splits power into named roles, each with an admin role that grants and revokes it. AccessManager adds hierarchical roles across contracts and execution delays.
Our comparison of Ownable, AccessControl and AccessManager covers when to use each and the mistakes audits find.
Upgrades are the largest admin power, because they replace the logic users trusted. Ethereum.org calls a single owner address a single point of failure, and recommends a multisig so actions need several parties. Ethereum.org
Then protect the keys behind the roles. Our multisig best practices turn SEAL's framework into a full signer policy.
SEAL's multisig operations certification, revision 1.1 updated April 17, 2026, sets the baseline listed below. Security Alliance
- At least three distinct signers and a threshold of 50% or more, with no N-of-N setups.
- Hardware wallets for every signer, with a fresh, dedicated address per multisig.
- Independent verification by each signer, with hashes cross-checked on two separate interfaces.
- Offboarded signers removed within 48 hours to 14 days, depending on the multisig's classification.
- Quarterly access reviews, and an emergency drill at least once a year.
Oracles and Dependencies
Contracts also trust things they do not control: price feeds, other protocols, bridges and tokens.
A bad input executes as faithfully as a good one. A stale price can mint, lend or liquidate at the wrong value.
Chainlink feeds are not streaming. They update when the answer moves past a configured deviation threshold or when the heartbeat idle time passes. Chainlink Documentation
Chainlink tells consumers to check when the data was last updated, and to pause or switch to an alternate mode when it is too old.
Read the timestamp from latestRoundData's updatedAt. Chainlink's API reference marks latestTimestamp as deprecated and says latestAnswer carries no timestamp at all.
Guardian's RAAC Core Contracts audit shows the gap. A production vault path discarded the oracle's timestamp and accepted stale NFT appraisals. Guardian
Minting enforced a one-hour freshness rule; the vault did not. It could over-issue iRAAC, then dilute existing holders once the price was corrected. The Low finding is marked Resolved.
Oracle logic runs through Guardian's public work. In Guardian's keyword count across its 321 public reports, 115 mention oracles; together they hold 5,392 findings, 235 of them Critical.
That count covers every finding in those reports, not only oracle findings. It shows review coverage, not an exploit rate.
Manipulation is a separate threat. Our guide to price oracle manipulation shows how a spot price moves within one transaction.
- Reject prices older than the feed's heartbeat, plus a small margin.
- Bound each price against a sanity range or a second source.
- Decide in code what happens when a feed fails: pause, fallback or a reduced mode.
- Add every external contract you call to the trust model, with its admin and upgrade path.
Monitoring and Response
Preventive controls set the boundary. Monitoring shows when someone is testing it, or when it quietly moves.
The signals worth watching, listed below, come from SEAL's monitoring guidelines and its multisig certification. Security Alliance
SEAL says every alert must have a designated owner and a documented response.
It also says to test alert delivery end to end, and to alert when an existing alert is disabled or changed.
Response onchain means a pause, a freeze or a revoked role. Each needs a key someone holds, and a path rehearsed on a fork.
Monitoring has a limit. It sees attacks and changes as they land, but cannot prove that an untriggered bug is absent. Guardian Resource Hub
Our guide to onchain monitoring covers the events to watch, and our DeFi incident response plan covers pause authority and drills.
- Ownership transfers, admin role changes and access control changes.
- Contract upgrades.
- Large transfers, above all from protocol and treasury wallets.
- Minting, burning and approvals outside normal patterns.
- Oracle price deviations and unexpected governance proposals.
- Unusual bridge volumes, and bridge contract state or ownership changes.
- Node health, block propagation and RPC availability.
- Multisig signer and threshold changes, nonce gaps, and module or guard changes.
Onchain vs Offchain Security
Offchain security covers the systems and people that build transactions or shape what users and signers see: frontends, APIs, cloud, CI/CD, keys, vendors and DNS. Guardian Resource Hub
The two meet at the signer. The key is custodied offchain; what it can authorize is set onchain.
Neither side covers the other. A flawless contract still runs a malicious upgrade a deceived signer approves, and a hardened laptop does not fix a stale price.
Read what offchain security covers for the surfaces around your contracts, and use our web3 security best practices to run both as one program.
| Aspect | Onchain security | Offchain security |
|---|---|---|
| Protects | What contracts will execute | What builds, signs or shows transactions |
| Surfaces | Code, roles, upgrades, oracles | Frontends, APIs, cloud, CI/CD, DNS, vendors |
| Typical failure | Logic bug, misused role, stale price | Tampered frontend, stolen key, hijacked domain |
| Testing | Fuzzing, invariants, independent review | Pentests, OpSec and configuration review |
| Detection | Chain events and contract state | Domain, DNS, cloud and code host changes |
Frequently Asked Questions
Where should a team start with onchain security?
With an inventory: every privileged function, who holds it, the key or multisig behind it, and any delay. Read it from chain state rather than docs, because deployed roles can drift from what the documentation says.
Is onchain security only for DeFi protocols?
No. Any team whose contracts hold value or carry admin powers needs it: token and stablecoin issuers, DAOs with treasuries, bridges, and teams that hold funds in multisigs. The surfaces are the same; the size of the admin powers differs.
How often should onchain controls be reviewed?
Whenever the system changes: an upgrade, a new role holder, a new oracle feed or a signer rotation. After each one, re-read roles, owners and multisig thresholds from chain state and check them against your inventory.
Related reading
- onchain vs offchain crypto hacks
- who controls defi admin keys census
- smart contract upgrade change management
- what is web3 mdr
Sources
- Ethereum.org: Smart contract security
- OpenZeppelin: Access utilities and implementations
- Chainlink Documentation: What are Chainlink Data Feeds?
- Security Alliance: Guidelines for On-Chain Monitoring
- Security Alliance: SFC - Multisig Operations
- Guardian: RAAC Core Contracts Audit Report: stale NFT appraisals
- Guardian Resource Hub: What Is Offchain Security? The Attack Surface Audits Miss
- Guardian Resource Hub: What Is Onchain Monitoring? A Guide for Security Teams
- Guardian: Managed Security
- Chainlink Documentation: Chainlink Data Feeds complete documentation (TXT)
- Chainlink Documentation: Data Feeds API Reference
- Guardian: Published Smart Contract Audit Reports
- Guardian: Published Smart Contract Audit Reports: oracle search
Keep Watch on What Your Contracts Execute
Guardian's Managed Security monitors your contracts on every block, from role changes and upgrades to multisig transactions, and watches domains, DNS and cloud. A Guardian engineer responds around the clock.