Using Trimmy

What happens after you arm

The timeline from a settled XRPL payment to a rule that executes itself, with measured times and who does each step.

Working with an agent? Every page here has a markdown twin, the whole site is one file at llms-full.txt, and trimmy-mcp lets it read live rules and compose a payment it cannot send.

Testnet. Trimmy runs on Flare Coston2. Nothing described here has run on Flare mainnet, and no page on this site describes real money.

Your payment is sent. From here nothing needs you: you can close the tab, and no support desk is waiting on you. Four things happen, and only the first is yours.

The numbers here come from two complete runs on chain, 2026-08-07 and 2026-08-09.

The attestation

Flare does not read the XRP Ledger directly. Someone requests an attestation of your transaction id from the Flare Data Connector, paying a small fee (1,000 wei in the first run). The request joins a voting round, and the proof can be fetched once that round finalises.

Measured: the proof arrived on the fifth poll in one run and the eighth in another, 20 seconds apart. Rounds are usually under two minutes on Coston2, but one took over fifteen. Expect minutes, not seconds.

Your batch runs on your account

With the proof in hand the executor calls executeDirectMintingWithData, passing both the proof and the user operation your 42-byte memo commits to. FAssets mints FXRP into the personal account derived from your XRPL address, and that account runs the two calls you reviewed: the exact allowance, then the rule.

State before and after, from the 2026-08-07 run:

If the memo does not commit to that pre-image, the mint reverts. The executor is a courier: it can delay your payment, not change it.

Somebody has to execute the arming, and today it is us

The public Coston2 executor did not pick up either of our arming payments, at 600 seconds each. One offered it nothing, which explains itself. The other offered the full 100,000 UBA delivery fee and was still ignored, because the public executor does not act on the 0xFE Smart Accounts branch that Trimmy uses. Measured, not assumed, so Trimmy runs its own executor for this step.

The executor is run against your transaction id. Nothing in the repository watches the XRP Ledger for arming payments on its own.

On the other branch the same executor minted 30 of 30 payments carrying a full fee, median 131 seconds. That is the closest thing to a normal expectation, and it is not our branch.

Until an executor acts, your payment sits at the Core Vault. It does not fail, and nothing happens. One of our early payments, which carried a zero fee, is still sitting there.

Then the rule waits, and anyone can run it

The rule is now on chain and execute() is permissionless. The contract re-derives every bound at execution time from the stored rule and a fresh oracle read, so the caller is trusted with nothing and appears once, as the recipient of the flat fee the rule carries: 9,400 units of the result asset per run by default, against a measured minimum viable fee of about 4,698 units at 383,451 gas. You never pay gas.

Demonstrated with a keeper identity that is neither the user nor the deployer: it started with zero, found the rule, executed it, and ended with exactly the 9,400 it was owed. The proceeds went to the rule's account, not the caller's.

Timing: our keeper sweeps every 15 seconds by default, and the floor is one block, 1 to 3 seconds measured. It reads the same feed the contract re-checks, so it has no information advantage. A price move shorter than one block cannot be caught, and near a threshold the feed oscillates across it, so failed attempts are ordinary. Call it one-block conditional execution against the FTSO with an oracle-enforced floor. It is not stop-loss protection.

A scheduled rule is eligible the moment it is armed: the first run happens as soon as somebody runs it, and the interval governs the gap after that. A private rule needs its threshold provisioned to the enclave first, and the enclave's operator can decline to issue a verdict, which is why that trigger is the weakest of the four. See Rule types.

Nobody is on call, including you

After the payment there is nothing to keep open. The rule ends on its own: when its budget is spent, when it expires, or when you cancel it. Cancelling one rule, or every rule at once with the epoch bump, is a Flare transaction; from XRPL it costs another payment and the same wait, so set the expiry you want when you arm.

All of this is Coston2 testnet. Nothing has run on Flare mainnet.