NARU기술 문서v0.1
예정표시가 없는 항목은 현재 작동한다. 아직 아닌 것만 표시한다.

기술 문서

대금을 먼저 예치하고, 판정 규칙을 해시로 고정하고, 성과가 확인되면 컨트랙트가 지급을 실행한다.

v0.1 · 2026-08-27

개요

확인된 성과만큼만 지급하는 광고 정산 레이어#

광고주가 대금을 먼저 컨트랙트에 예치한다. 판정 규칙은 예치와 동시에 해시로 고정되어 이후 변경할 수 없다. 성과가 확인되면 컨트랙트가 지급을 실행하며, 광고주의 별도 승인 절차는 없다.

에스크로
캠페인이 열리는 순간 전액이 컨트랙트로 옮겨진다
규칙 고정
캠페인을 열 때 판정 기준이 해시로 고정된다
자동 지급
조건이 충족되면 사람이 승인하지 않아도 지급된다
가스비
크리에이터는 트랜잭션을 보내지 않는다
미지급분 반환
마감 + 정산 유예기간이 지나야 광고주가 회수할 수 있다
지금은 GIWA Sepolia 에서 작동한다. 테스트넷이고, 쓰는 토큰도 테스트용 ERC-20 이다. 메인넷에는 아직 배포하지 않았다.
개요

성과형 계약이 자리잡지 못한 이유#

인플루언서 마케팅에서 성과형 계약이 자리잡지 못한 원인은 측정이 아니라 이행에 있다. 조건을 측정할 수는 있어도, 그 조건대로 지급되도록 강제할 수단이 없었다.

01
이행 보증이 없다
약속대로 지급된다는 보장도, 게시된다는 보장도 없다
예치가 여기를 막는다 — 이행이 보증되면 다음으로 넘어가지 않는다
02
성과형 계약을 못 쓴다
조건부로 묶을 수단이 없으니 선불이냐 후불이냐만 남는다
03
팔로워 수로 값을 매긴다
성과에 값을 매길 수 없으니 눈에 보이는 숫자가 가격이 된다
04
팔로워 수를 부풀린다
가격이 숫자로 정해지니 숫자를 늘릴 이유가 생긴다
그리고 처음으로 돌아온다. 부풀린 숫자가 결과를 못 믿게 만들고, 못 믿으니 선불도 못 준다.
네 가지가 순서대로 이어지고, 마지막이 다시 처음을 만든다. 하나만 고쳐서는 멈추지 않는다.
상황실제로 일어나는 일
광고주 → 크리에이터선불로 주면 게시하지 않을 위험. 그래서 후불을 고집한다
크리에이터 → 광고주만들고 게시했는데 “마음에 안 든다”며 지급을 거부당한다
국경을 넘으면계약서가 있어도 소송이 사실상 불가능하다. 회수 비용이 계약 금액을 넘는다

계약서는 분쟁이 발생한 뒤에 작동하는 장치라 위 세 경우 모두에 대응하지 못한다. NARU 는 자금을 사전에 예치하고, 조건이 충족되면 별도 승인 없이 지급되는 방식을 택했다.

개요

예치에서 지급까지#

캠페인 한 건이 시작해서 끝날 때까지 실제로 일어나는 일이다. 각 단계는 온체인에 기록이 남는다.

  1. 01
    예치
    광고주가 캠페인을 열면서 전액을 컨트랙트로 옮긴다. 예치 없이는 캠페인이 열리지 않는다.
  2. 02
    공개
    제목·규칙·지급 항목이 광고주 지갑으로 서명한 공개 기록(어테스테이션)으로 체인에 올라간다. 읽는 쪽이 우리 서버를 믿지 않고도 대조할 수 있다.
  3. 03
    참여
    크리에이터가 자격을 확인받고 참여한다. 자격 조건은 예치 때 정해져 이후 바뀌지 않는다.
  4. 04
    검수
    게시 전에 원고가 규칙에 맞는지 확인한다. 통과한 원고는 게시 후에 번복되지 않는다.
  5. 05
    관측
    게시물을 서버가 직접 읽고, 체인에 고정된 규칙으로 다시 판정한다.
  6. 06
    지급
    오라클이 판정 결과를 체인에 올리고 컨트랙트가 금액을 계산해 보낸다. 크리에이터는 가스를 내지 않는다.

누구의 차례인가

01
예치
02
공개
03
참여
04
검수
05
관측
06
지급
광고주
크리에이터
오라클
온체인
이 단계를 실행한다관여한다
같은 여섯 단계를 네 주체가 나눠 맡는다. 크리에이터가 트랜잭션을 보내는 단계는 없다.
프로토콜

지급액 계산#

컨트랙트는 앱 설치나 리포스트 500회가 무엇인지 알지 못한다. 조건 충족 여부는 컨트랙트 바깥에서 판정하고, 컨트랙트는 그 결과를 금액으로 환산한다.

지급액 = min(검증된 수량, 남은 상한) × 단가

그래서 새 캠페인 유형을 추가해도 컨트랙트를 다시 배포하지 않는다. 어테스테이션 스키마만 등록하면 된다.

지급 판정 순서

  1. 01캠페인 유효성 — 취소되지 않았고, 마감 + 정산 유예기간 안이고, 항목이 존재하는가
  2. 02검증 경로 분기
  3. 03참여 자격 — 자격 조건이 걸린 캠페인일 때만
  4. 04동결 여부
  5. 05수량 상한 — 한 사람에게 남은 만큼까지만
  6. 06금액 계산
  7. 07예산 상한 — 항목에 남은 만큼까지만
  8. 08상태 변경 — 누적 수량·집행액·어테스테이션 사용 표시
  9. 09자금 이체

2번 — 검증 경로 분기

지급 요청
검증자가 지정돼 있으면
그 검증자가 판정한다
온체인 직접 조회처럼 항목에 지정된 방식으로 넘긴다
지정돼 있지 않으면
어테스테이션을 검증한다
기본 경로. 컨트랙트가 아홉 항목을 확인한 뒤에만 통과시킨다
여기서부터는 두 경로가 같다 — 참여 자격 · 동결 여부 · 수량 상한 · 금액 계산 · 예산 상한 · 상태 변경 · 이체.
아홉 단계 중 갈리는 곳은 여기 한 곳뿐이다.

5번과 7번 — 상한에 두 번 걸린다

판정 순서 5 — 수량 상한
검증된 수량
이 사람에게 남은 상한
min
지급 수량
검증된 수량이 상한을 넘으면 남은 만큼만 지급된다
판정 순서 7 — 예산 상한
지급 수량 × 단가
항목에 남은 예산
min
실제 지급액
예산이 바닥나면 계산된 금액보다 적게 나간다
계산식 한 줄에는 두 번째 상한이 안 보인다. 곱한 뒤에 항목 예산에 한 번 더 걸린다.
8번(상태 변경)이 9번(이체)보다 먼저다. 재진입 공격을 막는 순서이고, 재진입 가드도 따로 적용한다.
프로토콜

캠페인 생성#

광고주가 캠페인을 만들 때 무엇을 정하고, 그중 무엇이 이후 바뀌지 않는지다. 마지막 단계에서 서명 두 번으로 예치가 끝나고, 그 순간 판정 기준이 확정된다.

일곱 단계

  1. 01
    목표
    무엇을 얻고 싶은지 먼저 고른다. 고르면 뒤 단계의 지급 항목·단가·확인 경로가 초안으로 채워진다.
  2. 02
    캠페인 정보
    이름·제품·모집 기간·모집 인원. 이름과 소개는 체인에 공개돼 크리에이터가 대조할 수 있다.
  3. 03
    타겟
    전체 공개로 열지, 참여 조건을 걸지 정한다. 조건은 이 단계에서만 정할 수 있다.
  4. 04
    정산 수단
    어느 토큰으로 지급할지. 시세가 움직이는 토큰은 예치하는 순간 수량이 고정된다.
  5. 05
    지급 항목
    어떤 성과에 얼마를 지급할지 고른다. 항목 예산의 합이 곧 예치 금액이다.
  6. 06
    브리프
    필수 문구·금지 표현·톤·유지 의무를 적는다. 검수와 지급 판정이 모두 이 글을 기준으로 이뤄진다.
  7. 07
    검토와 예치
    서명 두 번 — 토큰 사용 승인과 캠페인 생성. 두 번째가 끝나면 전액이 컨트랙트로 옮겨진다.

예치와 동시에 확정되는 것

광고주가 사후에 조건을 변경하는 경로가 구조적으로 차단된다. 원문은 체인 밖에 두고 해시만 올리므로, 당사자는 원문을 받아 해시를 다시 계산해 대조할 수 있다.

값확정 시점이후 변경
판정 규칙캠페인을 열 때불가
참여 자격 조건캠페인을 열 때불가 — 바꾸는 함수 자체가 없다
예산캠페인을 열 때증액만 가능
지급 항목별 원고 기준항목을 추가할 때불가

정산 유예기간

마감이 지나도 즉시 회수할 수 없다. 전환을 30일까지 성과로 인정하는 캠페인이라면 마감 직전에 일어난 전환은 판정이 늦게 나온다. 유예기간이 없으면 광고주가 마감 직후 미지급분을 회수해 크리에이터가 이행하고도 받지 못하는 경우가 생긴다. 그래서 유예기간은 성과를 인정하는 기간보다 길게 둔다(권장 30일 이상).

캠페인 진행
시작 ~ 마감
성과 인정
지급
광고주 회수
정산 유예기간
마감 ~ 유예기간 끝
성과 인정
지급
광고주 회수
종료
유예기간 이후
성과 인정
지급
광고주 회수
마감 직전에 일어난 전환은 판정이 여기까지 늦어진다. 유예기간을 그보다 길게 둔다.
마감 뒤에도 지급은 계속된다. 마감으로 멈추는 것은 새 성과 인정이고, 회수는 그보다 더 뒤에 열린다.
프로토콜

검증 방식과 신뢰 구조#

오프체인 사실을 온체인으로 옮기는 이상 누군가는 보고 주장해야 한다. 그래서 질문은 신뢰를 없앨 수 있나가 아니라 항목마다 신뢰를 어디까지 줄일 수 있나다. NARU 는 검증 방식을 지급 항목마다 교체할 수 있게 설계했다.

컨트랙트가 보장하는 것

  • 예치 없이는 캠페인이 열리지 않는다
  • 규칙은 생성 후 변경 불가
  • 광고주는 유예기간 전에 회수할 수 없다
  • 같은 판정 기록을 두 번 쓸 수 없다

검증 방식은 항목마다 교체된다

지급 항목마다 검증자를 지정한다. 지정하지 않으면 기본 경로를 쓴다. 검증자를 바꾸는 데 컨트랙트 재배포가 필요 없다. 항목의 필드 하나만 바꾸면 된다.

지급 항목
앱 설치·거래량·게시물처럼 값을 매기는 단위 하나
검증자
오라클 판정현재 가능
오라클 한 곳의 판정을 믿어야 한다 — 지금 쓰는 기본 경로
한 곳
M-of-N 서명추후 지원
N 곳 중 M 곳이 담합해야 판정이 뒤집힌다
여러 곳
영지식 증명추후 지원
원본을 공개하지 않고 조건 충족만 증명한다
증명
온체인 직접 조회추후 지원
컨트랙트가 체인을 직접 읽는다 — 믿을 곳이 남지 않는다
없음
검증자는 지급 항목마다 따로 지정한다. 아래로 갈수록 믿어야 할 곳이 줄어든다.
1차 대상이 Web3 KOL 이라는 점이 여기서 유리하게 작용한다. 이들이 만드는 성과 — 지갑 생성, 예치, 거래량 — 는 대부분 온체인에 있다. 온체인 직접 조회를 붙이면 그 항목에서는 오라클 신뢰가 사라진다. 오라클이 남는 것은 웹 데이터 (커머스 주문·앱 설치)뿐이고, 그쪽은 M-of-N 을 쓴다.

기본 경로에서 판정을 검증하는 방법

규칙 해시
규칙이 사후에 바뀌지 않았음을 대조할 수 있다
원본 해시
판정에 쓴 원본을 해시로 고정한다. 제3자가 같은 곳을 다시 조회해 맞춰 볼 수 있다
출처 표기
공식 API 로 읽었는지 화면에서 수집했는지가 남는다
판정 무효화
사후에 사기가 드러나면 판정을 무효로 되돌리고 그 이력도 남는다

남는 신뢰

오라클
기본 경로를 쓰는 항목에서 “조건이 충족됐다”는 판정을 한다. 지금은 NARU 가 직접 운영한다. 위 네 가지 장치로 판정을 재현해 검증할 수 있지만, 판정 자체를 대신 해 주지는 않는다.
구현에서는 이 역할을 어테스터라고 부른다. 판정 결과를 EAS 어테스테이션으로 발급하고, 컨트랙트가 그 어테스테이션을 아홉 항목으로 검증한 뒤에만 지급한다.
프로토콜 오너예정
업그레이드 권한이 사실상 자금 인출 권한이다. 멀티시그와 타임락은 메인넷 배포 전 필수다.
레퍼런스

컨트랙트와 네트워크#

전부 소스가 공개돼 있다. 익스플로러에서 바로 확인할 수 있다.

네트워크
GIWA Sepolia
체인 ID
91342
RPC
https://sepolia-rpc.giwa.io
익스플로러
https://sepolia-explorer.giwa.io
CampaignEscrow
대금을 보관하고 지급을 실행한다
0xD8D6…6251익스플로러 ↗
테스트 토큰
테스트넷용 ERC-20
0xdB2d…9F3f익스플로러 ↗
EAS
어테스테이션 저장소 — 체인에 기본으로 배포돼 있다
0x4200…0021익스플로러 ↗
레퍼런스

검증 가능한 항목#

캠페인에 걸 수 있는 지급 항목과, 그 성과를 NARU 가 어디서 확인하는지다. 아직 확인 경로가 없는 항목은 추후 지원으로 표시한다.

항목단위확인 경로지원
콘텐츠 게시
브리프대로 올리면 정액 지급
건게시물 원문현재 가능
구매 전환
할인코드로 들어온 주문 1건당 지급
건Shopify 주문 데이터추후 지원
게시물 유지
정해진 기간 지우지 않으면 잔금 지급
건공개 URL 정기 확인추후 지원
앱 설치
설치가 확인된 1건당 지급
설치앱 어트리뷰션추후 지원
신규 지갑 유입
새로 만든 뒤 일정 기간 남아 있는 지갑당 지급
지갑온체인추후 지원
예치금 유치
레퍼럴로 들어온 예치액 기준
천 USD온체인추후 지원
거래량
데려온 사용자가 쌓은 누적 거래량
천 USD온체인추후 지원
방문자 유입
링크를 타고 들어온 세션
천 세션NARU 링크 서버추후 지원
팔로워 증가
캠페인 기간에 늘고 유지된 팔로워당 지급
명X 프로필 · 기간 대조추후 지원
도달·저장
게시물 도달과 저장 수
천 도달X 게시물 지표추후 지원