Visualize

Draw a group and the groups under it, and see what that comes to on the chain: the conditions a spend has to meet, and the taproot output they are folded into.

The structure

Build the shape of a group's wallets — the group, the groups under it, the wallets it guards for its members — and see what the chain is asked to enforce for any one of them.

What this does not model. A policy on a page is not a group that works, and a tree that draws is not the whole of one address. Seven of Bennu's rules are nowhere in what you see above, and each is kept somewhere else:

• The ceremony. The tree says 3 of 5 sign. It does not say that every member has to take part to make the key in the first place, which is the step a group actually gets stuck on.
• The birth certificate. A subgroup's parentage is a statement its parent's quorum signed, not a script. Nothing on-chain checks it; every honest client does.
• The derivation. Real addresses come off BIP86's unhardened tail under a public account step tweaked from the group's key. The simulator names a key and stops there.
• The cap. Bennu will not propose more than 100,000 sats in one spend on mainnet. That is a gate in the app, and the chain would happily take more.
• One address. The internal key is account(K, network, n)/change/index, so every address has its own tree, with its own leaves and its own root. The drawing shows one of them.
• The leaf keys. A guardian's key is derived one step further per child, so the same group's leaf is a different key in every descendant's tree. That is what makes a revealed leaf unlinkable to a group.
• The key path. P is a FROST threshold key that several members have to co-operate to use. The taproot tree can no more show that than the policy can — it is one key either way.