onflow / onflow/docs

Interacting with Cadence

Open
#685 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
TypeScript
Stars
13
Forks
81
PR merge metrics
No merged PRs in 30d

Description

Why, What, How
“Flow EVM” extended precompiles
COA’s EVM smart contract interface

Another native tool ensuring seamless composability across environments are Cadence Owned Accounts. COA is a natively supported smart contract wallet type on the Flow EVM, facilitating composability between Cadence and EVM environments; COA is a EVM smart contract wallet controlled by a Cadence resource:

its an a smart contract deployed to Flow EVM, is accessible by other Flow EVM users and can accept and controls EVM assets such as ERC721s. However unlike other EVM smart contracts, they can initiate transactions (COA’s EVM address acts as tx.origin). This behaviour is different than other EVM environments that only EOA accounts can initiate a transaction. A new EVM transaction type (TxType = 0xff) is used to differentiate these transactions from other types of EVM transactions (e.g, DynamicFeeTxType (0x02).

its owned and controlled by a Cadence resource, which means they don’t need an EVM transaction to be triggered (e.g. a transaction to make a call to execute or EIP-4337’s validateUserOpmethod). Instead, using the Cadence interface on the resource, direct call transactions can be triggered. Calling this method emits direct call transaction events on the Flow EVM side.

Each COA smart contract can only be deployed through the Cadence side. EVM.createCadenceOwnedAccount(): @CadenceOwnedAccount constructs and returns a Cadence resource, allocates a unique Flow EVM address (based on the UUID of the resource and with the prefix 0x000000000000000000000002) and deploys the smart contract wallet byte codes to the given address. The address 0x0000000000000000000000020000000000000000 is reserved for COA factory, an address that deploys contracts for COA accounts.

function supportsInterface(bytes4 interfaceId) external view returns (bool)
provides the functionality needed to satisfy EIP-165. If the given interfaceID is available it returns true.

receive() external payable
is the standard method needed to allow other EVM users to send Flow to the smart contract directly, if data is passed to this method it would revert. This method is not usually directly called and any call to smart contract it without the data is automatically rerouted to this function.

function onERC721Received(address _operator, address _from, uint256 _tokenId, bytes calldata _data) external returns (bytes4)
is provided to support safe transfers from ERC721 asset contracts. It's called on the recipient after a transfer. Return of any value other than the magic value (0x150b7a02, as defined in the ERC-721 standard) must result in the transaction being reverted.

function tokensReceived(address operator, address from, address to, uint256 amount, bytes calldata data, bytes calldata operatorData) external
is provided to support safe transfers from ERC777 asset contracts. is called by the ERC777 token contract after a successful transfer or a minting operation. It doesn’t return anything.

function onERC1155Received(address _operator, address _from, uint256 _id, uint256 _value, bytes calldata _data) external returns (bytes4)
is provided to support safe transfers from ERC1155 asset contracts. It should return 0xf23a6e61 if supporting the receiving of a single ERC1155 token type.

function onERC1155BatchReceived(address _operator, address _from, uint256[] calldata _ids, uint256[] calldata _values, bytes calldata _data) external returns (bytes4)
is provided to support safe transfers from ERC1155 asset contracts (batch of assets). It returns 0xbc197c81 if supporting the receiving of a batch of ERC1155 token types.

function isValidSignature(bytes32 _hash, bytes memory _signature) external view virtual returns (bytes4)
returns the bytes4 magic value 0x1626ba7e (as defined in ERC-1271) when the signature is valid. This method is usually used to verify a personal sign for the smart contract wallets (see EIP-1271 for more details). In the context of COA smart contracts, we consider the signature as an aggregation of Flow account address, key index, path to COA resource and a set of signatures (Flow account). we return true if the signatures are valid, it provides enough weight for the account, and an account holds the resource at the given path. Under the hood, this method uses Cadence Arch contract for verification.

COA smart contract (in Solidity)

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

The issue names no repository file, test, or entry point. Start by reviewing the linked Flow EVM extended precompiles and COA smart contract specifications, then establish the documentation scope and acceptance criteria before implementation.

Written by the indexing model from the issue text.

Assessment

Tech stack
solidity
Domain
blockchain, documentation
Issue type
Documentation
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
20/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.