Global Variables are predefined blockchain variables that are automatically available in rule conditions and effects. These variables provide access to common blockchain context information without requiring explicit configuration. Global variables are prefixed with GV: and can be used directly in condition expressions, tracker update expressions, and other rule logic.

​
Available Global Variables

The following global variables are supported:
VariableTypeDescription
GV:BLOCK_TIMESTAMPuint256Current block timestamp (Unix timestamp)
GV:MSG_DATAbytesComplete calldata of the current message
GV:MSG_SENDERaddressAddress of the message sender
GV:BLOCK_NUMBERuint256Current block number
GV:TX_ORIGINaddressOriginal external account that initiated the transaction

​
Usage in Rule Conditions

Global variables can be used directly in condition expressions: 
{
  "Name": "Time-based Access",
  "Description": "Restrict access after a specific timestamp",
  "condition": "GV:BLOCK_TIMESTAMP > 1751452000",
  "positiveEffects": [],
  "negativeEffects": ["revert(\"Access denied after deadline\")"],
  "callingFunction": "withdraw(uint256 amount)"
}

{
  "Name": "Sender Restriction",
  "Description": "Only allow specific sender addresses",
  "condition": "GV:MSG_SENDER == 0x1234567890123456789012345678901234567890",
  "positiveEffects": [],
  "negativeEffects": ["revert(\"Unauthorized sender\")"],
  "callingFunction": "adminFunction()"
}

​
Usage in Tracker Updates

Global variables can also be used in tracker update expressions: 
{
  "Name": "Time Elapsed",
  "Description": "Update tracker with seconds since it was last updated",
  "condition": "1 == 1",
  "positiveEffects": ["TRU:timeElapsed = GV:BLOCK_TIMESTAMP - TR:lastTimeStamp)"],
  "negativeEffects": [],
  "callingFunction": "test()"
}

​
Common Use Cases

​
Time-based Logic

Use GV:BLOCK_TIMESTAMP for implementing time-based restrictions, deadlines, or time windows: 
{
  "condition": "GV:BLOCK_TIMESTAMP >= 1751452000 AND GV:BLOCK_TIMESTAMP <= 1752640000",
  "positiveEffects": [],
  "negativeEffects": ["revert(\"Outside allowed time window\")"]
}

​
Access Control

Use GV:MSG_SENDER and GV:TX_ORIGIN for implementing access control: 
{
  "condition": "GV:MSG_SENDER == adminAddress OR GV:TX_ORIGIN == ownerAddress",
  "positiveEffects": [],
  "negativeEffects": ["revert(\"Access denied\")"]
}

​
Transaction Analysis

Use GV:MSG_DATA for analyzing transaction data or implementing complex validation logic: 
{
  "condition": "GV:MSG_DATA.length > 4",
  "positiveEffects": ["emit \"Valid transaction data\""],
  "negativeEffects": ["revert(\"Invalid transaction data\")"]
}

​
Block-based Logic

Use GV:BLOCK_NUMBER for implementing block-based logic, such as rate limiting or periodic operations: 
{
  "condition": "GV:BLOCK_NUMBER > TR:lastProcessedBlock + 100",
  "positiveEffects": ["TRU:lastProcessedBlock = GV:BLOCK_NUMBER)"],
  "negativeEffects": []
}

​
Important Notes

Global variables are automatically available in all rule contexts. You don’t need to configure or import them—they’re ready to use in any condition expression or effect.
When using GV:MSG_SENDER vs GV:TX_ORIGIN, remember that:
  • GV:MSG_SENDER is the immediate caller (could be a contract)
  • GV:TX_ORIGIN is the original external account that initiated the transaction
Use GV:MSG_SENDER for authentication and access control. Use GV:TX_ORIGIN only when you specifically need to identify the original transaction initiator, and be aware of the security implications. OWASP Smart Contract Security article
Global variables reflect the current blockchain state at the time the rule is evaluated. Be aware that block timestamps and numbers can vary slightly between different nodes, and GV:BLOCK_TIMESTAMP may not be perfectly accurate for time-sensitive applications.