Integration question: composing a Monad transfer gate with SignedZone token-specific authorization

[riffsmon-bit]

Integration question: composing a transfer gate with SignedZone authorization

We are evaluating an optional transfer gate for dYØØR Season 2 on Monad. We need
to preserve current creator-fee enforcement and existing marketplace transfers.
This is a compatibility/design question, not a report of an exploit in Seaport
or the deployed registry. The current validator works directly; our proposed
forwarding approach changes the caller context and is not deployed.

If this belongs with a different SignedZone/transfer-registry maintainer, please
point us to the appropriate integration channel. We found no duplicate issue here.

Public deployment and reproduction context

Item	Value
Project	https://dyoor.fun
Chain	Monad, 143
Collection	0x349d8eb480c92cf75371fba5c6344a4d11b9103a
Collection validator	0xa000027a9b2802e1ddf7000061001e5c005a0000
Validator name from matching published runtime	StrictAuthorizedTransferSecurityRegistry
Validator runtime keccak256	0xc7dfe8ae4da5613f6406eab346f0808ee2322316f44d186136c830a71491366c
Policy	security level 3, operator list 4
Registered authorizer	0x000056f7000000ece9003ca63978907a00ffd100
Local fork block	102648547
Block hash	0x07aceeb45656eea920296a98bbea1fe93f7deb2292dc761d5dc585e19149dd13
Public RPC used	https://rpc.monad.xyz

The Monad validator runtime matches the published Ethereum deployed runtime at
the same address byte-for-byte. Published source/runtime evidence.
This does not establish source equivalence for the Monad authorizer itself.

Observed behavior

The validator reads collection policy using msg.sender; token-specific temporary
authorization also depends on the calling collection and token ID. A new gate
calling the existing validator is therefore not transparent.

On a local Foundry fork, five checks passed:

1. Direct validation preserves the collection's existing World escrow whitelist
   entry; naive forwarding does not.
2. Applying the same list and security level to the forwarding gate restores
   static whitelist decisions and continues to reject an unknown operator.
3. The registered authorizer's beforeAuthorizedTransfer(collection, tokenId)
   permits the direct path, but not the mirrored forwarding path.
4. An actual collection transferFrom succeeds with token approval plus that
   temporary authorization before installing the gate, then fails after installing
   it. The token approval is restored before the second attempt.
5. An unregistered caller cannot create the temporary authorization.

Minimal local reproduction sequence

Use a disposable fork at the block above. All impersonation, configuration changes
and transfers below are local test operations, not broadcasts or instructions
to reconfigure the live collection. No private keys or funded accounts are needed.

The incomplete forwarding gate used for the comparison has a public owner()
returning the collection administrator and this validation body:

function validateTransfer(address caller, address from, address to, uint256 id)
    external view
{
    require(msg.sender == collection);
    legacy.validateTransfer(caller, from, to, id);
}

Foundry-style sequence (pseudocode, not a complete standalone harness):

S2 = collection above; V = existing validator; tokenId = 11
governor = S2.owner(); holder = S2.ownerOf(11)
authorizer = V.getAuthorizerAccounts(4)[0]
operator = address(0xBAD); recipient = address(0xB0B)
assert V.isAccountWhitelisted(4, operator) == false

prank(holder): S2.approve(operator, tokenId)
prank(authorizer): V.beforeAuthorizedTransfer(S2, tokenId)
prank(operator): S2.transferFrom(holder, recipient, tokenId) // succeeds
prank(recipient): S2.transferFrom(recipient, holder, tokenId)
prank(holder): S2.approve(operator, tokenId)

deploy local gate(collection=S2, legacy=V, owner=governor)
prank(governor): V.applyListToCollection(gate, 4)
prank(governor): V.setTransferSecurityLevelOfCollection(gate, 3)
prank(governor): S2.setTransferValidator(gate)
prank(operator): S2.transferFrom(holder, recipient, tokenId) // reverts
assert S2.ownerOf(tokenId) == holder

Run the sequence in one test transaction so transient authorization remains in
scope. Impersonating the registered authorizer demonstrates registry semantics;
it is not a valid signed OpenSea order or an end-to-end fulfillment test.

Questions before choosing any integration

1. Is there a supported composable gate or explicit-collection validation/read
   interface that preserves the original collection's temporary authorization?
2. If SignedZone must instead authorize a new registry, does OpenSea support that
   integration on Monad? What onboarding/configuration is required, and how are
   existing orders and already-issued fulfillment extraData affected?
3. Is there a reproducible signed-order fixture or supported local test procedure
   for token-specific authorization and fulfillment on this deployment?
4. Where can we obtain the exact Monad authorizer source/build and immutable
   configuration to verify compatibility independently?

The creator-fee enforcement documentation
describes the SignedZone/registry handshake and API-provided signed extraData.
We do not want to assume custom forwarding is supported merely because the ABI
matches. We will not disable filtering or blanket-whitelist operators to make the
test pass. NFT custody and existing wallet addresses must remain unchanged.

[riffsmon-bit]

Local integration update: we now have a candidate that passes actual Seaport
fulfillment on the pinned Monad fork, without forwarding validation into the old
registry under a changed caller.

The candidate receives substandard-8 beforeAuthorizedTransfer /
afterAuthorizedTransfer callbacks directly and checks native transient
authorization in its collection transfer-validation hook. It reads the existing
registry's public level-3 policy and operator/authorizer list for the original
collection. It is deliberately narrow and not deployed or production-ready.

Important test limitation: we impersonate the zone controller only in the
disposable fork to enable a public fixture signer. We then use genuine seller and
zone signatures with the actual Monad Seaport, SignedZone and Season 2 bytecode.
This does not establish OpenSea API acceptance or access to any live signer.

Eight end-to-end local cases pass:

• Seaport fulfillment through the new gate, payment settlement and SignedZone
  cleanup after the NFT changes owner.
• Rejection of a signed payload targeting the old registry.
• Rejection when the registry address is changed without a new signature.
• Unknown zone signer, wrong domain and expired signature rejection.
• Transfer lock while a session is active; successful fulfillment after revocation.
• Replayed filled-order rejection.

The same-address Ethereum SignedZone runtime was also compared to Monad. All
deployed bytes match except the declared chain-ID and independently recomputed
EIP-712-domain immutables. The published source record is a partial metadata match;
its terminal compiler-metadata difference is recorded separately, not called an
exact compiler-artifact match.

The main unresolved question is therefore platform support for issuing fresh
signed fulfillment context targeting a custom gate, plus how existing orders,
cached extraData and registry discovery are handled. We cannot rewrite an old
signed registry address, and we will not disable creator-fee enforcement to avoid
that requirement. Can you confirm the supported integration/onboarding path, or
direct us to the appropriate registry/API maintainer?

[riffsmon-bit]

Following up with a real completed Monad sale, rather than a fixture zone signature.

Season 2 token #392 transferred in transaction 0x8e43b7ebf348cb821710c52fa4df65325d1a851585742d3e186a09e3d551f09d, block 103163955 (0xc71764e5d7e5613a5b73ab1ff13a4f6227fbf11a1401918ea01d76974edb5c41).

• Seaport target: 0x0000000000000068f116a894984e2db1123eb395, fulfillAdvancedOrder.
• SignedZone: 0x000056f7000000ece9003ca63978907a00ffd100.
• Season 2 collection: 0x349d8eb480c92cf75371fba5c6344a4d11b9103a.
• The NFT is a criteria-resolved consideration item, resolved to Update Consideration.sol #392.
• The 146-byte extraData has version 0 and substandard-8 context naming the existing registry 0xa000027a9b2802e1ddf7000061001e5c005a0000.
• Context hash: 0x1fa1ed05c8a597b5120f1e77070a070c79e83c4b9fabdca4ae0806edd3c83201.
• Calldata hash: 0x507a65750cbb15246f2251d13901a9e869982b78cea89850fb82862262b1ef7a.

Two public RPC endpoints agree on the successful receipt, block inclusion, Season 2 Transfer and historical runtime pins. This is historical evidence of the current path, not an independent signature verification or proof of custom-gate acceptance. Nothing has been changed on the live collection.

Our required product behavior is that wallet custody stays attached to the NFT, former-owner permissions become unusable after handoff, and the buyer can approve fresh missions. The test candidate currently requires an explicit on-chain recall before transfer. We must preserve creator-fee enforcement and existing marketplace sales.

Could you confirm one concrete supported path?

1. Can OpenSea onboard a collection-specific validator implementing the token-specific before/after authorization callbacks and issue signed fulfillment context targeting it on Monad? If yes, what review/configuration and staging evidence are required before changing the collection's validator?
2. Alternatively, is there a supported composable validation interface on the current registry that preserves its collection-scoped transient authorization while enforcing an additional owner-approved transfer restriction?
3. How should existing orders, cached extraData, criteria orders and batch/router fulfillments be tested during such an integration?

The documented fulfillment request schema does not expose a custom-registry override; we do not assume this rules out onboarding. We cannot rewrite the registry in an existing signed context, and we will not relax fee enforcement or deploy a gate on the assumption that it works.

If this repository is not the appropriate integration channel, please direct us to the SignedZone/registry or OpenSea API integration team. Project: https://dyoor.fun. Thank you.