Safe by Construction, Not by Contract

Safe by construction = a rule the network enforces on every transaction, not a rule a party has agreed to follow

Most financial protections are the second kind. A processor holds your instruction and a contract that says what it must do with it. The contract can make departing from that instruction expensive and clearly wrongful. It does not make departing from it impossible. Somewhere in the chain there is a party who could, in principle, decline to follow the instruction or freeze the account it sits in.

We wrote before about testing that gap on Keeta's test network, where a carrier's own account, with delegated spending rights granted to the protocol, remained a carrier's own account. Revoke the grant and the recovery that worked a moment earlier is refused, no notice required. That post covered the testnet result. This one covers the architecture question underneath it, and where that question is still open.

What a storage account actually removes

A Keeta storage account has no signing key of its own. It cannot authorise anything, because there is nothing to sign with. Instead, exactly one address holds the OWNER permission over it at any time, and Keeta enforces that as a network invariant rather than a policy: one owner, transfer only atomic. Whoever holds OWNER controls withdrawal. Nobody else can grant themselves that role, because granting a permission is itself an action that requires already holding the authority to grant it.

A party given only STORAGE_DEPOSIT against that account can pay funds in. That is the entire set of things it can do. It cannot withdraw, cannot revoke the owner's authority, cannot grant itself anything further. This was the proposition tested on testnet, eleven operations run against it, eleven refused or behaved exactly as expected. The result was not the protocol declining to misuse an authority it held. It was the ledger refusing an action nobody in that role was ever able to take.

That is the distinction the title is pointing at. A processor mandate is a rule a party has agreed to follow, backed by consequences for breaking it. A storage account with the wrong permission set is a destination where the action in question is not on the menu.

The part that is a configuration choice, not a guarantee

Here is where it gets less tidy. Keeta's own documentation describes a bank or anchor generating a storage account for a customer at onboarding, using that customer's own public key. Ownership at creation is set by whoever generates the account. It is not fixed by the protocol itself. The architecture enforces the rule once an owner is set. It has nothing to say about who that owner should be, and getting that assignment wrong would recreate the exact problem the storage account was built to avoid.

KYC on the network is designed separately from account ownership, which helps here but does not close the gap on its own. It works as a portable, cryptographically signed certificate, shared between KYC Anchors and Fiat Anchors, rather than being bound to whichever address happens to hold OWNER. In principle that separation lets a KYC'd counterparty exist independently of who controls a given account. In practice it still leaves the question of whether an anchor can generate an account under a public key that belongs to SukukFi rather than to the KYC'd customer, and credit it on that customer's behalf.

We asked Keeta's own team that question directly, on their Telegram, on 31 August 2026. The answer was straightforward about what the network does and honest about what it does not yet cover: on-chain permissions work exactly as documented once an account exists, but creating an account on behalf of another person or entity is, in their words, a gray area. Their expectation is that this will need an external legal agreement, and in the worst case a tri-party arrangement between SukukFi, the fiat anchor, and Keeta itself.

That question is not resolved. We are not going to describe it as though it were.

What this is and is not

This is an evaluation. Nothing here is deployed in production, and nothing in this post describes a live settlement path. What the testnet work shows is that the network-level protection is real once an account's ownership is correctly assigned, verifiable by anyone who wants to check the primitives rather than take a description of them on faith. What it does not yet show is a resolved answer to who is allowed to assign that ownership on a customer's behalf, and under what agreement.

We are not calling this insolvency-remote, or safe in any sense broader than the specific permission structure it demonstrates. It describes a mechanism, not a guarantee, and the mechanism still has an open corner. The traditional path, a processor mandate backed by drafting that makes departure costly, remains what SukukFi runs on today. This is the alternative we are testing, honestly, including the part that is not settled yet.

Read the testnet clawback test or explore the Keeta test network explorer.