syntax = "proto3";

package tycho.evm.v1;

// This file contains the proto definitions for Substreams common to all integrations.

// A struct describing a block.
message Block {
  // The blocks hash.
  bytes hash = 1;
  // The parent blocks hash.
  bytes parent_hash = 2;
  // The block number.
  uint64 number = 3;
  // The block timestamp.
  uint64 ts = 4;
}

// A struct describing a transaction.
message Transaction {
  // The transaction hash.
  bytes hash = 1;
  // The sender of the transaction.
  bytes from = 2;
  // The receiver of the transaction.
  bytes to = 3;
  // The transactions index within the block.
  // TODO: should this be uint32? to match the type from the native substream type?
  uint64 index = 4;
}

// Enum to specify the type of a change.
enum ChangeType {
  CHANGE_TYPE_UNSPECIFIED = 0;
  CHANGE_TYPE_UPDATE = 1;
  CHANGE_TYPE_CREATION = 2;
  CHANGE_TYPE_DELETION = 3;
}

// A custom struct representing an arbitrary attribute of a protocol component.
// This is mainly used by the native integration to track the necessary information about the protocol.
message Attribute {
  // The name of the attribute.
  string name = 1;
  // The value of the attribute.
  bytes value = 2;
  // The type of change the attribute underwent.
  ChangeType change = 3;
}

enum FinancialType{
  SWAP = 0;
  LEND = 1;
  LEVERAGE = 2;
  PSM = 3;
}


enum ImplementationType {
  VM = 0;
  CUSTOM = 1;
}

message ProtocolType{
  string name = 1;
  FinancialType financial_type = 2;
  repeated Attribute attribute_schema = 3;
  ImplementationType implementation_type = 4;
}

// A struct describing a part of the protocol.
// Note: For example this can be a UniswapV2 pair, that tracks the two ERC20 tokens used by the pair, 
// the component would represent a single contract. In case of VM integration, such component would 
// not need any attributes, because all the relevant info would be tracked via storage slots and balance changes.
// It can also be a wrapping contract, like WETH, that has a constant price, but it allows swapping tokens. 
// This is why the name ProtocolComponent is used instead of "Pool" or "Pair".
message ProtocolComponent {
  // A unique identifier for the component within the protocol.
  // Can be e.g. a stringified address or a string describing the trading pair.
  string id = 1;
  // Addresses of the ERC20 tokens used by the component.
  repeated bytes tokens = 2;
  // Addresses of the contracts used by the component.
  // Usually it is a single contract, but some protocols use multiple contracts.
  repeated bytes contracts = 3;
  // Attributes of the component. Used mainly be the native integration.
  // The inner ChangeType of the attribute has to match the ChangeType of the ProtocolComponent.
  repeated Attribute static_att = 4;
  // Type of change the component underwent.
  ChangeType change = 5;
  /// Represents the functionality of the component.
  ProtocolType protocol_type = 6;
  // Transaction where this component was created
  Transaction tx = 7;
}

// A struct for following the changes of Total Value Locked (TVL) of a protocol component.
// Note that if a ProtocolComponent contains multiple contracts, the TVL is tracked for the component as a whole.
// E.g. for UniswapV2 pair WETH/USDC, this tracks the USDC and WETH balance of the pair contract.
message BalanceChange {
  // The address of the ERC20 token whose balance changed.
  bytes token = 1;
  // The new balance of the token.
  bytes balance = 2;
  // The id of the component whose TVL is tracked.  Note: This MUST be utf8 encoded.
  // If the protocol component includes multiple contracts, the balance change must be aggregated to reflect how much tokens can be traded.
  bytes component_id = 3;
}