Hay ventas colectivas en las que el suministro inicial se establece en el momento del despliegue, que se establece en el suministro total definido (por lo que ese número es tantos tokens como habrá) y cuando alguien compra tokens durante la venta colectiva, se transfieren.
Por otro lado, tenemos ventas colectivas donde los tokens se pueden acuñar y el suministro inicial se establece en 0. Entonces, cuando alguien compra tokens, se acuñan y luego se transfieren mientras se incrementa el suministro total. También hay (la mayoría de las veces) un límite máximo para establecer la cantidad máxima de tokens que existirán. Cuando finaliza la venta colectiva, si no se alcanzó el límite máximo, los tokens se acuñarán hasta el límite máximo y se transferirán al equipo.
Entonces, en ambos casos el resultado final es el mismo. ¿Por qué usar tokens mintables y agregar complejidad adicional al código si (por lo que sé) el resultado final es el mismo? (Siempre que, por supuesto, haya un límite máximo y que los tokens no se puedan acuñar después de que finalice la venta colectiva)
//Actualizar:
Aquí hay un ejemplo para ilustrar mi punto: https://github.com/bitclave/crowdsale/blob/057357fecbcc00c9a6cf96831d71d94fb7a13f03/contracts/CATCrowdsale.sol
Entonces, a menos que me esté perdiendo algo, en este caso, por ejemplo, ¿no habría sido lo mismo hacer que el token no se pueda acuñar con el mismo suministro total que el límite máximo? ¿O me estoy perdiendo algo?
Sí, es lo mismo, pero si le das a 10 desarrolladores el mismo problema, podrías obtener 10 formas diferentes de resolverlo.
Sin embargo, es interesante, si lo piensa, Ethereum en realidad recompensa a los usuarios de código más eficiente al cobrar más por soluciones complejas.
ismael