Step By Step: Dependency

Layers are often maligned as the most complicated part of Magic. While mostly untrue, the one part of layers that can be difficult to grasp at an advanced level is the dependency system. I'd like to try and change that. If after reading this article you're still confused about some aspect of dependency, that means I haven't accomplished my goal; please let me know what you're confused about so that I can find a different/better way to explain it.

A brief note: This is a more advanced article intended for Magic players and judges who already have a strong grasp of the rules. If you don't yet know the basics of type-changing effects, layers, and timestamps, you'll probably find this article a bit confusing. I have an introduction to layers and timestamps here.

What is dependency?

Dependency exists to make the layer system more intuitive. If you were to always apply effects in a set order defined only by their timestamp and what layer they're in, you'd get a bunch of very weird results. Consider an example: You control Kwende, Pride of Femeref and Glory Seeker. You proceed to equip Glory Seeker with Chariot of Victory. What would happen here if dependency didn't exist? Well, we'd apply effects in timestamp order. First Kwende, doing nothing, then Chariot of Victory, giving it first strike. Glory Seeker ending up with first strike but not double strike is not the result that players would expect, and they'd find this very confusing. We want the game's rules to be intuitive to players; most of them are not going to be reading through the entire rulebook, so if someone takes a guess as to how something works, we'd like it if those guesses were usually correct. Dependency is an attempt at formalizing human intuition so that we can apply it consistently across all tournaments.

So how does it work? Continuous effects are worded as statements that are true, and that's how humans process them. If a card says "creatures you control have first strike", we'd expect that if a spectator wanders by and remarks "hey bro, creatures you control have first strike", they'd be correct. However, that's not always possible. If there's a card that says "creatures you control have base power and toughness 1/1" and another that says "creatures you control have base power and toughness 3/3", well, those can't both be true. So dependency tries to minimize the number of falsehoods. or to be more accurate, it tries to strike a balance between minimizing falsehoods while also keeping the system feasible to understand and calculate results for.

It does this by looking to see whether any effects "care about" the result of another effect, with a more formal definition of "care about". If so, the first effect waits to apply afterwards, so that both effects get to "do their thing" to the maximum extent possible. In these cases, we say that the first effect "depends on" the other.

Notably, this is a redefinition of the word "depends" for the purpose of having a technical term to use in the comprehensive rules. This can confuse people who are treating the word as having its normal English definition. In Magic terms, Urborg, Tomb of Yawgmoth is dependent on Blood Moon because Blood Moon removes its abilities, but this is not how the word is normally used; if we're not talking about Magic and we say that Alice depends on Bob, we wouldn't expect that to mean that Bob is trying to kill her! (You could rephrase this to "Alice's existence depends on Bob's actions", which makes a little more sense.) So any time you're considering dependency in Magic, don't get tripped up on what the word means in normal English. Just like how in mathematics "prime numbers" doesn't mean "the best numbers", in Magic "depends on" is a technical term with a specific definition.Though let's be real, prime numbers are pretty great.

So how do we handle dependencies on a technical level? There are two challenges we must overcome:

Determining a dependency

The rules have the following to say about what constitutes a dependency:

An effect is said to “depend on” another if (a) it’s applied in the same layer (and, if applicable, sublayer) as the other effect; (b) applying the other would change the text or the existence of the first effect, what it applies to, or what it does to any of the things it applies to; and (c) neither effect is from a characteristic-defining ability or both effects are from characteristic-defining abilities. Otherwise, the effect is considered to be independent of the other effect

(a) and (c) are trivial, so let's focus on (b). There are 4 criteria listed in (b), and satisfying any one of them means that there's a dependency. Let's go over them one at a time:

"applying the other would change the text"

There are no existing cards that can cause a dependency under this lineAt least, I think there aren't. With over 24,000 different Magic cards in existence, it's difficult to be certain of claims like "X is impossible". I spent several hours researching what types of dependencies can be caused by existing cards, but I could have missed something. Prove me wrong, if you can. :), so this part of the rule is just here in case it's needed for future cards.This rule should really be talking about the ability that creates the effect, since the text of an effect itself isn't a characteristic and can't be changed, but it's clear what this rule is trying to say even if it's technically inaccurate.

"or the existence of the first effect"

This is talking about situations where one effect makes another stop existing entirely. With existing cards, this can happen in layers 1, 3, 4, or 6. Layer 6 is the most common, since that's where you apply effects that remove abilities. Examples:

"what it applies to"

This is for when one effect is applying to a certain set of objects (such as "all creatures"), and another effect is adding or removing an object from that set (such as turning an artifact into a creature or a creature into a land).Note that we're checking whether this is actually happening, not just whether it "could happen" if different cards were on the battlefield to be affected. For example, if there's an effect that says "All Humans are Elephants" and another that says "All Elephants are Squid", the latter is only dependent on the former if there's actually a Human on the battlefield. With existing cards, this can only happen in layer 4 or 6. Examples:

"or what it does to any of the things it applies to."

This applies when one ability refers to some quality to determine its effect and the other ability changes that quality, therefore changing the result of the first ability. (For example, an effect that says "other creatures get +X/+X, where X is this creature's power" would be dependent on an effect that changes the creature's power, since that would change the buff it gives to other creatures.) It also applies when an ability can't do something and another ability would make it able to do that thing.

Unfortunately, this is quite vague. If two Trait Doctorings have targeted the same creature with protection from red, one changing "black to "green" and another changing "red" to "black", is there a dependency? It's unclear whether this counts as changing "what it does".Official Wizards sources have made inconsistent official rulings on this, sometimes ruling that it is a dependency and sometimes that it isn't.

There's also a bigger problem: According to this rule, an effect that says "target creature loses flying" is dependent on an effect that says "target creature gains flying", because a creature that doesn't have flying can't lose flying, so giving it flying would change what the first effect does from "nothing" to "loses flying". However, Wizards of the Coast has stated that this is not how they want this to work.It's actually one of the examples in the dependency section of the CR.

We can solve these problems by pretending that the rule says:

"what it attempts to do to any of the things it applies to".

In other words, we consider what the effect itself says to do, but not how that will affect individual objects or players. This change makes neither example a dependency anymore, and is consistent with the official rulings Wizards has made on the subject.

Under this interpretation, this line can cause a dependency with existing cards in layers 2, 6, or 7. It can happen in layer 2 because taking control of one object can change what player the word "you" in that object's abilities refers to, and in the others because some variable in the ability is being changed by some other effect.


So, those are the 4 ways for one effect to be dependent on another. In a non-technical sense, there's a dependency if effect A "does something" to effect B. The 4 categories above are an attempt to comprehensively define what "does something to" means for every possible pair of effects.

In other words, apply effect A. See what it does. Now undo that and apply effect B, followed by effect A. See what effect A does now. If what it does in the second case is different from the first case (or it doesn't exist at all anymore), it's dependent on effect B.This is not the same as checking if the result is different! We're checking what the effects themselves do, not what the resulting game state looks like. Switching the order of application of Blood Moon and Prismatic Omen results in large changes to the game state, but no changes to the abilities themselves, so there is no dependency.

For some number of effects, the number of possible dependencies is the number of possible ordered pairs of effects. For example, with 2 effects A and B, there are two possible dependencies: A dependent on B, or B dependent on A. With 3 effects, there are 6 possible dependencies. (A dependent on B or C, B dependent on A or C, and C dependent on A or B.) With 4 effects, 12. Etc.With N effects, the number of possible dependencies is N * (N-1).

Once you've gone through the list of ordered pairs and you know which ones actually have a dependency, you're ready to move on the the next step: figuring out what order to apply the effects in.

Ordering effects

Now that we know which pairs of effects have a dependency, we just need to figure out what order to apply them in. Notably, while we're going through the dependencies to figure out which effect to apply first, that process depends only on their timestamps and dependencies, nothing else. This means that we can make it much easier to think about the process by ignoring what the cards actually do, and simply keeping a list of those timestamps and dependencies. For the purposes of the next few sections, I'll refer to effects by a letter, like "effect A", and "effect B", with earlier letters in the alphabet denoting earlier timestamps. I'll refer to a dependency like "A>B", meaning that effect A is dependent on effect B.

The rules tell us to modify timestamp order within a layer in the following way:

An effect dependent on one or more other effects waits to apply until just after all of those effects have been applied. If multiple dependent effects would apply simultaneously in this way, they're applied in timestamp order relative to each other. If several dependent effects form a dependency loop, then this rule is ignored and the effects in the dependency loop are applied in timestamp order.

This is pretty good, but there's one ambiguity: What does it mean to "ignore this rule"?

Obviously, if we take it literally, it makes no sense. Saying "ignore this rule" is like saying "this sentence is false"; it's a paradox. What it probably means to say is something like "If several dependent effects form a dependency loop, the previous two sentences do not apply to those effects." But that's still ambiguous, since we need to know how effects in a loop interact with effects that aren't in that loop.

For example, consider three effects: A, B, and C, with dependencies A>C and C>A. A and C form a dependency loop. What order do these effects get applied in? What if A has a separate dependency on B? The CR doesn't answer any of these questions, and Wizards has not clarified the ambiguity. Since we need an answer in order to know how to process nearly any dependency situation that includes a loop, I'm going to infer that it's probably supposed to work as though it said this:

If several dependent effects form one or more dependency loops, all dependencies in those loops are ignored.

We can't be sure that this is what Wizards intends, but this the simplest system for handling it. (Presumably Wizards wants humans to actually be able to calculate the results on their own.) If anyone can get Wizards to give us an actual answer then I'll update the article, but for now we'll have to use this. Continuing on:

After each effect is applied, the order of remaining effects is reevaluated and may change if an effect that has not yet been applied becomes dependent on or independent of one or more other effects that have not yet been applied.

This is just telling us to perform the same process after applying each effect, rather than rely on the order we determined previously. For example, consider three effects: A, B, and C, with A dependent on C. We apply B first, but let's say that whatever B did made the A>C dependency stop existing. This rule tells us that we don't "remember" that dependency now that it's gone, and we apply A next. It's more obvious why this is necessary when you consider that applying one effect could make another one stop existing entirely, so we certainly need to remove that effect from the list, and it wouldn't make sense to keep its dependencies around either.

So, what's the actual process for applying effects? Let's go though it one step at a time.And we are of course assuming that all of these effects are applied in the same layer and sublayer, since dependencies don't cross between different layers.

Step 1: Write out the effects in timestamp order:

  1. Effect A
  2. Effect B
  3. Effect C

Step 2: Find the first effect on the list that isn't dependent on anything else. (Ignoring any dependencies involved in any loops.) Let's say that effect A is dependent on effect B, so the first effect on the list that isn't dependent on anything else is effect B.

Step 3: Apply that effect, changing the characteristics of objects in the game as appropriate.

Step 4: We make a new list of effects that still need to be applied, and start over from step 1 with the new list.

Once there are no more effects left to apply, you're done!

Here's the exact step-by-step process:

  1. Create a list of effects that have not yet been applied, and a list of their dependencies.
  2. Check to see whether their dependencies create any loops. If so, remove all of those dependencies from the list.
  3. Put the list of effects in timestamp order.
  4. Find the first effect on the list that isn't dependent on anything else.
  5. Apply that effect.
  6. Go back to step 1.And you really do need to make a new list, not just reuse the old one. The effect you just applied might have caused other effects to stop existing or have new dependencies.


Everything is better with graphs

It turns out that there's a visual way to think about this process as well: Just use a directed graph!

  1. Create a vertex to represent each effect.
  2. For each dependency, create an edge that leads from the dependent vertex to the one it's dependent on.
  3. Remove all edges that are part of any cycles.
  4. Find all vertices that have no outgoing edges.
  5. Among those, the one with the earliest timestamp is the one to be applied.
  6. After applying it, start over from step 1 with a new graph to represent whatever effects now need to be applied.

Let's take a look at another example. We have 5 effects, with dependencies A>B, A>D, B>C, B>D, C>A, D>E, and E>D. Handling these via the list method would be a pain, but as a graph it's quite simple:

It's easy to see that there are two loops here, so we remove those edges:

The three vertices with no outgoing edges (which means they're not dependent on anything) are C, D, and E. C has the earliest timestamp, so that's the one we apply.


Dependency calculator

Here's a simple program that can tell you which effect should be applied next.Code from CSAcademy. Enter dependencies in the form "A>B", each on its own line. You can also enter a single letter or word to represent an effect with no dependencies. If you use single letters, timestamps are in alphabetical order. Otherwise they're in the order of entry. (For example, if you enter "Blood Moon", "C", "Ashaya", "A", timestamp order will be "A", "C", "Blood Moon", "Ashaya".)

There's also a much more elaborate simulator here. It doesn't seem to handle some of the more complicated dependencies quite right, but overall it's very impressive and I'd recommend playing around with it to get a feel for how dependencies work in a real-life situation.


Practice questions

For all of these questions, the timestamp order of objects/effects is the order they're mentioned in. Assume that that there are no permanents on the battlefield other than the ones mentioned. For each question, remember the process: First determine what dependencies exist, without worrying about putting them in order. Then once you know what all the dependencies are, figure out what effect is the next to be applied. Then start over from the beginning with the remaining effects. Most importantly, don't just skim through the questions! Try to figure out the answer on your own, and then check how you did. If you're consistently arriving at wrong answers, that means you've probably misunderstood something important.

Question #1

You control Conversion, Blood Moon, and Watery Grave. What land type is the Watery Grave?

Plains. Applying Blood Moon would change what Conversion applies to (since it would make Watery Grave a Mountain, allowing Conversion to apply to it), so Conversion is dependent on Blood Moon. Applying Conversion would not change what Blood Moon applies to (since it just applies to all nonbasic lands regardless of their land type), so Blood Moon is not dependent on Conversion. We therefore apply Blood Moon first, turning Watery Grave into a Mountain, then Conversion, turning it into a Plains.

Question #2

You control Conversion, Blood Moon, and Stomping Ground. What land type is the Stomping Ground?

Mountain. Applying Blood Moon would not change what Conversion applies to (since Stomping Ground is already a Mountain), so Conversion is not dependent on Blood Moon. Applying Conversion would not change what Blood Moon applies to, so Blood Moon is not dependent on Conversion. We therefore apply them in timestamp order, with Conversion first, turning Stomping Ground into a Plains, then Blood Moon, turning it into a Mountain.

Question #3

You control Conversion, Blood Moon, Watery Grave, and Stomping Ground. What land types are the Watery Grave and Stomping Ground?

Both Plains. Applying Blood Moon would change what Conversion applies to (by turning Watery Grave into a Mountain), so Conversion is dependent on Blood Moon. Applying Conversion would not change what Blood Moon applies to, so Blood Moon is not dependent on Conversion. Applying Blood Moon turns them both into Mountains, then Conversion turns them both into Plains.This is an example of what I mentioned earlier; when considering when a dependency exists, we take into account only the cards that are actually on the battlefield, not any cards that could possibly be on the battlefield. As a result, the land type of Stomping Ground can change when you play a Watery Grave, even if nothing changed about the effects themselves.Yes, this is weird.

Question #4

You control Blood Moon, Watery Grave, and Prismatic Omen. What land type(s) is the Watery Grave?

All basic land types. Blood Moon and Prismatic Omen would both apply to the Watery Grave regardless, so neither is dependent on the other. We apply them in timestamp order.

Question #5

Some Mind Bend shenanigans have occurred. You control a Conversion with its normal text of "All Mountains are Plains", a Conversion that says "All Forests are Mountains", and a third Conversion that says "All Swamps are Forests". You also control a Watery Grave. What's its land type?

Mountain. The first effect in timestamp order is "All Mountains are Plains". It's not dependent on either other effect, so it gets applied first. Then we look at "All Forests are Mountains" and see that it's dependent on "All Swamps are Forests", since the latter would turn Watery Grave into a Forest and allow the former to apply to it. So "All Swamps are Forests" gets applied next, and finally "All Forests are Mountains".

Question #6

Mind Bend continues to wreak havoc. You control a Conversion that says "All Plains are Swamps", one that says "All Mountains are Plains", and one that says "All Swamps are Mountains". You also control a Watery Grave. What's its land type?

Plains. There's only one dependency here:

So we apply "All Plains are Swamps" first. It doesn't do anythingNot to be confused with doing nothing., so we apply "All Swamps are Mountains" next, then "All Mountains are Plains".


Question #7

You control a Conversion that says "All Islands are Swamps", one that says "All Mountains are Islands", and one that says "All Swamps are Mountains". You also control a Watery Grave. What's its land type?

Swamp. Applying "All Swamps are Mountains" would cause Watery Grave to stop being an Island, so "All Islands are Swamps" is dependent on it. We therefore have two dependencies:

After applying "All Swamps are Mountains", Watery Grave is a Mountain, and we check our dependencies again:

Since "All Islands are Swamps" is now dependent on "All Mountains are Islands", the latter gets applied first, making Watery Grave an Island, and then finally effect A turns it into a Swamp.

Question #8

You decide to change things up a bit. You control a Glaciers that says "All Islands are Swamps", one that says "All Mountains are Islands", and one that says "All Swamps are Mountains". You also control a Watery Grave and a Stomping Ground. What are their land types?

They're both Swamps. We have three dependencies:

We apply C first, making Watery Grave into a Mountain. We check our dependencies again and see that A is dependent on B, so we apply B next, then A.

Question #9

You control a Glaciers that says "All Mountains are Islands", one that says "All Islands are Swamps", and one that says "All Swamps are Mountains". You also control a Watery Grave and a Steam Vents. What are their land types?

They're both Islands. There are 4 dependencies:

There's a loop, so we remove those edges:

We apply B first, turning both lands into Swamps. We check dependencies again and see that "All Mountains are Islands" is still dependent on "All Swamps are Mountains", but not vice versa, so they get turned into Mountains, and then Islands.

Question #10

You control Goblin Arsonist, a Dralnu's Crusade that's had its text changed to "All Zombies are green and are Elves in addition to their other creature types.", and a regular Dralnu's Crusade. What does the Goblin look like?

It's a 3/3 black Goblin Shaman Zombie Elf.

In layer 4, the edited Dralnu's Crusade is dependent on the regular one, so it's applied second. Goblin Arsonist becomes a Goblin Shaman Zombie, then it becomes a Goblin Shaman Zombie Elf.

In layer 5 there are no dependencies, so the effects are applied in timestamp order. Goblin Arsonist becomes green, then black.

Question #11

You control 3 Minimus Containment that are all enchanting each other in a loop. Timestamp order is A, B C, with A enchanting B, B enchanting C, and C enchanting A. What does each one look like?

They're all Artifact - Treasures that can tap for mana and have no other types or abilities.

In layer 4 there are no dependencies, and they all become Artifact - Treasures.

In layer 6 there are no dependenciesNot that this matters; the result would be the same regardless of any dependencies., and they all gain the ability to tap for mana and lose all other abilities. (They're not Auras anymore, but 303.4m tells us that they can still affect whatever they're attached to. 613.6 makes it so that all three effects get applied, even if the Minimus Containment generating the effect has lost the ability by then.)

When state-based actions are checked, they're not Auras, so they'll become unattached from each other and stop being treasures. Then state-based actions are checked again, at which point they're now unattached Auras and will die.

Question #12

You control Opalescence, Dralnu's Crusade, a Conspiracy naming "Goblin", and another Conspiracy naming "Goblin". What types and subtypes does everything have?

All enchantments except Opalescence are "Enchantment Creature - Goblin".

Opalescence isn't dependent on anything, so it's applied first. Now Dralnu's Crusade is dependent on both Conspiracies, since they'd allow it to apply to the three creatures on the battlefield, so we apply the first Conspiracy. Now all 3 creatures are Goblins, so Dralnu's Crusade is no longer dependent on the second Conspiracy. We apply Dralnu's Crusade next, and finally the second Conspiracy.

Question #13

You control Life and Limb, Amoeboid Changeling making itself a Saproling, Blood Moon, 1 Saproling token, and 1 Stomping Ground. What do things look like?

All creatures and lands are Mountain Saprolings.

Life and Limb and Blood Moon are dependent on each other, and Life and Limb is also dependent on Amoeboid Changeling.

We ignore the loop and therefore apply Amoeboid Changeling first. There's still a loop, which we still ignore, so we apply Life and Limb next, making everything into Forest Saprolings. Last we apply BLood Moon, making them into Mountain Saprolings.

Question #14

You control Life and Limb, a Taiga enchanted by Living Terrain (which has had its text changed to replace "Treefolk" with "Saproling"), and Conversion. What does the Taiga look like?

It's a 5/6 green Land Creature - Plains Saproling.

In layer 4, Life and Limb is dependent on Conversion, since Conversion would make the Taiga stop being a Forest and prevent Life and Limb from applying to it. There are no other dependencies, so we apply Living Terrain first, making it a Saproling. Now Life and Limb is no longer dependent on Conversion, since Taiga would be a Saproling regardless. So we apply Life and Limb next, which does nothing since the Taiga is already a Forest and a Saproling. Last we apply Conversion, changing it from a Mountain to a Plains.

Then in layer 7 there are no dependencies, so we apply Life and Limb first, making it a 1/1, which is then overwritten by Living Terrain.

Question #15

You control Dryad of the Ilysian Grove, Ashaya, Soul of the Wild, Blood Moon, and a Swamp. What do they all look like?

Ashaya and Dryad are Mountain Land Creatures with no abilities other than to tap for red. The Swamp is still just a Swamp.

When we first check for dependencies, we see that both Blood Moon and Dryad are dependent on Ashaya, since applying Ashaya would create more lands for them to apply to. So we apply Ashaya first. After the creatures become Forests, we check for dependencies again. Now Dryad is dependent on Blood Moon, because it's a land and applying Blood Moon would remove its abilities. So Blood Moon is applied next, and Dryad never gets to apply.

Question #16

You control Xenograft naming "Zombie", Urborg, Tomb of Yawgmoth, and Kormus Bell. What does Urborg look like?

It's a 1/1 creature with no creature types.

In layer 4, the only dependency is Kormus Bell on Urborg, so we apply Xenograft first, not doing anything. Then we apply Urborg, making itself a Swamp, and then Kormus Bell making it a creature.

Question #17

You control Ashaya, Opalescence, a Conversion that says "All Swamps are Plains", a Conversion that says "All Plains are Swamps", and Blood Moon. You've also used Navigator's Compass to turn the first Conversion and Blood Moon into Plains, and the second Conversion into a Swamp. After this you turn the Conversions and Blood Moon face-down and then face-up again. What does everything look like?

Don't panic! It's gonna be ok.

Turning the enchantments face down and face up gives them a new timestamp, so the timestamp order of our effect is:

Neither Ashaya nor Opalescence are dependent on any of the other 6 effects, so we don't need to worry about what dependencies may exist between them. Ashaya is dependent on Opalescence, so we apply Opalescence first. This doesn't cause Ashaya to become dependent on anything new, so we apply Ashaya next, turning the three creature enchantments into Forests. Next come the Navigator's Compass effects, and since they're not being generated by a static ability, they can't be dependent on anything.611.2c and 611.2d along with our interpretation of "what it does to any of the things it applies to" make it impossible for a continuous effect generated by the resolution of a spell or ability to ever be dependent on any other effect. We apply those next. Now we just have the Conversions and Blood Moon left, and here's where we have to start paying attention.

They're all nonbasic Forests. Conversion #1 and Blood Moon are also Plains, while Conversion #2 is also a Swamp. Applying Blood Moon would remove the abilities of both Conversions, so they're both dependent on Blood Moon. The two Conversions are also dependent on each other, since they'd each remove the abilities of the other. Lastly, the Blood Moon is dependent on Conversion #2, since it would turn Blood Moon into a Swamp. But it's not dependent on Conversion #1. So our dependency graph looks like this:

We ignore any dependencies that are involved in loops, which is all of them, so we apply Conversion #1.This is, by the way, an example of the ambiguity we talked about earlier in the rule "If several dependent effects form a dependency loop, then this rule is ignored and the effects in the dependency loop are applied in timestamp order". If rather than ignore all loops simultaneously you were to ignore loops one by one, you'd either end up applying Conversion #2 or Blood Moon first, depending on whether you first remove the 3-effect loop or the two 2-effect loops. This turns Conversion #2 into a Swamp with no abilities, meaning the only effect left to apply is Blood Moon.

The end result is that Ashaya and all 3 enchantments are Mountains with no other land subtypes and no abilities.


For more dependency practice, see here.


Thanks to Pi Fisher for proofreading and suggestions, to Todd Bussey for noticing that I was missing the Necrotic Ooze + Yixlid Jailer dependency, and to Laurie Cheers for cluing me in to the Exchange of Words + Volrath's Shapeshifter dependency. Any errors are my own.

RSS feed