Why a cascade pays no one

A cascade can fire and credit nobody. When that happens it is almost always because the bound collaborator group cannot give the cascade any layers to walk. Siren handles that case by failing closed. It emits no credits, returns an empty result, and in some cases logs the reason. This page explains why that happens and gives you a checklist to follow when a cascade pays no one.

Fail closed means no credits, not a fallback

When a cascade cannot do its job, it returns nothing. It does not quietly switch to Fixed and credit the triggering collaborator instead. There is no Fixed fallback at runtime. Every path that cannot produce a valid cascade returns an empty set of credits, so the trigger results in zero engagement or metric rows from that calculation.

This is deliberate. A cascade that cannot walk a chain has no defensible answer for who to pay, so it pays no one rather than guessing. The cost is that a misbound cascade is silent. The work to find out why is on this page.

The picker filter and runtime fail-closed are two different things

There are two separate guards, and they do not do the same job.

The picker filter is a frontend convenience. On the Programs Edit and Distributors Edit screens, the calculation picker hides cascade options when the bound collaborator group cannot provide layers. A flat group provides no layered walker, so the picker does not offer Upline Cascade or Downline Cascade while a flat group is bound. This is a presentation filter only. It keeps you from selecting an option that could not work. See Why some calculation methods disappear for how that matching works.

Runtime fail-closed is the actual safety net. The picker hides the option in the UI, but it does not rewrite a calculation that is already saved, and the API does not coerce a cascade into anything else. If a program or distributor ends up with a cascade calculation bound to a group that cannot supply layers, the calculation still runs when a trigger fires. At that point it fails closed and emits no credits. So a cascade can pay no one even though the picker would never have offered it, because the picker only governs what you can pick today, not what is already stored.

What causes a cascade to emit nothing

Every case below makes the cascade return an empty set of credits. The triggering collaborator is never credited by a cascade, so failing closed means nobody is paid by that calculation for that trigger.

The bound group is flat or lacks a layered walker

A cascade needs a layered walker to know who sits at each layer. A flat group does not provide one. Its directional walkers are empty, so the cascade walks nothing and returns no credits. This is the most common cause.

A flat group fails quietly. Because its walker is empty, the cascade simply has nothing to iterate and returns an empty set without logging. A custom or hierarchical structure that yields walker steps without layer information is treated as a misconfiguration. In that case the cascade returns no credits and logs a RuntimeException so the silent no-op is traceable. Either way the result is the same: no credits.

The group is deleted or unbound

A cascade reads which group is bound from the program config (engagement side) or the distributor config (metric side). Several states here produce no credits:

• No group is bound at all (the binding is absent or zero). The cascade returns nothing.
• The binding points at a group that has since been deleted. The lookup fails and the cascade returns nothing.
• The bound group’s structure resolver cannot be found. The cascade returns nothing.

The triggering collaborator is not a member of the bound group

A cascade walks the chain starting from the triggering collaborator’s position inside the bound group. If the collaborator who fired the trigger is not a member of that group, there is no position to start from, so the cascade returns no credits.

The triggering collaborator is at the end of the chain

A cascade walks away from the triggering collaborator, so it needs someone on the side it walks toward. An Upline Cascade started by the collaborator at the top of the chain has no one above to credit. A Downline Cascade started by the collaborator at the very bottom has no one below. The triggering collaborator is a valid member with valid layers, but there is no one in the walked direction, and the cascade never credits the collaborator who fired the trigger, so the result is empty. A sale or metric from the person at the end of the chain pays no one.

Layer 1 is set to 0 or unset

Per-layer scores are read from pointsAtLayer1 through pointsAtLayer5. A value of 0 or less at a layer terminates the cascade at that point, so only pointsAtLayer1 can empty the whole cascade. If pointsAtLayer1 is 0 or unset, the cascade stops before it credits anyone and pays nobody. A 0 at a later layer is not a failure. It stops the cascade there and the layers before it are still paid, which is how operators signal “no further layers”. If you meant the cascade to pay and it pays no one, check that layer 1 has a positive value.

Checklist when a cascade pays no one

Work through these in order. Each one maps to a cause above. The checklist assumes the trigger fired and the cascade ran. If you are not sure the underlying event happened at all, the sale or metric that should start the cascade, confirm that first, because a cascade only pays out when something triggers it.

1. Confirm a group is actually bound. Open the program (or distributor) and check that a collaborator group is bound to it. An unbound calculation emits nothing.
2. Confirm the bound group still exists. If the group was deleted after it was bound, the binding points at nothing and the cascade returns no credits.
3. Check the group’s structure. A flat group cannot supply layers, so a cascade bound to it pays no one. Switch the group to a linear chain or parent-child structure, or bind a group that already uses one. The create a collaborator group guide covers where the structure is set.
4. Confirm the triggering collaborator is a member of the bound group. If the person who fired the trigger is not in the group, the cascade has no position to start from.
5. Confirm there is someone in the direction the cascade walks. An Upline Cascade needs at least one collaborator ranked above the one who fired the trigger, and a Downline Cascade needs at least one below. A trigger from the end of the chain leaves the cascade no one to credit.
6. Check the per-layer values. Make sure pointsAtLayer1 is a positive integer. A 0 or unset layer 1 stops the cascade before it credits anyone. Confirm that the layers you intend to pay are above 0 and that any 0 is where you actually want the cascade to stop.
7. Check the active status of the peers. A cascade skips inactive peers without consuming the layer slot, so if every peer along the walk is inactive, the cascade can finish having credited no one even though it ran correctly.

If you reach the end of the list and the calculation is still bound to a hierarchical group with a member trigger and positive layers, check your server log for a RuntimeException mentioning a walker step without layer information. That points at a structure that yields walker steps the cascade cannot read, which is a misconfiguration of the structure rather than of the calculation.

For the underlying mechanics, see Upline Cascade and Downline Cascade. For how the picker decides which calculations to offer, see Why some calculation methods disappear.