What is a Sysvar
A sysvar, short for system variable, is a special, read-only account kept track of by the Solana runtime to make cluster state available to programs. Need to know the current slot, the unix timestamp, the rent rate, or the epoch schedule? A sysvar has it all stored at a fixed, known address that validators update automatically. Programs don't write to sysvars; rather, anyone and everyone can read them.
They're like the departures board of a train station that is continually updated by staff for everyone to read. And no, you don't get to go up there and change the numbers for your platform. That's sysvars in a nutshell. They're the official state of the chain, visible to everyone, managed by the system, and unchangeable by users.
How Sysvars Work Technically
Each sysvar has its own address hard-coded to specific public keys. Clock is SysvarC1ock11111111111111111111111111111111; for example. It has the current slot, epoch, and unix timestamp. The Clock sysvar is refreshed during every 400-millisecond slot. Rent gives the deposit rates that determine what accounts need to be rent-exempt. EpochSchedule has information about epoch boundaries- each epoch has 432,000 slots (roughly 2 days). SlotHashes contains the most recent hashes of slots, StakeHistory stores information on the stake activation and deactivation of epochs, Instructions gives a program the ability to see the instructions in its transaction.
A program reads sysvars the same way it reads any other account or uses the built-in syscalls for the most popular sysvars like Clock. Reading a sysvar costs nothing beyond normal compute and does not require an oracle or an external data source. The same validators that are executing your transaction wrote the data. Sysvars are oracles of sorts but "for free," and they are limited to facts that the chain can only know.
Instructions is worth mentioning because it allows a program to introspect. That is, programs can check that an instruction that they expect has been included before them in the same transaction. This is how some DEXs check that a fee payment was made alongside a swap, and how the Jito team can check for tip transactions, all without having to blindly trust the caller to provide data.
How Sysvars Compare to Ethereum
Ethereum has similar built-in values, as block.number, block.timestamp, block.basefee. They're accessible to contracts as built-in language keywords. Solana has a similar end-goal but does so via everything is an account philosophy; so all cluster state is just another list of accounts and can be read explicitly within transactions, rather than an implicit value that's available via some ambient context. This isn't just cosmetic, as it allows the runtime to know exactly which transactions depend on which pieces of state and facilitates parallel transaction execution; a benefit that block.timestamp style ambient variables do not enable. Compare this to Bitcoin where almost nothing is accessible; in fact, the only access is via timelocks and you cannot simply read the current block height in Script.
Why Sysvars Matter
Consider a liquid staking protocol like Marinade, where users deposit their stake and receive a liquid token. Users can unstake their liquid tokens at any time after the staking period has expired. To know whether a user can unstake, a program reads EpochSchedule and Clock, does some arithmetic, and sends funds to the user once the unstaking period expires. That is a keeper-bot-free protocol, oracle-free, user-action-free protocol that is possible thanks to sysvars. Protocols for lending like Kamino and Solend also use the sysvar Clock for when a user borrows, accrues interest, and how long a user needs to wait until they can liquidate their collateral for a loan. If you have ever tried to do vesting on the chain, there's a good chance that your claim period checks against Clock and sysvars.
With that in mind, consider every protocol on the chain; sysvars are among the most frequently read accounts on Solana and yet, no data provider is being charged in the process.
The caveat is the accuracy of the Clock sysvar. The unix timestamp is based on validator's vote of what the current slot start-time is, and it is not the actual time; in fact, it has historically drifted by a few seconds and in some rare occasions has drifted for some minutes due to chain health conditions. However, protocols treat the Clock as having second level precision, and for some other requirements with more granular needs, users have to count slots and not rely on unix timestamps.
That aside, sysvars are an incredibly powerful mechanism that solves a massive problem for Solana devs. What Ethereum developers get from globals or what other blockchains get from oracle networks, Solana developers get from a sysvar that's been sitting there all along.
