All pages

Using Trimmy

Arming a rule

Step by step: check your XRPL address offline, choose the rule, read the independent decode, then send one XRPL payment carrying three fields.

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.

Trimmy is live on Flare Coston2 testnet only. Nothing has run on Flare mainnet. The XRP you send is testnet XRP and is worth nothing.

You need an XRPL testnet address, its wallet, and testnet XRP. No EVM wallet, no FLR, no extension. That is not new: Smart Accounts already lets an XRPL payment drive a contract call with no gas token, and Trimmy is built on it. What this payment buys is a rule that stays armed afterwards.

1. Open the arming page

Open trimmy.xyz/arm over https, or localhost if you run it yourself. On plain http it disables its address field: step 2 needs crypto.subtle, which browsers give only to secure origins, and a page that stopped checking quietly would be worse than one that refuses.

2. Enter your XRPL address

Paste it, then press "Look up my account". Your browser verifies the address's four-byte base58check checksum offline, before any network call. Only then does the page ask Flare, read-only, which account that address controls.

A mistyped address cannot be caught on Flare

MasterAccountController.getPersonalAccount derives an address from any string. It is not a lookup, and it never fails. Measured on Coston2:

String handed to the contract Address returned
rDE4JUm2jaue31VwidRXWuWzf5dQkUxcsB 0x07a76b5c…, the real account
rDE4JUm2jaue31VwidRXWuWzf5dQkUxcsA, one character changed 0x6085dbe8…

A typo therefore does not error. It resolves to a different Flare account, and a payment armed against it sets an allowance and creates a rule on an account you do not control. It cannot be recalled or refunded, so nothing recovers it.

The checksum your address already carries is the only place this is detectable, and before you send is the only time. Hence the browser check, whose test mutates every character of a real address into every other character of the XRPL alphabet, 1,900+ variants, and accepts none. Copy your address from your wallet rather than retyping it.

3. Choose the rule

Pick a preset, then set the amount each time, how many times, how often or at what price, and the expiry. Rule types covers what each one does and does not do.

Other bounds are fixed in the contract, with no setter: the pair and venue are set at deploy time, a sale must land within 50 basis points of the oracle price, schedules cannot run faster than every 60 seconds, and no rule lives past 365 days.

So what you sign is a bounded mandate: an exact allowance rather than an unlimited one, one verb, one venue, one token pair, a hard budget, an expiry, and a cancel-all. An agent can compose a rule inside that boundary and cannot exceed it, and it cannot reach your account another way: PersonalAccount.executeUserOp is onlyController, measured.

4. Read what you would be authorising

Press "Build the payment" and read the panel stamped "Memo verified" or "Do not send".

A 42-byte memo decides the whole outcome on Flare, and nobody reads it by eye. The page could restate the form you filled in, which would look identical and prove nothing: an encoder bug would be echoed back word for word. Instead a separate decoder reads the bytes it built, re-derives the commitment, and describes what it finds, reading nothing from the form. It refuses the payment if the memo does not commit to the batch, if the spender is not Trimmy, or if a selector is unrecognised.

5. Send the payment

From any XRPL wallet, send one payment with three fields:

Destination : rDhpmiPq4BVBDWMVdSrmkgt8thKyRzGV1p
Amount      : the XRP figure the page shows
Memo        : MemoData = the 84 hex characters the page shows

Do not add a destination tag. A registered tag overrides the memo entirely and credits the tag holder: the payment goes to a stranger and no rule exists.

For twelve runs of 0.01 XRP:

Component Amount
What the rule can spend 0.12 XRP
Minting fee, taken by FAssets 0.10 XRP
Delivery fee, paid to the executor 0.10 XRP
Total 0.32 XRP

The minting fee is 0.25% with a 0.1 XRP minimum, so the minimum applies here. The delivery fee is read live, because governance can change it. Unspent budget stays in your account.

Never send less than the figure shown. Anything from 0.1 to 0.2 XRP inclusive delivers you exactly zero, with no revert and no event, and the XRP is gone. The floor is 0.2 XRP and one drop.

One-tap signing is not built

You copy three fields by hand. Xaman's hex deep link carries TrustSet transactions only, so it cannot carry a Payment with Memos. A memo-bearing request needs Xaman's Platform API and a server-held key, which a static page cannot have. It is missing, not faked.

If you chose a private rule

The payment carries no threshold price and cannot: anything in it sits on a public ledger forever. Arming sets triggerValue = 0. It fires only once you run the command the page gives you, which encrypts your price to the enclave and commits a hash of it. This trust model is weaker than the other three: it needs one enclave running, and that operator can censor it by declining to act. It is not trustless.

Next: What happens after you arm.

Source on GitHub Read this page as markdown: /docs/arming/index.md