> ## Documentation Index
> Fetch the complete documentation index at: https://open-fi.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# The Allowance State Machine

> Why OpenFi doesn't use static token approvals.

Most Web3 "recurring payment" tools rely on a static ERC-20-style approval: the payer grants a contract access to a large or unlimited balance, and an off-chain bot manually calls a transfer function each period. If that contract is compromised, the entire approved balance is exposed.

OpenFi's **Allowance State Machine** tracks elapsed time, per-epoch maximums, and remaining duration natively on-chain, so a compromised session key can never move more than the ceiling allocated to the *current* active epoch.

|                     | Static approval                                                     | OpenFi Allowance State Machine                         |
| ------------------- | ------------------------------------------------------------------- | ------------------------------------------------------ |
| Mechanism           | Off-chain bot calls `transferFrom` against a large approved balance | On-chain state tracks time + velocity per epoch        |
| Worst-case exposure | Entire approved balance                                             | Current epoch's ceiling only                           |
| Web2 awareness      | None                                                                | Can factor in bank-side data via the data-oracle layer |

This module currently lives on **Aptos (Move)**, chosen for its resource-oriented safety model, and is what session keys are checked against on every debit pull.

<Note>
  Stellar-side settlements do not currently sit behind an identity/allowance gate. This is a known, tracked gap, not an assumption of parity with the Aptos path.
</Note>