anchor.diff:  para guardar la metadata de las transacciones crypto y otra para la metadata de las transacciones fiat.
   A estas dos tablas se le suman la de eventos y la de transacciones de la red crypto. +
   Para cada monitor agent deberá haber un método que consulte la tabla de eventos trayendo el siguiente
  -evento pendiente para el agente particular que consulta, es decir que si consulta el CryptoMonitorAgent
  +evento pendiente para el agente particular que consulta; es decir que si consulta el CryptoMonitorAgent
   entonces se le debe dar un evento con source Crypto Transmission Network Service; si consulta el
   FiatMonitorAgent entonces se le debe dar un evento con source Money Transmission Network Service; y
   si consulta el MonitorAgent entonces se le debe dar un evento con source Incoming Crypto.
  
positive.code: red crypto a través del Incoming Crypto, la espera de la metadata es necesaria para poder aplicar las
  actualizaciones del balance. +
  Lo que haremos será que el método que llama el relay agent que consulta las transacciones en estado
  (RESPONSIBLE, TO_BE_APPLIED), es decir el método getResponsibleTBATransactions retornará sólo las
  transacciones en ese estado que además tengan la metadata sincronizada. De esta manera el problema
  queda reducido al problema que hemos resuelto en la lógica del Incoming Extra User.
  
  Para obtener la información eficientemente podemos colocar una tabla que relaciona la tabla que almacena
  las transacciones crypto con el tipo de metadata que se detectó asociada a esa transacción. Visto con
  más detalle, cuando llega un mensaje con metadata de un transacción fiat registramos en esta tabla el
  par (hash de la transacción crypto asociada, FIAT_TRANSACTION) y si llega una la metainformación de lo
  que sería una transacción crypto entre intra users colocaremos un registro (hash de la transacción crypto
  asociada, CRYPTO_TRANSACTION). +
  La manera de utilizar esta tabla será que cuando se piden las transacciones de las que uno es responsable
  se consultará qué transacciones en estado (RESPONSIBLE, TO_BE_APPLIED) tinen su hash asociado en esta
  tabla. +
  Requeriremos un método para saber si una transacción es FIAT_TRANSACTION o CRYPTO_TRANSACTION (u otro
  tipo futuro) para que a la hora de aplicar las transacciones pidamos la metadata asociada y podamos
  trabajarla. +
  
  Como un agregado, este plugin deberá llamar a los métodos `informTransactionSeenByVault` e
  `informTransactionCreditedInWallet` del network service MoneyTransmission cuando se trate
  
negative.code: == Documentación
  
  Al recibir un pago desde un intra user tenemos que coordinar la información que llega a través de la
  red crypto con la metadata de la transacción. El Crypto Router nos envía la información de las
  transacciones crypto. Por otro lado, diversos network services especializados nos enviarán la
  información de la metadata. +
  Para este Milestone, esta metadata puede ser metadata de crypto (se da cuando un Intra User nos envía
  una transacción crypto) o de fiat (se da cuando un Intra User nos envía una transacción de Fiat over
  