Trackers are persistent, on-chain variables defined within a policy. They allow you to store and reference historical, cumulative, or computed values across multiple rule evaluations.

Think of them like scoped smart contract state—available only to your policy but powerful enough to shape complex behaviors.

What Can You Use Trackers For?

Trackers are great for scenarios like:

  • Rate limits (e.g. daily transaction totals)
  • Cooldowns or lock periods
  • Thresholds or quotas (e.g. “users can only mint X per day”)
  • Storing cumulative activity (e.g. “total tokens sold”)
  • Tracking rolling state over time

Defining a Tracker

Each tracker must be configured when deploying a policy. You’ll define:

  • 🆔 Name (required)
  • 📝 Description (optional, off-chain)
  • 🔧 Initial value
    An expression that computes the tracker’s starting value

Tracker values must be initialized during policy deployment. They are available immediately for use in condition expressions.

🛠️ Expression-Based Initialization

Trackers are initialized using an expression—just like rule conditions. You can reference:

  • Fixed config values
  • Token or transaction data
  • Foreign contract values

Example

name: dailyTransferred
description: Tracks how much a user has sent today
initialValue: 0

Reading from a Tracker

Once defined, you can reference any tracker in:

  • Rule condition expressions
  • Tracker update expressions
  • Foreign call arguments

You simply use its name as a variable.

Be mindful of the order your rules run in. Trackers are updated as effects, so the new value is only visible in later rules—not the one that triggered the update.

Updating a Tracker

Trackers are updated using the update tracker effect type. You’ll provide:

  • The name of the tracker
  • An update expression that computes the new value

Example:

onTrue:
  - updateTracker:
      id: dailyTransferred
      expression: dailyTransferred + transaction.amount

Tracker Visibility

While trackers are internal to your policy, they are stored on-chain and may be made readable externally. This enables other contracts to:

  • Query current tracker values
  • Use them as part of off-chain logic
  • Integrate them into dashboards or analytics tools

Avoid unintended tracker conflicts. If multiple rules update the same tracker, make sure it’s deliberate. The Forte UI will warn you about this.

Summary

FeatureDetails
ScopePrivate to a single policy
PersistenceStored on-chain, mutable via effects
InitializationRequired at policy deployment via an expression
Usable InRule conditions, tracker updates, foreign calls
External AccessMay be exposed to external contracts (read-only)