수수료 지불 주소와 실제 이용자: 대납·번들러가 만드는 차이

수수료 지불 주소는 네트워크 비용을 직접 낸 계정이고, 실제 서비스를 이용한 사람이나 비용을 최종 부담한 주체와 다를 수 있습니다. 번들러와 중계자는 여러 요청을 대신 제출할 수 있고 페이마스터는 조건에 따라 비용을 지원할 수 있습니다. 통계에서는 제출자·요청 계정·비용 후원자·최종 고객을 별도 역할로 읽어야 합니다.

수수료를 냈다는 사실은 어떤 역할을 뜻하나요

온체인 활동에서 비용을 지불한 주소를 세는 이유는 단순 수신이나 무료 주소 생성보다 적극적인 참여를 보려는 데 있습니다. 하지만 서비스가 대신 수수료를 내는 구조가 있으면 이 지표가 관측하는 대상이 이용자에서 중개 인프라 쪽으로 이동할 수 있습니다.

우선 네트워크 거래를 제출하고 선불 비용을 낸 주소, 실행을 승인한 계정, 비용을 정산받는 수익자, 서비스 비용을 최종 부담한 고객을 구분합니다. 모든 역할이 하나의 주소에 모일 수도 있지만 반드시 그래야 하는 것은 아닙니다.

예를 들어 서비스가 거래를 먼저 제출한 뒤 고객 잔액에서 별도 요금을 차감한다면 장부에 보이는 수수료 지불 주소와 경제적 부담자는 달라집니다. 공개 체인에 나타나지 않는 내부 정산은 온체인 수치만으로 확인할 수 없으므로 자료의 관측 범위를 밝힙니다.

네트워크에 먼저 비용을 낸 주소를 알아도, 그 비용을 최종적으로 누가 부담했는지는 별도 질문입니다.

JOBCOIN 활동 지표 해설

VISUAL GUIDE거래 요청부터 블록 확인까지

1. 01
   수수료를 냈다는 사실은 어떤 역할을 뜻하나요

   온체인 활동에서 비용을 지불한 주소를 세는 이유는 단순 수신이나 무료 주소 생성보다 적극적인 참여를 보려는 데 있습니다.

2. 02
   번들러는 여러 계정의 요청을 한 거래로 묶습니다

   ERC-4337은 UserOperation이라는 계정 실행 요청과 이를 묶어 EntryPoint 계약에 전달하는 번들러를 설명합니다.

3. 03
   페이마스터가 있다는 사실과 무료 이용은 같지 않습니다

   ERC-4337의 페이마스터 확장은 요청의 비용을 계정 대신 부담하는 계약을 지원합니다.

AI로 제작한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.

번들러는 여러 계정의 요청을 한 거래로 묶습니다

ERC-4337은 UserOperation이라는 계정 실행 요청과 이를 묶어 EntryPoint 계약에 전달하는 번들러를 설명합니다. 블록에 포함되는 최상위 거래와 그 안의 여러 요청은 다른 단위입니다. 최상위 발신 주소만 세면 여러 계정의 활동이 하나로 보일 수 있습니다.

가상 상황에서 계정 30개가 각기 한 번씩 요청하고 번들러 한 주소가 이를 세 거래로 제출했다고 가정합니다. 고유 제출 주소는 하나, 최상위 거래는 세 건, UserOperation은 30개입니다. 어떤 숫자도 실제 사람 30명을 자동으로 입증하지는 않지만 각각 관측한 역할이 다릅니다.

같은 계정이 하루에 열 번 요청하면 요청 수에는 열 번 반영될 수 있지만 고유 계정 수에는 한 번만 들어갑니다. 반대로 한 사람이 여러 스마트 계정을 쓰면 고유 계정 수는 늘어납니다. 활성 주소와 주체를 구분하는 분석과 같은 이유로 사람 수에 대한 표현을 제한해야 합니다.

페이마스터가 있다는 사실과 무료 이용은 같지 않습니다

ERC-4337의 페이마스터 확장은 요청의 비용을 계정 대신 부담하는 계약을 지원합니다. 표준은 EntryPoint에 예치된 비용과 요청 검증 절차를 구분하며, 번들 처리 비용을 받을 수익자도 별도 필드로 둡니다. 이 역할들은 모두 같은 계정이라고 가정해서는 안 됩니다.

앱이 조건을 충족한 사용자에게 비용을 지원할 수도 있고, 별도 토큰이나 서비스 요금으로 정산하는 방식도 가능할 수 있습니다. 어떤 방식인지는 개별 서비스의 계약과 요금 조건을 확인해야 합니다. 페이마스터 주소가 등장했다는 사실만으로 모든 이용이 무조건 무료였다고 적지는 않습니다.

분석에서는 지원된 요청의 비중과 실제 사용자 부담을 별도 항목으로 둡니다. 지원 기간이 끝나면 수수료 지불 주소의 분포나 활동 빈도가 바뀔 수 있습니다. 이런 변화가 사용자 이탈인지 지원 정책 변경인지 구분하려면 해당 시점의 조건과 후속 활동을 함께 보아야 합니다.

중계 거래와 거래소 출금도 비슷한 분리 현상이 있습니다

ERC-2771은 메타트랜잭션의 서명자, 가스 중계자, 신뢰된 전달자, 수신 계약의 역할을 구분합니다. 수신 계약은 신뢰된 전달자가 제공한 원래 서명자 정보를 해석합니다. 따라서 단순히 네트워크 거래의 발신 주소를 읽는 것과 앱이 인식한 요청자를 읽는 것이 달라질 수 있습니다.

이 구조를 분석할 때는 모든 전달 계약을 신뢰된 전달자로 임의 간주하지 않습니다. 해당 수신 계약이 어떤 전달자를 인정하는지와 메시지 검증 범위를 확인해야 합니다. 서명자 필드처럼 보이는 데이터가 있다는 이유만으로 검증된 실제 이용자 정보라고 처리하면 안 됩니다.

거래소의 묶음 출금도 많은 고객 지급을 적은 거래와 지갑으로 처리할 수 있습니다. 여기서는 거래소 내부 고객 계정 자료가 공개 체인에 모두 드러나지 않습니다. 트랜잭션 배칭을 함께 읽으면 기록 수 감소가 곧 이용 감소를 뜻하지 않는다는 점을 이해하기 쉽습니다.

수수료 주소 통계를 다시 만들 때 필요한 연결 키

분석용 원시 기록에는 체인, 최상위 거래 해시, 요청 식별자, 요청 계정, EntryPoint 또는 전달 계약, 비용 지원 정보를 나눠 보관합니다. 같은 주소 문자열이 다른 체인에서 쓰일 수 있으므로 주소만을 전 세계 유일 키로 사용하지 않습니다.

한 번의 수집 응답에 같은 요청이 중복으로 들어오거나 재처리된 경우에는 고유 식별자로 중복을 제거합니다. 최상위 거래가 성공했다고 내부 요청이 모두 같은 결과를 냈다고 가정하지 말고 요청별 결과를 확인합니다. 추출하지 못한 항목은 추정값으로 채우기보다 미확인으로 표시합니다.

일반 거래와 대납 거래를 함께 세려면 범주별 원시값을 먼저 제시합니다. 이후 합계를 만들더라도 어떤 단위를 합쳤는지 명확해야 합니다. 고유 번들러 수와 고유 스마트 계정 수를 단순히 더하면 서로 다른 역할을 하나의 사용자 수로 합쳐 버릴 수 있습니다.

• 제출 주소와 요청 계정, 비용 지원 계약을 별도 열에 둡니다.
• 네트워크 비용과 서비스의 최종 요금 조건을 구분합니다.
• 체인과 계약 버전 및 요청 식별자를 함께 기록합니다.
• 요청별 성공 상태와 중복 수집 여부를 확인합니다.
• 대납 정책 변경 전후를 같은 집계 기준으로 비교합니다.

집중도와 사용자 규모는 따로 결론을 냅니다

소수 번들러에 제출이 집중돼 있다면 인프라 의존도를 설명하는 자료가 될 수 있습니다. 그러나 그것만으로 앱 사용자가 적다고 결론 내릴 수는 없습니다. 반대로 많은 제출 주소가 보인다고 운영 주체가 모두 독립적이라고 단정할 수도 없습니다.

독자를 위한 문장은 역할을 붙여 작성합니다. ‘수수료 제출 주소가 줄었다’, ‘고유 요청 계정이 늘었다’, ‘대납 요청 비중이 높아졌다’는 각각 검증 가능한 다른 주장입니다. 변화의 이유를 하나의 성장률로 뭉치지 않으면 서비스 설계가 바뀌어도 자료를 일관되게 읽을 수 있습니다.

자주 묻는 질문