Deployment fails with HEX encoded data error


I think that typically in deployment (at least in web3 contract deploy) the data field must be fed a HEX code, which is happening with all of my other contracts in the package I’m building. There is one contract that continues to return deployment failed with error: The data field must be HEX encoded data I’m looking all over my contract for any issues and I deployed it successfully outside of zos. What issues could cause this error. Apologies if this has been covered before and I missed it.

This is happening after I add the contract and then try to execute zos push.


Should I create an issue for this? I have looked at my contract in many different ways and I can’t identify why this one contract would fail deployment. Thanks for any help!


Hello @pllearns! Is there any relevant code you can post? Maybe your truffle config or the contract? Have you performed the proper zos commands prior to zos push?


Hey! Here is the truffle.js, I am currently using the development network, and solc version 0.5.2:

  ignore: /node_modules\/(?!openzeppelin-solidity)/
const HDWalletProvider = require(`truffle-hdwallet-provider`)
require(`dotenv`).config() // Store environment-specific variable from '.env' to process.env
const NonceTrackerSubprovider = require(`web3-provider-engine/subproviders/nonce-tracker`)

// NOTE: If retreiving mnemonic from Metamask - use 1st wallet in profile list.

const wallet = process.env.WALLET
const mnemonic = process.env.MNENOMIC
const infuraKey = process.env.INFURA_API_KEY

module.exports = {
  migrations_directory: `./migrations`,
  networks: {
    development: {
      network_id: `*`, // Match any network id
      host: `localhost`,
      gas: 6721975,
      port: 8545
    kovan: {
      network_id: 42,
      from: wallet,
      provider: () => new HDWalletProvider(
      gas: 6986331,
      gasPrice: 4500000000
    ropsten: {
      network_id: 3,
      provider: () => new HDWalletProvider(
      gas: 6986331,
      gasPrice: 3500000000
    mainnet: {
      network_id: `1`,
      provider: () => {
        const wallet = new HDWalletProvider(
        const nonceTracker = new NonceTrackerSubprovider()
        return wallet
      gas: 6986331,
      gasPrice: 25000000000
  solc: {
    optimizer: {
      enabled: true,
      runs: 500
  compilers: {
    solc: {
      version: `0.5.2`


Here is the snippet from the contract, it’s based on the current PLCR contract, the initialize function is constructed the same as the other contracts that are deploying:

    // ============
    // ============

    uint public pollNonce;
    uint public INITIAL_POLL_NONCE;

    mapping(uint => Poll) public pollMap; // maps pollID to Poll struct
    mapping(address => uint) public voteTokenBalance; // maps user's address to voteToken balance

    mapping(address => DLL.Data) dllMap;
    AttributeStore.Data store;

    IERC20 public token;

    @dev Initializer. Can only be called once.
    @param _token The address where the ERC20 token contract is deployed
    function initialize(address _token) initializer public {
        // require(_token != address(0) && address(token) == address(0));
        token = IERC20(_token);
        pollNonce = INITIAL_POLL_NONCE;


The only difference that I can observe is this contract’s location in the file structure: it’s under /contracts/PLCR/... where the other contracts are in /contracts/, but the zos add is still finding the contract since it compiles to the /build/contracts/ folder like all of the other contracts


Thanks! I’m gonna go ahead and tag @spalladino to see if there is anything in particular he can spot.


Awesome! Thank you @IvanTheGreatDev!


Hey @pllearns! Can you share the output of zos push with the --verbose flag, as well as zos --version? Also, is your repo public, so we can take a look at it? Thanks!


Hey @spalladino! Here is the output

[Error] Error: PLCRVoting deployment failed with error: The data field must be HEX encoded data.
    at _txInputFormatter (/Users/philliplorenzo/.nvm/versions/node/v10.15.0/lib/node_modules/zos/node_modules/web3-core-helpers/src/formatters.js:88:15)
    at Method.inputTransactionFormatter (/Users/philliplorenzo/.nvm/versions/node/v10.15.0/lib/node_modules/zos/node_modules/web3-core-helpers/src/formatters.js:135:15)
    at /Users/philliplorenzo/.nvm/versions/node/v10.15.0/lib/node_modules/zos/node_modules/web3-core-method/src/index.js:144:38
    at (<anonymous>)
    at Method.formatInput (/Users/philliplorenzo/.nvm/versions/node/v10.15.0/lib/node_modules/zos/node_modules/web3-core-method/src/index.js:142:32)
    at Method.toPayload (/Users/philliplorenzo/.nvm/versions/node/v10.15.0/lib/node_modules/zos/node_modules/web3-core-method/src/index.js:177:23)
    at send (/Users/philliplorenzo/.nvm/versions/node/v10.15.0/lib/node_modules/zos/node_modules/web3-core-method/src/index.js:467:30)
    at Object._executeMethod (/Users/philliplorenzo/.nvm/versions/node/v10.15.0/lib/node_modules/zos/node_modules/web3-eth-contract/src/index.js:897:24)
    at Promise (/Users/philliplorenzo/.nvm/versions/node/v10.15.0/lib/node_modules/zos/node_modules/zos-lib/src/artifacts/Contract.ts:69:10)
    at new Promise (<anonymous>)
    at Contract.<anonymous> (/Users/philliplorenzo/.nvm/versions/node/v10.15.0/lib/node_modules/zos/node_modules/zos-lib/src/artifacts/Contract.ts:66:12)
    at (<anonymous>)
    at fulfilled (/Users/philliplorenzo/.nvm/versions/node/v10.15.0/lib/node_modules/zos/node_modules/zos-lib/lib/artifacts/Contract.js:4:58)

And here is the repo:
The contract is in /contracts/PLCR/PLCRVoting.sol

My zos version is 2.2.0


I also have some TestHelper() issues, should I put that in another post, or keep in here since they may be related? @spalladino do you have any questions about the repo?


Hey @pllearns, you have actually stumbled upon a nasty bug in zos, which I’ve just filed here. We’ll be working on this soon, and I hope that we can release a patch version with the fix by the end of next week the most.

As a workaround, for now, you can change the visibility of the getAttribute and setAttribute functions in AttributeStore.sol in your project from public to internal. That should make the library internal as well, which will not require linking (which is actually better in this case, as you save gas by removing unnecessary CALLs that can be inlined in the contract), and will thus not trigger the bug.

Apologies for the inconvenience!


I think it’d be best if you open a new issue or thread. That said, keep in mind that we very recently updated our testing guide, so make sure to check it out!


Great! Thanks @spalladino , I wish I would have been able to identify the attributeStore visibility as a workaround. I remember at one point removing it from the contract altogether, but that really broke things! lol I’ll post the test issue in another post if I need to. Thanks again!