Skip to content

trying to call this contract with ucs03 #4552

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
daikiijax opened this issue May 14, 2025 · 13 comments
Open

trying to call this contract with ucs03 #4552

daikiijax opened this issue May 14, 2025 · 13 comments
Assignees
Labels
A-app Area: app.union.build C-feature-request Category: A feature request, i.e: not implemented / a PR.

Comments

@daikiijax
Copy link

how do i call this contract? make instruction and how do i get this salt?

Image

@daikiijax daikiijax added A-app Area: app.union.build C-feature-request Category: A feature request, i.e: not implemented / a PR. labels May 14, 2025
@daikiijax
Copy link
Author

failed to call this contract and why?

Image

@umarpython
Copy link

Since you're trying to call the "ucs02" contract and it's failing, let's break this down with some ideas to resolve the issue:
Check the Contract Address and ABI:
Ensure you have the correct contract address and ABI. The ABI defines the contract's functions, and without it, you can't call the contract. Look in the Union Build GitHub repo for a compiled artifact (e.g., ucs02.json) or the contract's source code to generate the ABI.
Verify the Function You're Calling:
Confirm the function name and parameters you're trying to call. If the function doesn't exist or the parameters are incorrect, the call will fail. Check the contract's code for the function signature.
Network and Environment:
Make sure you're interacting with the correct blockchain network (e.g., Ethereum mainnet, testnet like Sepolia, or a local network). If the contract isn't deployed on the network you're targeting, the call will fail.
Use a tool like Hardhat, Truffle, or Foundry to deploy and interact with the contract locally for testing.
Transaction Details:
Gas Limit: If the gas limit is too low, the transaction will fail. Estimate the gas using a tool like ethers.js or web3.js and set an appropriate limit.
Sender Account: Ensure the account you're using has enough funds (e.g., ETH for gas fees) and the necessary permissions to call the contract.
State Requirements: Some functions require specific conditions (e.g., only the contract owner can call them, or certain state variables must be set). Check the contract's logic for require or modifier conditions.
Debug the Failure:
The failure reason isn't specified in the issue. Use a blockchain explorer (e.g., Etherscan) to look up the transaction hash and see the error message (e.g., "out of gas," "revert," or "invalid opcode").
If you're using a library like ethers.js, catch the error to see the revert reason:
javascript
try {
await contract.functionName(...args);
} catch (error) {
console.log(error.reason);
}
Getting the SALT:
The user asked, "how do I get this SALT?" In smart contracts, a "salt" is often used in deterministic contract deployment (e.g., with CREATE2 opcode). It’s a random value that ensures a unique contract address.
If ucs02 uses CREATE2, the salt should be specified in the deployment script. Check the deployment code in the repo for something like:
solidity
address computedAddress = address(uint160(uint(keccak256(abi.encodePacked(
bytes1(0xff),
address(this),
salt,
keccak256(abi.encodePacked(bytecode))
))))));
If the salt isn't hardcoded, it might be generated dynamically (e.g., using a timestamp or random number). Look for deployment scripts or documentation in the repo.
Next Steps
Could you share more details about the error message when the call fails, or the specific function you're trying to call? That would help narrow down the issue.
For the salt, if you can share the deployment script or context of how ucs02 is deployed, I can help you locate or generate the salt value.

@daikiijax
Copy link
Author

daikiijax commented May 19, 2025

My current issue is that I'm failing to construct the correct operand. I don’t really understand how to build a valid operand for UCS03. Actually, I’m confused about this operand — how exactly am I supposed to fill it in? I mean, in UCS03-ZKGM there are many types of instructions, like exampleBatchInstruction, exampleMultiplexInstruction, exampleForwardInstruction, and exampleTransferAndCall. So which one is actually the correct instruction to use?

@umarpython
Copy link

I understand you're struggling to construct a valid operand for the "ucs03" contract, specifically within the UCS03-ZKGM framework, and you're unsure which instruction type to use among exampleBatchInstruction, exampleMultiplexInstruction, exampleForwardInstruction, and exampleTransferAndCall. Let’s break this down step-by-step to clarify how to build the operand and choose the right instruction.
Understanding Operands in the Context of UCS03-ZKGM
In smart contracts, an operand is typically the data or arguments you pass to a function when calling it. For UCS03-ZKGM, which seems to be a zero-knowledge-based system (ZKGM likely stands for something like Zero-Knowledge Generic Machine), the instructions you mentioned (exampleBatchInstruction, etc.) suggest a framework where different types of operations are encoded as instructions with specific operands. Each instruction type likely serves a distinct purpose, and the operand structure will depend on the instruction you choose.
Since the Union Build GitHub repo isn't publicly detailed in my knowledge, and the specific UCS03-ZKGM documentation isn't available, I'll base my guidance on common patterns in smart contract systems, zero-knowledge frameworks, and instruction encoding. Let's analyze the instructions and how to construct their operands.
Step 1: Identify the Purpose of Each Instruction
The instruction types you listed give clues about their functionality:
exampleBatchInstruction: Likely used to batch multiple operations into a single call. This is common in ZK systems to reduce gas costs and proof overhead by bundling operations.
exampleMultiplexInstruction: Probably allows routing or multiplexing multiple sub-instructions, possibly to different contracts or logic paths within the ZK system.
exampleForwardInstruction: Typically used to forward a call to another contract or module, often used in proxy or delegation patterns.
exampleTransferAndCall: Likely performs a token transfer (or similar operation) followed by a function call on the recipient contract, a common pattern in ERC20/ERC721 interactions.
To choose the correct instruction, you need to clarify your goal. For example:
If you're trying to execute multiple operations at once, use exampleBatchInstruction.
If you're routing operations to different targets, use exampleMultiplexInstruction.
If you're delegating a call to another contract, use exampleForwardInstruction.
If you're transferring assets and then triggering a function, use exampleTransferAndCall.
Since your issue ticket mentions a failure to call the contract but doesn't specify the operation, let’s assume a common scenario: you're trying to perform a single operation (e.g., transferring an asset and calling a function). This makes exampleTransferAndCall a good candidate to explore first. If this isn't your goal, you can adjust based on the explanations above.
Step 2: Understand the Operand Structure
In smart contract systems, operands for instructions like these are often encoded as a bytes array, where the data is structured according to the instruction's requirements. For UCS03-ZKGM, the operand will likely include fields like:
Instruction identifier: A selector or ID to indicate the instruction type.
Target address: The contract or account to interact with.
Parameters: Specific data like amounts, function selectors, or additional arguments.
Without the exact ABI or documentation for UCS03-ZKGM, I’ll outline a general approach based on similar systems (e.g., Ethereum smart contracts and ZK frameworks). Let’s use exampleTransferAndCall as our example.
Example: Operand for exampleTransferAndCall
This instruction might expect an operand with the following structure (hypothetical, based on common patterns):
Instruction ID (e.g., 1 byte): A value identifying exampleTransferAndCall.
Token Address (20 bytes): The address of the token contract (if applicable).
Recipient Address (20 bytes): The address receiving the transfer.
Amount (32 bytes): The amount to transfer (often a uint256).
Target Contract Address (20 bytes): The contract to call after the transfer.
Function Selector (4 bytes): The function to call on the target contract (e.g., the first 4 bytes of keccak256("functionName(paramTypes)")).
Function Arguments (variable length): The arguments for the function call, ABI-encoded.
Step 3: Construct the Operand
Let’s construct an operand for exampleTransferAndCall. Suppose you want to:
Transfer 100 tokens from a token contract at 0x123... to 0x456....
Then call a function onTransfer(uint256) on a contract at 0x789....

  1. Instruction ID
    Assume exampleTransferAndCall has an ID of 0x03 (this is a guess; you’d need to check the contract’s documentation or source code).
  2. Token Address
    0x123... (20 bytes, padded).
  3. Recipient Address
    0x456... (20 bytes, padded).
  4. Amount
    100 as a uint256 (32 bytes): 0x000...64 (hex for 100).
  5. Target Contract Address
    0x789... (20 bytes, padded).
  6. Function Selector
    For onTransfer(uint256), the selector is the first 4 bytes of keccak256("onTransfer(uint256)"). Using a tool like an Ethereum ABI encoder, this might be 0x12345678 (example value).
  7. Function Arguments
    uint256 argument (e.g., the amount 100 again), ABI-encoded as 32 bytes: 0x000...64.
    Encoding the Operand
    Concatenate these fields into a single bytes array:
    0x03 (1 byte)
    0x123... (20 bytes)
    0x456... (20 bytes)
    0x000...64 (32 bytes)
    0x789... (20 bytes)
    0x12345678 (4 bytes)
    0x000...64 (32 bytes)
    Total length: 1 + 20 + 20 + 32 + 20 + 4 + 32 = 129 bytes.
    In a tool like ethers.js, you can encode this using ethers.utils.concat:
    javascript
    const { ethers } = require("ethers");

const instructionId = "0x03";
const tokenAddress = "0x1234567890abcdef1234567890abcdef12345678"; // Example
const recipientAddress = "0x456789abcdef123456789abcdef123456789abcde";
const amount = ethers.utils.hexZeroPad("0x64", 32); // 100
const targetAddress = "0x789abcdef123456789abcdef123456789abcdef12";
const functionSelector = "0x12345678"; // Example selector
const functionArgs = ethers.utils.hexZeroPad("0x64", 32); // 100

const operand = ethers.utils.concat([
instructionId,
tokenAddress,
recipientAddress,
amount,
targetAddress,
functionSelector,
functionArgs,
]);

console.log(operand);
Step 4: Call the Contract with the Operand
Assuming ucs03 has a function like executeInstruction(bytes calldata operand), you’d call it like this:
javascript
const contractAddress = "CONTRACT_ADDRESS_HERE";
const contractABI = ["function executeInstruction(bytes calldata operand)"];
const provider = new ethers.providers.JsonRpcProvider("YOUR_PROVIDER_URL");
const wallet = new ethers.Wallet("YOUR_PRIVATE_KEY", provider);
const contract = new ethers.Contract(contractAddress, contractABI, wallet);

await contract.executeInstruction(operand);
Step 5: Why Your Call Might Be Failing
Incorrect Operand Structure: If the operand doesn’t match the expected format (e.g., wrong field lengths or order), the contract will revert. Double-check the contract’s source code for the exact structure.
Wrong Instruction Type: If exampleTransferAndCall isn’t the right instruction for your use case, the contract might reject it. Review your goal and the contract’s documentation.
Gas Issues: Ensure you’re providing enough gas for the transaction.
Permissions/State: The contract might have conditions (e.g., only certain addresses can call it, or certain state must be set).
Step 6: Choosing the Right Instruction
Without more context, I can’t definitively say which instruction is correct. However:
Start with exampleTransferAndCall if you’re dealing with a transfer followed by a call.
If you’re batching multiple operations, switch to exampleBatchInstruction and adjust the operand to include multiple sub-instructions.
If none of these fit, you’ll need to dig into the ucs03 contract code or documentation to see how these instructions are defined.
Regarding the SALT (From Your Earlier Comment)
You also asked about getting the salt. In the context of CREATE2, the salt is a bytes32 value used to deterministically compute a contract’s address. For ucs03, the salt might be:
Hardcoded in the deployment script.
Generated dynamically (e.g., based on a timestamp or user input).
Passed as part of the operand for certain instructions (less likely here).
Check the deployment script in the Union Build repo for a line like:
solidity
bytes32 salt = bytes32(uint256(12345)); // Example
If it’s not hardcoded, it might be computed—look for logic involving keccak256 or similar.
Next Steps
Can you share the specific operation you’re trying to perform with ucs03? That would help me recommend the right instruction.
If you have access to the contract’s source code or ABI, check the definition of exampleTransferAndCall (or other instructions) to confirm the operand structure.
If the call still fails, share the error message or transaction hash for further debugging.

@daikiijax
Copy link
Author

do you have contact? i need to call you?

@umarpython
Copy link

Every I said here was from grok on X
You can get more details using AI

@daikiijax
Copy link
Author

still failed to call contract bro

@umarpython
Copy link

+2349060574435

@daikiijax
Copy link
Author

what's that number?

@umarpython
Copy link

WhatsApp contact

@daikiijax
Copy link
Author

i don't have WhatsApp. do you have discord, telegram or Twitter?

@umarpython
Copy link

Itzlawkeeper01 X handle

@sheriifMahadi
Copy link

Hi, i'm having a bit of an issue with the sdk. did you get it to work?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-app Area: app.union.build C-feature-request Category: A feature request, i.e: not implemented / a PR.
Projects
None yet
Development

No branches or pull requests

4 participants