ERC-2981: NFT 로열티는 어떻게 정의되고 구현되는가

LeeMaimaiLeeMaimai
/2025년 10월 16일
ERC-2981: NFT 로열티는 어떻게 정의되고 구현되는가

주요 결과

• ERC-2981은 NFT 로열티를 정의하는 이더리움 표준입니다.

• 마켓플레이스는 'royaltyInfo' 함수를 통해 로열티를 계산합니다.

• 로열티 강제 집행은 마켓플레이스의 정책에 따라 달라집니다.

• 2023년부터 로열티 강제 집행이 선택 사항으로 전환되고 있습니다.

• 제작자는 하드웨어 지갑을 사용하여 로열티 설정을 안전하게 관리해야 합니다.

NFT 로열티는 제작자와 마켓플레이스 간의 사회적 계약으로 시작되었습니다. 거래가 성숙하고 수수료 모델이 발전함에 따라 업계는 모든 마켓플레이스가 읽을 수 있는 일관된 온체인 방식의 로열티 정보 설명이 필요하게 되었습니다. ERC-2981은 바로 이를 제공합니다. 특정 NFT 판매에 대해 얼마의 로열티가 누구에게 지급되어야 하는지 쿼리하기 위한 최소한의 상호 운용 가능한 인터페이스입니다. 이 글에서는 ERC-2981이 무엇인지, 작동 방식, 구현 시 고려 사항, 그리고 마켓플레이스의 강제 집행 및 제작자 수익화 현황에 대해 설명합니다.

ERC-2981이 실제로 표준화하는 것

ERC-2981은 대체 불가능한 토큰에 대한 단일 함수를 정의하는 이더리움 표준입니다.

  • royaltyInfo(tokenId, salePrice) → (receiver, royaltyAmount)

로열티를 존중하는 마켓플레이스는 판매 시점에 royaltyInfo를 호출하여 지급액을 계산합니다. 이 표준은 지급을 강제하지 않으며, 인터페이스만 설명합니다. 강제 집행은 마켓플레이스의 정책 문제에 달려 있습니다.

주요 설계 선택 사항:

  • 비율 기반: 로열티는 판매 가격에 대한 함수로 계산되며, 일반적으로 기십점(예: 500 = 5%)과 같은 분수를 사용합니다.
  • 수신자 유연성: 로열티 수신자는 제작자의 주소, 멀티시그, 분할 계약 또는 업그레이드 가능한 지급 주소가 될 수 있습니다.
  • ERC-721 및 ERC-1155와 호환: ERC-2981은 일반적인 NFT 표준과 호환되며, 인터페이스 감지를 위해 ERC-165를 사용합니다.

운영 준비가 된 구현을 위해 많은 팀이 OpenZeppelin의 ERC2981을 기반으로 구축합니다.

왜 지금 중요한가

2023년부터 몇몇 선도적인 마켓플레이스는 로열티 강제 집행을 선택 사항으로 전환했습니다. 가장 주목할 만한 변화는 OpenSea가 로열티를 강제하는 장소로 거래를 제한할 수 있었던 Operator Filter를 종료하기로 결정한 것입니다. 자세한 내용은 OpenSea 발표를 참조하십시오. 결과적으로 ERC-2981과 같은 온체인 표준은 강제 집행 방식이 다양함에도 불구하고 플랫폼 전반에 걸쳐 로열티 데이터를 표시하는 기본 방식이 되었습니다.

그 이후로 생태계는 다음과 같은 대응을 했습니다.

  • 마켓플레이스가 로열티 로직을 통일된 방식으로 확인하여 로열티 로직을 해결할 수 있도록 하는 레지스트리 인프라스트럭처, 예: Royalty Registry 및 관련 명세.
  • 온체인 강제 집행 또는 제한을 위한 프로그래밍 가능한 표준, 특히 ERC-721C (Creator Token Standards).
  • 프로토콜 수준 보상 및 제작자 인센티브와 같은 대안적 수익 모델, 예: Zora의 Creator Rewards.

2024-2025년에는 L1 및 L2 네트워크 전반에 걸쳐 ERC-2981 채택이 계속 확산될 것이며, 로열티를 존중하기로 선택한 마켓플레이스는 일반적으로 거래를 정산할 때 이 인터페이스를 쿼리할 것입니다.

인터페이스 작동 방식 (예상치 못한 문제 없이)

판매 시점에 규정을 준수하는 마켓플레이스는 다음을 수행합니다.

  1. ERC-165 (인터페이스 ID 0x2a55205a)를 통해 토큰이 IERC2981을 지원하는지 확인합니다.
  2. royaltyInfo(tokenId, salePrice)를 호출하여 다음을 가져옵니다.
    • receiver: 지급금을 받을 주소.
    • royaltyAmount: salePrice에서 계산된 지급액.

제작자 또는 컬렉션 소유자는 일반적으로 "기본 로열티"를 설정하고 선택적으로 "토큰별 로열티"를 설정합니다. 많은 구현에서 기십점(basis points)에 대한 분모로 10,000을 사용합니다. 마켓플레이스 회계는 판매 수익을 판매자, 프로토콜 수수료 및 로열티 수신자에게 분배합니다.

구현 팁:

  • royaltyInfo에서 되돌리기(revert)를 피하세요. 마켓플레이스는 호출이 실패할 경우 지급을 건너뛸 수 있습니다.
  • 로열티 수신자를 업그레이드 가능하게 유지하세요(예: Ownable 또는 관리자 제어를 통해) 키를 교체하거나 분할 계약으로 마이그레이션할 수 있습니다.
  • 합리적인 최대치로 로열티를 제한하세요(많은 프로젝트가 ≤10% 유지). 이는 2차 시장 유동성을 장려합니다.

간단한 Solidity 예제

아래는 OpenZeppelin을 사용한 간소화된 패턴입니다. 기본 로열티를 설정하고 ERC-165 지원을 재정의하는 방법을 보여줍니다. 프로덕션에서는 접근 제어, 초기화 가드 및 강력한 민팅 논리를 추가해야 합니다.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

import "@openzeppelin/contracts/token/ERC721/ERC721.[sol](https://onekey.so/blog/ko/ecosystem/best-sol-wallets-in-2025-ultimate-guide-to-software-hardware-options/)";
import "@openzeppelin/contracts/token/common/ERC2981.[sol](https://onekey.so/blog/ko/ecosystem/best-sol-wallets-in-2025-ultimate-guide-to-software-hardware-options/)";
import "@openzeppelin/contracts/access/Ownable.[sol](https://onekey.so/blog/ko/ecosystem/best-sol-wallets-in-2025-ultimate-guide-to-software-hardware-options/)";

[contract](https://onekey.so/blog/ko/ecosystem/what-is-a-smart-contract/) MyNFT is ERC721, ERC2981, Ownable {
    uint256 private _nextTokenId;

    constructor([address](https://onekey.so/blog/ko/ecosystem/what-is-a-crypto-wallet-address/) defaultReceiver, uint96 defaultBps)
        ERC721("MyNFT", "MYN")
    {
        // 기본 로열티 설정 (예: 500 = 5%)
        _setDefaultRoyalty(defaultReceiver, defaultBps);
    }

    function mint([address](https://onekey.so/blog/ko/ecosystem/what-is-a-crypto-wallet-address/) to) external onlyOwner {
        _safeMint(to, _nextTokenId);
        _nextTokenId++;
    }

    // 선택 사항: 특별 아이템에 대한 토큰별 로열티 설정
    function setTokenRoyalty(uint256 tokenId, [address](https://onekey.so/blog/ko/ecosystem/what-is-a-crypto-wallet-address/) receiver, uint96 bps)
        external
        onlyOwner
    {
        _setTokenRoyalty(tokenId, receiver, bps);
    }

    // 필수: ERC-165 supportsInterface
    function supportsInterface(bytes4 interfaceId)
        public
        view
        override(ERC721, ERC2981)
        returns (bool)
    {
        return super.supportsInterface(interfaceId);
    }
}

더 자세한 내용은 OpenZeppelin의 ERC2981 가이드를 참조하십시오.

분할, 업그레이드 및 엣지 케이스 처리

실제 로열티 흐름은 단일 수신자인 경우가 드뭅니다. 고려 사항:

  • 분할 계약: 잘 테스트된 인프라스트럭처인 0xSplits를 사용하여 고정된 비율로 여러 당사자에게 수익을 라우팅합니다.
  • 레지스트리 조회: 일부 마켓플레이스는 최신 로열티 데이터를 위해 레지스트리를 참조합니다(Royalty Registry).
  • 업그레이드 가능한 수신자: 키 교체 또는 조직 변경 시 수신 주소를 업데이트할 수 있는 기능을 유지합니다.
  • 토큰별 재정의: 특별 에디션은 기본값에 비해 고유한 로열티율을 가질 수 있습니다.

기술적 참고 사항:

  • 일관된 분모: 오프체인 통합에서 명확성을 위해 기십점(10,000)을 사용합니다.
  • 토큰 유형 인식: ERC-1155 구현은 번들 가격이 아닌 토큰별 판매 가격에 대한 로열티를 계산해야 합니다.
  • 우아한 폴백: 로열티 수신자가 설정되지 않은 경우 0을 반환하여 마켓플레이스 호출 실패를 방지합니다.

마켓플레이스 현실: 신호 대 강제 집행

ERC-2981은 제작자의 의도를 신호합니다. 지급을 강제하지는 않습니다. 각기 다른 장소에서는 다음과 같은 조치를 취할 수 있습니다.

  • ERC-2981을 완전히 존중합니다.
  • 특정 조건 하에서 로열티를 제한하거나 줄입니다.
  • 로열티를 완전히 무시합니다.

이러한 변동성을 고려하여 많은 제작자는 하이브리드 모델을 실험합니다.

  • ERC-721C를 통한 온체인 제한으로 로열티를 존중하는 운영자에게만 전송을 제한합니다.
  • Zora의 Creator Rewards와 같은 프로토콜 수준 보상.
  • 제작자 수익 존중에 대한 커뮤니티 규범 및 사회적 압력.

OpenSea의 2023년 운영자 필터링 종료 결정은 프로토콜 수준 강제 집행보다는 시장 선택으로의 더 넓은 추세를 반영합니다. 자세한 내용은 발표를 참조하십시오. 2024-2025년에는 이러한 균형이 계속될 것입니다. ERC-2981은 로열티 메타데이터에 대한 표준 인터페이스로 남아 있지만, 강제 집행은 분산되어 있습니다.

테스트, 검증 및 모니터링

안정적인 로열티 동작을 보장하려면 다음을 수행하십시오.

  • 인터페이스 지원 확인: 계약이 ERC-165에 따라 supportsInterface(0x2a55205a) == true를 보고하는지 확인합니다.
  • 호출 시뮬레이션: 엣지 판매 가격 및 토큰에 걸쳐 royaltyInfo를 테스트합니다.
  • 인덱싱 호환성: 마켓플레이스 파트너가 의존하는 경우 Royalty Registry와 같은 관련 레지스트리에 계약을 등록합니다.
  • 명확하게 문서화: 구매자와 마켓플레이스의 예기치 않은 상황을 최소화하기 위해 로열티 정책, 제한 및 수신자 로직을 게시합니다.
  • 표준 학습: ERC-2981이 처음이라면 Alchemy의 이 개요가 유용한 입문서가 될 것입니다: ERC-2981이란 무엇인가?.

제작자를 위한 보안 및 키 관리

로열티 구성은 관리자 제어 하에 있습니다. 공격자가 배포자 또는 관리자 키에 액세스할 수 있게 되면 로열티를 다른 곳으로 전환하거나 비활성화할 수 있습니다. 모범 사례:

  • 기본 로열티 설정, 수신자 업데이트 또는 분할 계약 배포와 같은 높은 권한 작업에는 하드웨어 지갑을 사용합니다.
  • 팀 관리 컬렉션에는 멀티시그 설정을 선호합니다.
  • 서명 흐름을 투명하고 감사 가능하게 유지합니다.

보안 및 UX를 저해하지 않으면서 안전하고 이식 가능한 서명을 원하는 제작자와 스튜디오의 경우 OneKey 하드웨어 지갑은 다음을 제공합니다.

  • 오픈 소스 펌웨어 및 투명한 보안 관행을 갖춘 오프라인 개인 키 저장.
  • 계약 배포 및 관리 작업을 위한 일반적인 이더리움 도구와의 원활한 통합.
  • NFT가 L2 또는 여러 EVM 네트워크에서 민팅되는 경우 유용한 크로스체인 지원.

하드웨어 지갑을 사용하여 로열티 설정을 관리하면 손상된 장치나 핫 월렛으로 인해 온체인 수익 신호가 변조되지 않도록 할 수 있습니다.

결론

ERC-2981은 NFT 로열티의 기반 계층입니다. 마켓플레이스가 제작자 지급액을 결정하기 위해 읽을 수 있는 간단하고 보편적인 인터페이스입니다. 이는 강제 집행을 보장하지는 않지만(마켓 정책이 합니다), 신호를 표준화합니다. 강제 집행이 선택 사항이고 진화하는 세상에서 ERC-2981을 레지스트리, 분할 계약 및 ERC-721C와 같은 프로그래밍 가능한 제한과 결합하면 제작자에게 작업을 지속하기 위한 실용적인 도구를 제공합니다.

NFT 컬렉션 또는 제작자 인프라를 관리하는 경우 ERC-2981을 깔끔하게 구현하고 철저히 테스트하며 하드웨어 지갑으로 관리자 키를 안전하게 보호하십시오. 이 조합은 프로젝트가 의존하는 수익 흐름을 보호하면서 마켓플레이스 전반의 상호 운용성을 극대화합니다.

OneKey로 암호화 여정 보호하기

View details for OneKeyOneKey

OneKey

세계에서 가장 진보한 하드웨어 지갑.

View details for 앱 다운로드앱 다운로드

앱 다운로드

스캠 경고. 모든 코인 지원.

View details for OneKey SifuOneKey Sifu

OneKey Sifu

암호화 의문을 해결하기 위해, 한 번의 전화로.

계속 읽기