Originally posted on Mirror

The ecosystem for sales and purchases of NFTs is rapidly maturing. A wide selection of invaluable tooling exists today and plenty more has yet to reach the market. We present a few of our own solutions to the hurdles encountered when transacting in NFTs in a non-retail context.

OpenSea and the Wyvern Exchange Contract

OpenSea’s marketplace is founded upon Wyvern Protocol’s early smart contracts and has been battle tested through several years of use and now hundreds of millions of dollars in daily transaction volume.

For all the Wyvern Exchange contract does well, due to limitations of Solidity an invocation of its public function for fulfilling an order is difficult to understand at a glance.

If only one person is responsible for the whole lifecycle of an OpenSea purchase then this is not a concern — the person trusts the OpenSea dApp to craft the correct invocation of this function and there is no question as to what will be purchased and where it will go.

But with the separation of the responsibilities for creating and reviewing that transaction, there comes a problem for the reviewer.

The simplest option at present is to have the reviewer(s) craft their own, duplicate copies of the proposed transaction and come to agreement on the raw transaction data. In this scenario none of the parties can be certain as to what the transaction will ultimately do, but they can each trust that as long as they agree on the raw transaction data and believe that the OpenSea dApp itself has not been compromised, it is likely the transaction will behave in accordance with their intent.

This, however, brings a substantial operational burden for those who would review these transactions. In practice, any person should be able to craft a duplicate copy of the data for a Wyvern Exchange transaction without access to the signer that will be used for the purchase. In practice, OpenSea’s UI is not tailored for this use and will require access to an active Web3 session for the same signer.

A Tool for OpenSea Transaction Review

We’ve crafted a simple tool for parsing and ultimately reviewing calls to the Wyvern Exchange’s atomicMatch_ function. The utility is publicly available here and supports parsing direct calls to atomicMatch_() or unwrapping and parsing those calls from a transaction proposed to a Gnosis Safe.

The reviewer now no longer need access to the signer that will purchase the assets, and can visually confirm the details of the token to be purchased.

Batching Purchases

For a number of reasons, an actor might want to fulfill orders for multiple assets on the market at once. Tools for this use case are emerging, the first of which being the excellent genie.xyz.

We present our solution developed in tandem and tailored for use with a Gnosis Safe.

The Problem of Review, Again

Gnosis’s Multisend utility creates transactions that are even more inscrutable in their contents, posing a challenge for the Safe Owners to validate and approve transactions created with its use.

There is an added dimension to the review step, as any assets in the batch that have had their listings changed since the transaction was proposed will cause the entirety of the transaction to be reverted once broadcast.

Here we’ve opted for a different approach, wherein a Safe Owner does not review the transaction body but instead simulates its approval and execution and checks the results against the stated outcomes they expect.

This provides the reviewer some confidence that the transaction will not revert and needlessly burn gas, and that the purchases they expect are correctly reflected in the transaction’s data. The Safe Owners can simulate once before granting their approval, then again just before executing the transaction to confirm none of the listings have changed.

The utility is published publicly at https://www.npmjs.com/package/@standard-crypto/opensea-batch-purchaser. Its use requires a marginally more technical user with access to an Alchemy project and the ability to install and run node packages.

Importantly, it does not require access to any of the signers for the safe’s owners as it will mock approvals from owners in its local simulation.

Delegation with Gnosis Safes

Lastly, we recommend use of a surprisingly under-promoted feature of Gnosis Safes: the ability for Owners to register delegates.

Any delegate is able to freely propose transactions to the safe and must sign their endorsement of the transaction for it to be accepted by Gnosis’s web2 API. Signatures from delegates never count toward the threshold of Owner signatures required to execute any transaction, meaning the delegate has power only to propose transactions to the Owners.

This allows Safe Owners to keep approval privileges locked behind hardware-backed signers, while granting proposal privileges to hot wallets for easier use within dApps or for delegating proposal power to a trusted actor to enact some complex on-chain interaction on the Safe Owners’ behalf.

Safe delegates are a wholly off-chain abstraction and are created and removed via EIP-712 signatures. We recommend use of this excellent tool for creating and administering delegates.