AuroraComprenda su contrato de colección
Cómo las colecciones ERC-721 -C y ERC-1155 -C de Aurora manejan la propiedad, los pagos, las obras de arte, el comercio y regalías.
En esta página
Referencia de función de contrato
Cada función de colección legible y escribible, con argumentos, permisos y acciones unidireccionales explicadas. Elija su tipo de colección.
Dos tipos de colección, el mismo creador controla
Los estándares C agregan validación de transferencia para las políticas de tarifas del mercado compatible Creator. Ambos tipos de colección tienen controles de propietario para acuñación, metadatos, regalías y comercio. La red gas , los precios de las obras de arte y las tarifas de la plataforma son costos separados.
| Tipo de colección | Cómo funcionan los tokens |
|---|---|
| ERC-721-C · Unique NFTs | Cada obra de arte acuñado tiene su propio identificador de token y un propietario. |
| ERC-1155-C · Editions | Una obra de arte tiene un identificador de token con varias copias. Los coleccionistas pueden tener más de una copia de esa edición. |
Su cartera es dueña de la colección
Para las nuevas colecciones nativas acuñar, el monedero que despliega la colección se convierte en su propietario. La fábrica de Aurora implementa el contrato; no se convierte en el administrador de la colección. Elegir la billetera de pago de un artista no le da permisos al propietario de esa billetera.
El propietario puede configurar las versiones y regalías, pausar o cerrar permanentemente acuñación, publicar revisiones de metadatos, permitir el comercio y retirar los ingresos retenidos de acuñar. La transferencia de propiedad utiliza dos pasos: el propietario existente nomina una nueva billetera y esa billetera acepta. Una revelación programada pendiente debe completarse o cancelarse antes de que cambie la propiedad.
Algunas colecciones más antiguas usan un controlador separado acuñar. En esa configuración, el controlador posee la colección y su billetera propietaria administra el acuñar. Compruebe las direcciones del contrato y el propietario para su implementación particular.
Elige cuándo recibirá tu artista acuñar pagos
Solo el precio de la obra de arte va a la billetera acuñar procede. La tarifa de la plataforma del Aurora se procesa por separado. Las obras de arte gratuitas no tienen pago de Creator, aunque las tarifas de la plataforma y gas aún pueden aplicarse. La reventa regalías se configura por separado.
El propietario puede cambiar el modo o la cartera de recepción para el futuro mints de una versión abierta. Aurora pausa la liberación mientras aplica el cambio, luego restaura su estado de pausa anterior. Los ingresos retenidos previamente permanecen disponibles para retiro; cambiar al pago directo no envía automáticamente ese saldo anterior.
El pago directo requiere una billetera o contrato que acepte la moneda nativa de la red. Si rechaza el pago, todo el acuñar se revierte, incluyendo el NFT y la transferencia de cuota de plataforma. Una transacción minada fallida todavía puede costar gas. El propietario puede corregir la billetera receptora o cambiar al modo de retiro antes de volver a intentarlo.
Establecer el acuñar procede cartera
Introduzca la billetera que debe recibir el precio de la obra de arte. Esta puede ser la billetera del artista y no necesita ser su billetera de implementación.
Elija acuñar procede el pago
Enviar a la cartera después de cada acuñar es el valor predeterminado para las nuevas versiones en colecciones compatibles. El contrato reenvía el precio de la obra en la misma transacción que el acuñar. Elija Mantener en el contrato de retiro para acumular ganancias en su lugar.
Publicar y aprobar la configuración
Revise la dirección de recepción y firme las transacciones de billetera requeridas. Aurora muestra los pasos de aprobación. Los ajustes de pago se registran en la cadena antes de que se abra la versión.
¿Quién puede retirar los ingresos retenidos?
Solo el propietario del contrato acuñar puede autorizar un retiro. Aurora llena la cartera guardada de acuñar como el destinatario. El propietario también puede llamar al retiro manualmente con el destinatario elegido y la cantidad. La billetera guardada no es una restricción irreversible a la autoridad de retiro del propietario.
Los ingresos retenidos se mantienen en en la cadena en el controlador de colección o legado. Aurora no los tiene en una cuenta offchain. El saldo de los ingresos puede incluir múltiples liberaciones. Puede retirarse mientras acuñación está activo, en pausa o terminado.
Arte, metadatos y revelación
El propietario controla las actualizaciones de metadatos después de acuñar. No hay un interruptor de congelación separado solo de metadatos. Una referencia de archivo inmutable identifica una versión fija, pero el propietario puede publicar una nueva referencia. Renunciar a la propiedad elimina permanentemente esta capacidad junto con cualquier otro control del propietario.
Esta flexibilidad es compatible con el mantenimiento a largo plazo: los creadores pueden corregir metadatos o pasar a otro proveedor de almacenamiento compatible si un proveedor no está disponible. El nuevo ERC-721 -C 0.6 y ERC-1155 -C 0.3 construye aceptar esquemas URI sin una lista de permisos de protocolo, incluyendo IPFS, HTTPS y futuros esquemas de almacenamiento. Los contratos más antiguos mantienen sus restricciones originales. Las cargas Aurora todavía usan IPFS; cambiar a otro proveedor actualmente requiere una transacción de propietario a través de una interfaz de contrato.
Una referencia no es una garantía de alojamiento. El contenido HTTPS puede cambiar en la misma dirección, y los futuros esquemas de almacenamiento necesitan el soporte de billeteras y mercados para mostrarlos. Los directorios de metadatos deben terminar con una barra y proporcionar archivos JSON decimales; el contrato no verifica que un proveedor esté en línea.
La revelación retrasada inicialmente muestra obras de arte de marcador de posición. En Aurora, Reveal programado y Force revelan tanto el final de la versión actual como la publicación de su obra de arte comprometida a través de aprobaciones de monedero del propietario; la cuenta atrás no envía una transacción por sí misma. La revelación de fuerza se puede usar antes del tiempo planeado, incluso después de que acuñación se haya detenido o haya terminado. Después de la confirmación, la cuenta atrás desaparece. Para acuñar más tarde, elija Agregar otra versión y establecer nuevas fases, fechas y precios en la misma colección; la colección en sí no está cerrada permanentemente.
Comisiones de trading y creación
Antes del primer acuñar, elija si el comercio comienza con ese acuñar o se habilita manualmente más tarde. Habilitar el comercio es una forma: las transferencias no se pueden bloquear nuevamente con el interruptor de comercio. Pausa acuñación no pausa el comercio ya habilitado.
El receptor y el porcentaje de regalía describen los pagos de venta secundaria regalías, no los pagos primarios acuñar. regalías tienen un tope de 10% . La aplicación depende de la política de validación seleccionada y la ruta comercial compatible del mercado; ERC-721 -C o ERC-1155 -C solo no es una promesa de que cada reventa pague regalías .
Desde ERC-721 -C 0.6.0 -beta. 2 y ERC-1155 -C 0.3.0 -erc1155-beta. 2 en adelante, el propietario de la colección puede reemplazar el validador de transferencia activo por updateTransferValidator, por ejemplo, al migrar a una actualización de seguridad revisada. Esto cambia la validación de la transferencia, no la implementación de la colección. Las colecciones desplegadas más antiguas conservan sus restricciones originales.
Configurar el validador a 0x0000000000000000000000000000000000000000 desactiva las comprobaciones del validador. El propietario puede restaurar el validador anterior o elegir un reemplazo más tarde. Mientras está deshabilitado, la aplicación basada en validador regalía y otras restricciones de validador se detienen. El destinatario y el porcentaje de regalía permanecen registrados; los mercados aún pueden honrarlos voluntariamente. Las aprobaciones de los titulares, las tarifas de la plataforma gas, acuñar y el bloqueo de operaciones de cobro aún se aplican.
Reemplace, deshabilite o restaure un validador de transferencia
Esta es actualmente una transacción de propietario a través del explorador de bloques de la colección, como Basescan. Utilice la dirección de colección y su interfaz de contrato verificada, incluyendo Leer como proxy o Escribir como proxy si se muestra. El setTransferValidator heredado permanece bloqueado para llamadas directas: use updateTransferValidator .
Antes de reemplazarlo, verifique que el nuevo validador sea confiable, admita su estándar de token y funcione con las rutas de mercado previstas en esta cadena. Tener un código de contrato por sí solo no establece compatibilidad. El registro de tipo token se intenta automáticamente, pero las políticas de seguridad y las listas de operadores no migran automáticamente; configúrelas y verifíquelas con las herramientas compatibles del nuevo validador.
Registre el validador actual
Leer propietario y getTransferValidator en su colección. Guarde la dirección actual del validador para que pueda restaurarla si es necesario. El getter de validador independiente registra la vinculación de implementación inicial y no realiza un seguimiento de los cambios posteriores.
Elija la nueva configuración
Conecte la billetera del propietario de la colección. Abra updateTransferValidator e introduzca la dirección de reemplazo compatible. Para desactivar la validación, ingrese la dirección completa cero: 0x0000000000000000000000000000000000000000 . No deje el campo en blanco o escriba la palabra null.
Confirmar y verificar
Revise y confirme la transacción de la billetera. Después de la confirmación, vuelva a leer getTransferValidator y verifique que coincida con la configuración prevista. Cero significa desactivado.
Restaurar después de una desactivación temporal
Llame nuevamente al updateTransferValidator con la dirección guardada o de reemplazo, verifique su política y pruebe la ruta de transferencia prevista. Reemplazar un validador no lo aprueba automáticamente para mover los NFT de los titulares.
Renunciar permanentemente a los controles del propietario
Las nuevas construcciones proporcionan renounceOwnership como una acción final e irreversible. Establece el propietario a la dirección cero y borra cualquier transferencia de propiedad pendiente. Ni el Aurora ni el propietario anterior pueden restaurar el control después.
Antes de renunciar, termine sus metadatos y la configuración regalía, cierre permanentemente acuñación, permita el comercio, retire todos los ingresos retenidos y complete o cancele la revelación pendiente. El contrato rechaza la renuncia hasta que se cumplan esas condiciones. La cancelación de una revelación no publica ilustraciones finales: no renuncie mientras los tokens aún necesitan una actualización de metadatos.
La renuncia es actualmente una transacción manual a través de la interfaz del explorador de la colección. Evita futuros cambios de propietario en los metadatos, regalías, la configuración de pago y los controles acuñar. No hace que el contenido de un servidor web sea inmutable ni congela las políticas de validación externa, y elimina su capacidad para realizar la administración del validador que requiere la propiedad de la colección.
¿Qué pasa si Aurora no está disponible?
acuñado NFT y sus registros de propiedad permanecen en la cadena de bloques. El contrato implementado existe independientemente del sitio web de Aurora. Los propietarios pueden usar las funciones de contrato compatibles a través de un explorador u otra interfaz. La disponibilidad de obras de arte y la visualización en el mercado también dependen del almacenamiento y los servicios del mercado.
El público acuñación en estas compilaciones requiere una autorización de tarifa firmada Aurora, incluso cuando no se aplica la tarifa de la plataforma. Por lo tanto, un servicio de firma no disponible puede detener el nuevo público mints. Esa autoridad firmante no puede usar funciones solo de propietario, tomar propiedad de colección o retirar los ingresos del creador.
La colección utiliza una implementación fija y no se puede actualizar. Las nuevas características y correcciones de código requieren nuevas implementaciones; los tokens existentes no se mueven o actualizan automáticamente. Las pruebas de seguridad locales y la revisión del código no son una auditoría de seguridad independiente ni una garantía de seguridad.