Return to Answer

DELEGATECALL can usually be a vulnerability to the "sending" contract, not the "receiving" contract. DELEGATECALL basically says that I'm a contract and I'm allowing you to do whatever you want to my storage: so it isn't really possible for me to use DELEGATECALL to change your storage.

When contract C does a DELEGATECALL to contract D, C is at the mercy of D. With DELEGATECALL, all of D's code manipulates the storage of C.

In hub-spoke contracts, a hub (master) performing a DELEGATECALL to spoke (servant) contracts is certainly vulnerable to spoke contracts manipulating the state of the hub. The attack surface could be large, and DELEGATECALL wasn't intended as a way to allow arbitrary untrusted code (spokes) to manipulate "shared" state (hub): it may help to explore this more with some specific examples. A contract or "library" usually only has a single, active contract it delegates to at a time.

A spoke contract S that uses DELEGATECALL to another spoke contract T, is at the mercy of T, rather than attacking T (just like the example with C and D).

DELEGATECALL can usually be a vulnerability to the "sending" contract, not the "receiving" contract. DELEGATECALL basically says that I'm a contract and I'm allowing you to do whatever you want to my storage: so it isn't really possible for me to use DELEGATECALL to change your storage.

When contract C does a DELEGATECALL to contract D, C is at the mercy of D. With DELEGATECALL, all of D's code manipulates the storage of C.

In hub-spoke contracts, a hub (master) performing a DELEGATECALL to spoke (servant) contracts is certainly vulnerable to spoke contracts manipulating the state of the hub. The attack surface could be large, and DELEGATECALL wasn't intended as a way to allow arbitrary untrusted code (spokes) to manipulate "shared" state (hub): it may help to explore this more with some specific examples. A contract or "library" usually only has a single, active contract it delegates to at a time.

A spoke contract S that uses DELEGATECALL to another spoke contract T, is at the mercy of T, rather than attacking T (just like the example with C and D).

DELEGATECALL can usually be a vulnerability to the "sending" contract, not the "receiving" contract. DELEGATECALL basically says that I'm a contract and I'm allowing you to do whatever you want to my storage: so it isn't really possible for me to use DELEGATECALL to change your storage.

When contract C does a DELEGATECALL to contract D, C is at the mercy of D. With DELEGATECALL, all of D's code manipulates the storage of C.

In hub-spoke contracts, a hub (master) performing a DELEGATECALL to spoke (servant) contracts is certainly vulnerable to spoke contracts manipulating the state of the hub. The attack surface could be large, and DELEGATECALL wasn't intended as a way to allow arbitrary untrusted code (spokes) to manipulate "shared" state (hub). It may help to explore this more with some specific examples.

A spoke contract S that uses DELEGATECALL to another spoke contract T, is at the mercy of T, rather than attacking T (just like the example with C and D).

DELEGATECALL can usually be a vulnerability to the "sending" contract, not the "receiving" contract. DELEGATECALL basically says that I'm a contract and I'm allowing you to do whatever you want to my storage: so it isn't really possible for me to use DELEGATECALL to change your storage.

When contract C does a DELEGATECALL to contract D, C is at the mercy of D. With DELEGATECALL, all of D's code manipulates the storage of C.

In hub-spoke contracts, a hub (master) performing a DELEGATECALL to spoke (servant) contracts is certainly vulnerable to spoke contracts manipulating the state of the hub. The attack surface could be large, and DELEGATECALL wasn't intended as a way to allow arbitrary untrusted code (spokes) to manipulate "shared" state (hub): it may help to explore this more with some specific examples. A contract or "library" usually only has a single, active contract it delegates to at a time.

A spoke contract S that uses DELEGATECALL to another spoke contract T, is at the mercy of T, rather than attacking T (just like the example with C and D).

DELEGATECALL can usually be a vulnerability to the "sending" contract, not the "receiving" contract. DELEGATECALL basically says that I'm a contract and I'm allowing you to do whatever you want to my storage: so it isn't really possible for me to use DELEGATECALL to change your storage.

When contract C does a DELEGATECALL to contract D, C is at the mercy of D. With DELEGATECALL, all of D's code manipulates the storage of C.

In hub-spoke contracts, a hub performing a DELEGATECALL to spoke contracts is certainly vulnerable to spoke contracts manipulating the state of the hub.

DELEGATECALL can usually be a vulnerability to the "sending" contract, not the "receiving" contract. DELEGATECALL basically says that I'm a contract and I'm allowing you to do whatever you want to my storage: so it isn't really possible for me to use DELEGATECALL to change your storage.

When contract C does a DELEGATECALL to contract D, C is at the mercy of D. With DELEGATECALL, all of D's code manipulates the storage of C.

In hub-spoke contracts, a hub (master) performing a DELEGATECALL to spoke (servant) contracts is certainly vulnerable to spoke contracts manipulating the state of the hub. The attack surface could be large, and DELEGATECALL wasn't intended as a way to allow arbitrary untrusted code (spokes) to manipulate "shared" state (hub). It may help to explore this more with some specific examples.

A spoke contract S that uses DELEGATECALL to another spoke contract T, is at the mercy of T, rather than attacking T (just like the example with C and D).