New policy
Observe a transaction
A boundary is derived from something that already happened. Paste a Soroban testnet hash, or use a shipped fixture.
- hash
- 3f1c9a7e5b2d84610fae37cc9d15b8027e4a6d3f8c1b5e9027a4d6f8b3c1e5a9
- network
- simulated(shipped fixture — not observed on a live network)
- ledger
- 51234
- source
- the account the policy installs on
| # | Contract | Function | Arguments |
|---|---|---|---|
| 0 | transfer() |
|
Token movements
caused by the single invocation above- OUT500000000(50)
Amounts are integers in the asset's smallest unit; the parenthesised value is a display rendering only. Only OUT movements — those leaving the source account — contribute to a derived cap, and they are summed gross: an inflow of the same asset is never subtracted.
Review what Limen derived
The least-permissive boundary that still permits the flow above. Computed in your browser by the same package the test suite runs.
Context rule
| allowed contracts | |
|---|---|
| allowed functions |
|
| validity | ledger 51234 → 172194 (≈ 7 days) |
Policies(2 of 5 max)
| Primitive | Target | Configuration |
|---|---|---|
| spending_limit | 500000000(50)per 120960 ledgers(≈ 7 days) | |
| function_allowlist | transfer() |
What would be written to the chain
Not the same thing as the boundary above. Limen's model can express constraints no audited primitive imposes; those are refused here rather than installed as something broader.
Install
Writing the plan above to a smart account, signed by its owner.
There is no lowered plan to write. Either the boundary above was not derived, or lowering refused it — in which case the reason is stated above rather than worked around here.
There is no form here that accepts a secret key, and there will not be one.