Questions About Editing Validated Orders (zones, tipping, and considerations)

[0xAskar]

1. Are you able to edit considerations of already validated/existing orders?
2. If so, does that depend on zone, and what type of zones would allow for that ability?
3. Is there any real viable difference in adding a tip to the consideration rather than adding the tip in the fulfillOrder structure?

[arr00]

struct OrderParameters {
    address offerer; // 0x00
    address zone; // 0x20
    OfferItem[] offer; // 0x40
    ConsiderationItem[] consideration; // 0x60
    OrderType orderType; // 0x80
    uint256 startTime; // 0xa0
    uint256 endTime; // 0xc0
    bytes32 zoneHash; // 0xe0
    uint256 salt; // 0x100
    bytes32 conduitKey; // 0x120
    uint256 totalOriginalConsiderationItems; // 0x140
    // offer.length                          // 0x160
}

1. Above is the OrderParameters struct for reference. The first n (where n is totalOriginalConsiderationItems) of the consideration array must be the original consideration items--these are part of the signature. You may add any arbitrary consideration items to the array after the first n items. Ensure you do not change totalOriginalConsiderationItems. This is how the concept of adding "tips" to orders works.
2. This has nothing to do with zones.
3. The fulfillOrder structure is not part of the core seaport contracts--it is part of seaport.js which uses either filfillBasicOrder or fulfillAdvancedOrder on the core seaport contracts.

[0xAskar]

Thanks for the response. But the info you provided seem a bit inconsistent with the work I've seen

1. this makes sense, as I thought, but when I tried to edit the consideration array, it ended up invalidating the offer. I had to add tips to the fulfillOrder. But as you say in 3. that's because it is part of seaport.js, so you're usually able to add to considerations?

2. Why does it not have to do with zones? Could you explain what this means: As extensions to the consideration array on fulfillment (i.e. "tipping") can be arbitrarily set by the caller, fulfillments where all matched orders have already been signed for or validated can be frontrun on submission, with the frontrunner modifying any tips. Therefore, it is important that orders fulfilled in this manner either leverage "restricted" order types with a zone that enforces appropriate allocation of consideration extensions, or that each offer item is fully spent and each consideration item is appropriately declared on order creation.

3. Hmm, so I see, the structure for seaport-js and the seaport contracts are a bit different then?