ERC-2981은 NFT가 royaltyInfo(tokenId, salePrice)로 로열티를 받을 주소와 금액을 알려 주는 조회 표준입니다. 돈을 옮기는 방법은 정하지 않으며, 원문은 지급이 자발적이라고 분명히 적습니다. 이 글은 2026-10-27에 연 ERC-2981 원문(상태 Final)으로 확인한 범위만 다룹니다.
확인 기준일 2026-10-27 · 다음 확인 예정 2026-11-26
왜 지급을 강제하지 못할까?
원문은 어떤 이전이 판매이고 어떤 이전이 단순한 지갑 간 이동인지 알 수 없어서, transferFrom 같은 이전 함수에 지급을 묶을 수 없다고 설명합니다. 마켓플레이스가 이 표준을 구현하지 않으면 재판매 때 지급되는 돈이 없다고도 적습니다. 그래서 이 표준은 정보를 조회하는 약속에 머뭅니다. 보안 고려사항에는 이 표준 구현과 직접 관련된 것이 없다고 적혀 있습니다. 이전 표준 자체는 ERC-721과 ERC-1155 글에 정리되어 있습니다.
| 항목 | 원문 내용 |
|---|---|
| 함수 | royaltyInfo(uint256 _tokenId, uint256 _salePrice) external view returns (address receiver, uint256 royaltyAmount) |
| 인터페이스 ID | ERC-165용 0x2a55205a |
| 금액 단위 | _salePrice와 royaltyAmount는 같은 통화 단위 |
| 계산 방식 | 판매가에 대한 비율, 나머지는 올림·내림 모두 허용 |
| 수령인 | 한 주소, 분배·세금 처리는 수령 쪽 몫 |
금액은 어떻게 계산해야 할까?
구현자는 판매가의 비율로 계산해야 합니다. 판매가를 무시한 고정 금액을 돌려주거나 판매가를 상수와 비교해 정하는 방식은 거래 단위를 가정하게 되므로 금지됩니다. 비율이 10%라면 판매가가 10이든 1234567890이든 같아야 하고, 999의 10%는 99 또는 100 모두 유효합니다. 비율이 아닌 금액을 돌려주는 이유는 지급 시점이 늦어져도 얼마를 줄지 다툼이 없게 하려는 것입니다. 시간에 따라 선형으로 줄이는 것처럼 예측 가능한 변수는 쓸 수 있지만 block.timestamp 같은 변수는 쓰지 않도록 권고합니다.
마켓플레이스는 무엇을 확인할까?
먼저 supportsInterface(0x2a55205a)로 지원 여부를 묻는 방식이 원문 예시에 나옵니다. 이 방식의 한계는 ERC-165 인터페이스 확인 글에서 다룹니다. 표준을 지원하겠다는 마켓플레이스는 온체인, 장외, 경매 같은 오프체인 판매를 가리지 않고 지급해야 하며, 금액이 0이면 0 전송 거래를 보내지 않도록 권고합니다. 지급과 통지 방식은 이 표준에 없고 이후 EIP에서 정하겠다고 적습니다.
자주 묻는 질문
NFT를 팔면 로열티가 자동으로 빠지나요?
아닙니다. 이 표준은 금액과 수령인을 알려 줄 뿐이고, 실제 전송은 마켓플레이스가 실행해야 한다고 원문이 적습니다.
수령인이 여럿일 수 있나요?
반환값에는 수령 주소가 하나뿐입니다. 원문은 분배와 세금, 회계 같은 복잡한 처리는 수령 컨트랙트나 오프체인 절차가 맡는다고 설명합니다.
ERC-721에서만 쓸 수 있나요?
아닙니다. ERC-721과 ERC-1155 컨트랙트가 구현할 수 있지만, 자산을 고유하게 식별할 수 있는 다른 컨트랙트도 쓸 수 있다고 원문이 적습니다.
