O velho ditado diz mais ou menos assim: “rápido, barato e bom. Escolha dois”. Existem até diagramas de Venn bem legais por aí. Como este aqui 🙂

Essa ideia costuma ser considerada senso comum e se aplica muito bem à maioria das coisas. Ela sempre surge no contexto de tipos de transferência e de vários provedores de pagamento. É muito conveniente recorrer a ela, mas todos nós fazemos isso.
No contexto dos sistemas de pagamento tradicionais, é comum chegar perto dos três, embora não se atinja totalmente. As comparações de rapidez geralmente vão de dias a segundos, e a comparação de custo costuma ser uma taxa percentual em relação a um custo fixo baixo. Nesse contexto, ainda faz sentido. Até mesmo “bom” pode ser entendido como experiência do usuário ou segurança, aspectos que variam entre os provedores. Nos pagamentos, isso acaba se configurando assim com bastante frequência, pois sabe-se que interfaces de usuário ruins simplesmente perdem:

Bom, rápido e barato quase parecem requisitos mínimos quando se analisa pagamentos no contexto de uma cadeia. No contexto de uma cadeia, ao pensar em pagamentos, a segurança é obrigatória no que diz respeito ao gerenciamento de chaves, tudo tem custo fixo que varia de dólares a menos de um centavo, e as transações são concluídas em minutos ou segundos.
Não há considerações de prazo aqui, então a diferença na velocidade é significativa. A situação começa a se parecer mais com isto quando se comparam os sistemas tradicionais aos novos sistemas baseados em cadeias de blocos, se implementados corretamente:

A forma como a segurança é aplicada, como as taxas variam e como a velocidade cria novos riscos merecem consideração nesses novos ecossistemas de pagamento, mas esses são problemas tecnicamente gerenciáveis.
Nos sistemas antigos, lidamos com arquivos em lote não criptografados como ponto de partida. Nos novos sistemas, lidamos com um gerenciamento de chaves razoavelmente complexo logo de início. Ainda há questões de segurança a serem tratadas de qualquer maneira, mas a responsabilidade recai sobre os provedores em ambos os cenários, e são problemas tecnicamente solucionáveis.
Nos sistemas antigos, ficamos discutindo minúcias sobre dias x horas x minutos em termos de velocidade e, às vezes, passamos anos desenvolvendo soluções para chegar a segundos. Nos novos sistemas, tudo se resume a segundos. Na pior das hipóteses, são minutos.
Nos sistemas antigos, estamos negociando acordos de preços (como diz um velho amigo) na tentativa de tirar sangue de uma pedra para recuperar uma porcentagem maior, e nos novos sistemas, tudo se resume a dólares e centavos, além de ser instantâneo e seguro, se implementado corretamente.
Parece que as coisas estão melhorando, afinal.