Docs

Overview

Assetflow is a peer-to-peer market for digital assets. A file is encrypted in the seller’s browser and pinned to IPFS; ownership of it is an ERC-1155 licence held in the seller’s own wallet. A sale is a single transaction that moves the licence one way and USDG the other.

The protocol holds nothing. There is no pool, no deposit and no withdrawal. Orders are signed off-chain and settled on-chain, which means discovery can be cheap and fast while settlement stays verifiable.

Chain and addresses

USDG is Global Dollar. It implements EIP-2612, which is what allows a first purchase to need a signature rather than an approval transaction.

Assets and editions

Every listing is one ERC-1155 token id carrying its creator, the keccak hash of the ciphertext, the IPFS CID, a drop id, its category and an ERC-2981 royalty. Supply decides how the asset behaves:

19 categories are listable today. Because the settlement contract keys on a token standard rather than a category, widening the catalogue needs no contract change.

Order format

Orders are EIP-712 typed data. A maker signs one off-chain; the signature is the only thing that authorises a transfer.

struct Order {
    address maker;
    address asset;
    uint8   standard;  // 0 = ERC20, 1 = ERC721, 2 = ERC1155
    uint256 tokenId;
    uint256 amount;
    address payToken;
    uint256 price;     // total, in payToken units
    address taker;     // address(0) = open to anyone
    uint64  expiry;
    uint256 nonce;
    uint8   side;      // 0 = ASK (maker sells), 1 = BID (maker buys)
}

Flipping side turns the same struct into a bid, so a buyer can post “I will pay 400 USDG for that dataset” and a seller can accept it.

Settlement

settle(ask, sigAsk, bid, sigBid) is the primary path. Both sides have already signed, so whoever submits the transaction is only a broadcaster and gains nothing from it. The contract checks that the two orders describe the same asset, token id and pay token, that the bid price meets the ask, that neither has expired or been cancelled, and that both signatures are valid.

The quantity settled is the smaller of the two remaining amounts, so a bid for 3 licences against an ask offering 10 settles 3 and leaves 7 open. Execution is at the ask price, so any price improvement goes to the buyer. Then, in one transaction, the asset moves from maker to taker and USDG moves from taker to maker less fees. Both legs land or the transaction reverts.

fill(order, sig, amount) lets someone holding native gas take an order directly, with themselves as counterparty. It exists so the market keeps working if the relayer is down. cancel(nonce) invalidates an order.

Sponsored gas

No participant ever needs the native token. Three mechanisms cover the three actions:

• Buying — USDG implements EIP-2612, so approval is a signature. The buyer signs a permit and a bid; the relayer submits both as one transaction.
• Selling — the asset contract treats the settlement contract as an approved operator unconditionally, so setApprovalForAll never happens. This is only safe because the settlement contract cannot move a token without a signed order.
• Listing — the creator signs a mint authorisation and the relayer submits mintFor. The token is minted to the creator, not the relayer.

The relayer is an ordinary funded account with no special contract privilege. It cannot move anything without both parties’ signatures, and it only spends gas when a settlement actually lands.

Encryption and keys

The browser generates an AES-256-GCM key, encrypts the file locally, and uploads only ciphertext to IPFS. Keys are derived rather than stored:

fileKey = HKDF-SHA256(MASTER_SECRET, chainId || assetContract || dropId)

The drop id is issued at upload and recorded on-chain in the token metadata, so the gateway can recompute any key on demand and there is no key database. To download, a client presents its Privy access token; the gateway verifies it, resolves the linked wallet, checks balanceOf over RPC, and only then derives and returns the key. Decryption happens back in the browser.

Stated plainly: the gateway holds the master secret and can therefore derive any file key. That is a real custody point. Because the ciphertext and its hash are public and permanent, it can be replaced with threshold decryption later without touching the contracts or re-uploading anything.

The order book

There is no database. postOrder emits the signed order as an event, and cancellation emits another — the event log is the book. Asset metadata lives on IPFS, ownership is balanceOf, and provenance is the settlement events.

A small indexer reads those logs into a JSON snapshot that the site renders. The snapshot is a cache and can be deleted and rebuilt from chain state at any time.

Fees

Both fees are deducted inside settle, so there is no collection step.

Status