Problem with safe-core-sdk in Defender

Support Defender
1

I am currently working on an OpenZeppelin Defender AutoTask script (which is in JS), making use of the safe-core-sdk. I am using the latest dependency environment, but I have tested this with all of the available ones already.

The basics are working, I have successfully deployed a Safe via this script on Goerli via the official Factory, so that part is fine. However, I am a bit confused as the resulting Safe object that I am receiving via the safeFactory.deploySafe(...) call seems to be incomplete somehow.

In the implementation used in the SDK you can see that it should contain functions like getAddress() or createAddOwnerTx(). While the read-only ones seem to work (I can use getAddress() and so on), the other ones (like createAddOwnerTx()) are all leading to an error of ... is not a function. Printing createdSafe via console.log() just gives me Safe { }.

I have already tried to create a new safeSDK (a Safe instance) from scratch based on the deployed safe, but the same thing happens here. I am not really sure what to do here, what am I missing? Any ideas?

// Note: some of this code is related to the openzeppelin defender
const { DefenderRelayProvider } = require('defender-relay-client/lib/web3');
const Web3 = require('web3');
const Safe = require('@gnosis.pm/safe-core-sdk');
const { SafeFactory, SafeAccountConfig, Web3Adapter } = require('@gnosis.pm/safe-core-sdk');

exports.handler = async function(credentials) {
  const defenderProvider = new DefenderRelayProvider(credentials, { speed: 'fastest' });
  const web3 = new Web3(defenderProvider);

  const signer = '0x<REMOVED>';

  const ethAdapter = new Web3Adapter({
    web3,
    signerAddress: signer
  });
  
  const owners = ['0x<REMOVED>'];
  const threshold = 1;
  const safeAccountConfig = {
    owners,
    threshold
  };
  
  const safeFactory = await SafeFactory.create({ ethAdapter });

  // note: this works fine, the deployed safe is correct and working
  const createdSafe = await safeFactory.deploySafe(safeAccountConfig);

  const safeAddress = await createdSafe.getAddress();
  console.log(safeAddress); // this works!

  // the following does not work (error: createAddOwnerTx is not a function)
  const addUserTx = await safeSdk3.createAddOwnerTx({ ownerAddress: '0x<REMOVED>' });
  const addUserTxResponse = await safeSdk3.executeTransaction(createdTx);
}

I have posted it to the Ethereum StackOverflow (which seems to be the only way to really get support from the Safe team) here.

2

@marvinkruse
My quick guess is that embedded within Autotasks safe-cores-sdk is at ^0.3.1 version. While package itself had major release since than and also moved to different name. Missing methods might be a newer version feature.

If you want to try using newest version sdk you can use rollup to bundle dependency in your script.
Refer to sample rollup autotask to get started

3

Hey @peersky,

thank you for being so helpful! I tried to go via the rollup method as you proposed, but that led to different problems...

No native build was found for platform=linux arch=x64 runtime=node abi=93 uv=1 libc=glibc node=16.16.0
    loaded from: /var/task

I've basically added this line to the code instead of the old import

import Safe, { SafeFactory, SafeAccountConfig, Web3Adapter } from '@safe-global/safe-core-sdk';

And yarn build with rollup executes fine, with no errors. The resulting dist/index.ts file, however, does not work (neither locally nor within the AutoTask). Following the trace, it leads me to this line that triggers this in the dist/index.ts file:

const addon = nodeGypBuild(__dirname);
var bindings = lib$1(new addon.Secp256k1());

Does this have something to do with the secp256k1 build usually requiring to be built for the specific architecture?

Have you encountered this before or might you know how to fix this? A quick Google search led me to some folks that had a similar error when making use of AWS Lambda functions (the underlying technology of AutoTasks), but there was no solution in their case the cause seemed to be the environment or so? Could that be the reason?

4

Are you able to share repo you are working on ?

Considering that your build does not work locally, I assume it has nothing to do with AWS and most probably your process of generating rollup is place to look in to