The Stellar and Ethereum networks are in many ways complementary. Stellar provides simple transactional functionality that is cheap and fast, with transactions costing a small fraction of a cent and consistently taking less than ten seconds to complete. Ethereum provides a complete programming language (Solidity), smart contracts, and data storage, but as a result transactions are orders of magnitude slower and more expensive. What’s more, the cost of transactions on Ethereum is variable with both complexity (code and metadata) and network congestion.
Making an application dual-platform allows it to benefit from the best of both worlds — Stellar’s low cost and high speed, and Ethereum’s power and flexibility. But this requires that tokens can be moved safely from one blockchain to another without loss or duplication.
Because metadata on Stellar is limited to an asset and a 32-character metadata field — and large amounts of metadata becomes infeasibly expensive on Ethereum when the tokens are of relatively small real value — the bulk of the metadata is stored in IPFS.
Stellar transactions store the token ID using the metadata field, linking back to the IPFS address for the full token data. They can optionally store additional numeric metadata fields using alternate asset types.
Ethereum uses an ERC721 contract that allows key metadata to be stored directly in the blockchain without needing to refer to IPFS. Coin ID and value, batch ID, sequence and count, and direct links to the IPFS metadata and the corresponding API endpoint (following the ERC721 metadata standard).
The IPFS metadata is always present, so when moving from Stellar to Ethereum we can rely on it to fill in the additional fields. The core, immutable metadata is written to the ERC721 token as well so that it can be used directly by Ethereum smart contracts. For example, the nominal value of the token can be used by a smart contract managing token sales, auctions, or trades, and the batch and sequence can control uniqueness.
The Ethereum and Stellar blockchains are entirely separate entities, and a token cannot truly leave either network. So the process of transferring tokens is one of careful, auditable bookkeeping. The requirements are:
- No token can be lost — the transfer from one network to the other should succeed fully or fail such that all changes are reverted.
- No token can be duplicated — if a token is transferred to another network, it is no longer available on the original network.
- Transactions are verifiable — any third party should be able to inspect the respective blockchains and come to the same conclusion as to the ownership of any token.