본문으로 건너뛰기

증권의 권리를 보유기간에 따라 계산할 수 있을까

· 약 16분
Bankware Global Engineering

한동안 RWA와 토큰증권에 관한 이야기는 자산을 얼마나 잘게 나눠 거래할 수 있는가에 집중돼 있었다.

부동산, 음악 저작권, 미술품, 매출채권처럼 거래하기 어렵거나 접근 비용이 높은 현실 자산을 디지털 토큰으로 표현하면 더 작은 단위로 소유하고 이전할 수 있다. 유동성이 낮았던 권리에 새로운 거래 가능성이 생긴다는 것이 토큰화가 제시한 첫 번째 약속이었다.

하지만 거래 단위만 작아진다고 금융의 작동 방식까지 달라지는 것은 아니다.

부동산에서는 월세가 발생하고, 음악과 특허에서는 사용료가 발생한다. 대출채권과 매출채권에는 이자와 상환금이 쌓인다. 이런 자산의 권리를 토큰으로 나눠 유통한다면 거래가 끝난 뒤 더 어려운 질문이 남는다.

자산이 만들어낸 수익과 자산을 움직일 정책 결정권을 계속 바뀌는 토큰 소유자들에게 어떻게 나눌 것인가?

토큰화는 어디까지 왔는가

2026년 8월 현재 세계의 토큰화는 기존 증권이 분산원장으로 대거 이전한 단계가 아니다. 채권, 펀드와 예금 등을 중심으로 규제된 실증에서 통제된 실제 가치 거래와 초기 상용화로 넘어가는 전환기에 가깝다. 유럽연합은 DLT Pilot Regime에서 분산원장 기반 금융상품의 거래와 결제를 시험하고 있다. 싱가포르는 Project Guardian의 상용화를 지원하고 참여기관들은 관련 네트워크 구축을 추진하고 있다. 홍콩금융관리국은 2025년 11월 EnsembleTX를 출범해 실제 가치가 오가는 통제된 파일럿 단계로 옮겼다. BIS는 토큰화의 가능성을 자산 기록과 이전 규칙을 하나의 프로그래머블 플랫폼에 결합하는 데서 찾는다.

그렇다고 완성된 전환이 일어난 것은 아니다. 금융안정위원회는 도입 수준을 매우 낮지만 증가하는 상태로 평가했다. 유럽의 초기 참여도 제한적이었다. 시장은 아직 작고, 효율성·투명성·접근성이라는 기대효과 상당수는 더 검증해야 할 대상으로 남아 있다. BIS Annual Economic Report 2025의 제3장, BIS FSI의 토큰화 평가, 금융안정위원회의 2024년 평가, ESMA의 DLT Pilot 검토, 싱가포르 통화청의 Project Guardian 상용화 지원 방안, 홍콩금융관리국의 Project Ensemble 현황은 각각 그 가능성과 아직 남은 제도·인프라의 간극을 보여준다.

한국에서도 제도적 문이 열리고 있다. 금융위원회는 2023년 토큰증권 가이드라인을 발표하며 토큰증권을 별도의 새로운 자산이 아니라 분산원장 기술을 이용해 자본시장법상 증권을 디지털화한 새로운 발행 형식으로 설명했다. 2026년에는 관련 전자증권법과 자본시장법 개정안이 국회를 통과해 공포됐고, 개정 전자증권법은 2027년 2월 4일 시행될 예정이다. 아직 시행 전인 지금은 분산원장 요건과 발행·유통·결제 인프라를 만드는 이행 단계다. 금융위원회도 협의체를 꾸려 정형증권의 토큰화와 온체인 결제를 포함한 단계별 로드맵을 논의하고 있다. 금융위원회의 2023년 정비방안, 2026년 법률 개정 발표, 개정 전자증권법, 토큰증권 협의체의 단계별 로드맵 논의가 이 변화의 경계를 제시한다.

이 제도화가 본격화되기 전인 2023년, 우리가 관심을 가졌던 것은 분산원장이 열 수 있는 조금 더 구체적인 가능성이었다.

기존 권리를 분산원장에 그대로 옮기는 데서 멈추지 않고, 원장이 가진 시간성과 프로그래머빌리티를 이용해 새로운 권리 계산 방식을 만들 수는 없을까?

거래 이후에도 권리는 계속 움직인다

RWA와 토큰증권은 같은 말이 아니다. RWA는 무엇을 권리화하고 토큰화할 것인가에 관한 넓은 업계 용어다. RWA 토큰이라는 이름만으로 기초자산의 법적 소유권이나 증권성이 생기는 것은 아니다. 토큰증권은 그 권리가 자본시장법상 증권일 때 선택할 수 있는 법적·기술적 발행 형식이고, STO는 그러한 토큰증권을 발행·모집하는 행위를 가리킨다. 그리고 이 글이 다룰 소유기간 증명은 발행된 권리의 이력을 이용해 수익과 의사결정 권한을 어떻게 계산할지에 관한 한 단계 아래의 문제다.

RWA 무엇을 권리화·토큰화하는가
토큰증권 증권인 권리를 어떤 원장 형식으로 기록하는가
STO 토큰증권을 발행·모집하는 행위
권리 계산기 발행 후 수익과 의사결정 권한을 어떻게 계산·집행하는가

토큰증권이 된다고 증권의 실질이 저절로 달라지지는 않는다. 투자자 보호, 공시, 권리 확정과 시장질서에 관한 규칙도 사라지지 않는다. 적격 분산원장을 법적 증권 계좌부로 인정하는 구조에서 바뀔 수 있는 것은 권리자와 이전 이력을 기록하는 기반, 그리고 그 이력 위에서 실행할 수 있는 계산의 범위다. 모든 RWA 토큰이 곧바로 그러한 법적 원장이 되는 것은 아니다.

중앙화된 기존 시스템에서도 보유기간에 따른 계산은 이론적으로 가능하다. 문제는 불가능성보다 비용과 표준화에 가깝다. 여러 기관에 흩어진 소유·이전·정산 이력을 맞추고 상품마다 다른 계산을 반복 구현해야 한다. 분산원장과 스마트 컨트랙트는 공통된 소유 이력 위에 서로 다른 권리 계산기를 올릴 가능성을 제공한다.

배당 기준일이라는 한 장의 사진

기존 주식 배당은 일반적으로 특정한 배당 기준일에 누가 얼마나 보유했는지를 확인한다. 이는 낡아서 남은 규칙이 아니다. 권리자를 명확히 확정하고, 배당락을 포함한 시장가격 조정과 대규모 정산을 처리하는 현재의 시장 구조 안에서 중요한 기능을 수행한다.

따라서 보유기간 가중 방식이 모든 기존 배당보다 공정하다거나 주식 배당 기준일을 대체해야 한다고 말할 수는 없다.

다만 현금흐름이 시간에 걸쳐 계속 발생하는 자산에서는 다른 질문을 던질 수 있다. 한 달 동안 임대료가 발생했는데 지급 기준일 직전에 권리를 취득한 사람과 한 달 내내 권리를 보유한 사람에게 같은 경제적 몫을 부여하는 것이 상품의 의도에 맞을까? 음악 사용료, 대출 이자, 인프라 운영수익처럼 기간에 따라 누적되는 현금흐름이라면 한 시점의 잔액보다 전체 기간의 지분을 보는 방식이 더 잘 맞을 수도 있다.

스냅샷은 한 장의 사진이다. 분산원장의 이전 이력은 시간에 따라 이어진 필름에 가깝다.

2023년에 던진 질문

2023년 블록체인 난제 해결 챌린지를 준비하며 우리가 던진 질문은 단순했다.

토큰이 이동할 때마다 잔액과 블록 높이를 함께 남긴다면, 과거의 특정 구간에서 누가 얼마를 얼마나 오래 보유했는지 계산할 수 있지 않을까?

당시 기획서에서는 주소별 잔액을 블록 높이와 함께 기록하고, 수익 지급자가 과거의 블록 구간과 지급할 수익 토큰을 지정하는 모델을 제안했다. 토큰 소유자는 나중에 자신이 그 기간 동안 보유했던 지분을 근거로 수익을 청구한다. Substrate의 pallet-contracts, Ink!와 Rust로 잔액 캡처, 수익 입금과 인출 기능을 담은 프로토타입을 구성했다고 기록돼 있다.

이 아이디어는 이후 뱅크웨어글로벌 주식회사가 보유한 대한민국 등록특허 제10-2670671호 「증권형 토큰의 수익 배분 시스템 및 방법」으로 정리됐다. 출원일은 2023년 10월 16일, 등록일은 2024년 5월 27일이다.

여기서 소유기간 증명은 새로운 영지식증명이나 암호학적 proof를 뜻하지 않는다. 더 정확히 말하면 원장에 남은 체크포인트로 과거의 시간가중 소유지분을 감사 가능하게 재구성하는 회계 알고리즘이다.

점이 아니라 면적을 계산하기

주소 A의 잔액을 세로축, 블록 높이를 가로축으로 놓아보자. 잔액이 바뀌지 않는 동안 그래프는 수평으로 이어진다. 잔액과 그 잔액이 유지된 블록 수를 곱하면 직사각형의 면적이 된다.

ownershipArea(A, H0, H1)
= sum(balance_A(segment) * segmentLength)

TWAB(A, H0, H1)
= ownershipArea(A, H0, H1) / (H1 - H0)

TWAB는 time-weighted average balance, 즉 기간가중 평균잔액이다. 모든 블록의 상태를 하나씩 저장할 필요는 없다. 잔액이 바뀐 지점과 그때의 새 잔액만 체크포인트로 남기면, 두 체크포인트 사이의 면적을 계산할 수 있다.

기간 경계는 반드시 먼저 정해야 한다. 이 글에서는 모든 구간을 [start, end)로 표현한다. 시작점의 상태는 포함하지만 종료점에서 발생한 변경은 다음 구간에 들어간다. 따라서 [58, 98)은 58번부터 97번까지 정확히 40개의 블록 슬롯이다.

100,000개의 수익을 다시 나눠보기

수익 지급자가 [58, 98) 구간에 수익 토큰 100,000개를 배분한다고 가정하자. 이 기간에 적격 증권토큰의 총발행량은 1,000개로 고정돼 있고, 블록당 수익은 2,500개다.

  • 이전 소유자는 73번 블록에서 A에게 1,000개를 이전한다.
  • A는 83번 블록에서 B에게 500개를 보낸다.
  • B는 90번 블록에서 A에게 500개를 돌려보낸다.
구간블록 수A 잔액B 잔액A 수익B 수익
[58, 73)150000
[73, 83)101,000025,0000
[83, 90)75005008,7508,750
[90, 98)81,000020,0000

A는 53,750개, B는 8,750개를 받는다. [58, 73) 동안 1,000개를 보유했던 이전 소유자가 37,500개를 받으면 총 지급량은 정확히 100,000개가 된다.

총발행량이 바뀌는 경우에는 잔액 면적만으로 부족하다. mint와 burn이 일어나는 지점을 총발행량 체크포인트에도 반영하고, 각 구간에서 다음 지분율을 계산해야 한다.

shareArea(A, H0, H1)
= sum(balance_A(segment) / eligibleSupply(segment) * segmentLength)

여기서 분모가 전체 발행량인지, treasury와 소각 예정 물량을 뺀 적격 발행량인지는 기술이 아니라 상품의 권리 정책이다. 계산식은 그 정책을 숨겨주지 않는다.

하나의 이력에서 서로 다른 권리로

소유 이력은 하나지만 그 이력이 언제나 같은 권리를 만들어야 하는 것은 아니다.

잔액·위임 체크포인트
|
+--> 수익권 계산기: 기간별 경제적 지분에 따른 지급
|
+--> 표결권 계산기: 제안 전 관찰기간의 지속된 원장상 지분
|
+--> 기여도 장부: 별도 증빙·평가·감쇠·취소 규칙

수익권은 수익이 실제로 발생한 기간의 경제적 지분을 묻는다. 정책 표결권은 제안이 나오기 전부터 누가 원장상 지분을 지속적으로 보유했는지를 물을 수 있다. 기여도는 자본을 얼마나 보유했는지가 아니라 누가 분석, 개발, 운영, 감시 또는 커뮤니티 활동에 기여했는지를 다룬다.

세 질문의 목적이 다르므로 점수도 분리해야 한다.

정책 표결에도 시간을 넣을 수 있을까

단일 스냅샷이 막는 것과 놓치는 것

일반적인 토큰 투표는 특정 snapshot에서의 과거 잔액을 사용한다. 현재 잔액 대신 과거 체크포인트를 조회하면 투표한 뒤 토큰을 다른 주소로 옮겨 다시 투표하는 행위와 같은 트랜잭션의 flash loan으로 표를 빌리는 공격을 줄일 수 있다. OpenZeppelin의 ERC20Votes도 과거 voting power를 체크포인트로 보관하고 Governor가 특정 시점의 표를 조회하도록 구성한다. OpenZeppelin의 거버넌스 가이드는 이 snapshot 모델을 기본으로 설명한다.

하지만 한 시점의 snapshot만으로는 기준점 직전에 토큰을 매집한 참여자와 오랫동안 같은 수량을 보유한 참여자를 구별하지 못한다. 이때 소유기간 계산을 표결에 적용할 수 있다. 제안 공개 이후의 매수와 위임을 제외하려는 설계라면 기준점 V를 제안 공개 시점 또는 그 이전의 고정 epoch로 잡아야 한다. votingDelay는 그 뒤에 이어지는 숙의기간이 된다.

제안 기준점을 1,000번 블록, 관찰기간을 [900, 1000)이라고 하자.

  • A는 100개를 100개 블록 동안 계속 보유했다.
  • B는 990번 블록에 100개를 취득했다.
  • 1,000번 블록 직전의 현재 잔액은 둘 다 100개다.
A ownershipArea = 100 * 100 = 10,000
A TWAB = 10,000 / 100 = 100

B ownershipArea = 100 * 10 = 1,000
B TWAB = 1,000 / 100 = 10

단일 snapshot에서는 둘 다 100개의 기초 표결 단위를 갖는다. 완전한 선형 기간가중 정책에서는 A가 100, B가 10을 갖는다. 같은 블록 안에서 빌렸다 갚는 flash loan은 관찰기간의 평균에 사실상 영향을 주지 못하고, 표결 직전 매집의 효과도 보유한 기간만큼 줄어든다.

이 특성은 장점인 동시에 정치적 선택이다. B가 공격자가 아니라 정당한 신규 투자자여도 같은 감쇠를 받기 때문이다. 반대로 대규모 지분을 오래 보유한 참여자는 장기간 강한 영향력을 유지한다. 기간가중은 순간 자본의 공격을 약화하지만 오래된 자본의 과점을 해결하지 않는다.

기준점 지분과 과거 평균을 함께 보기

여기에는 한 가지 문제가 더 있다. 과거 평균잔액만 표로 인정하면 기준점 전에 지분을 전량 처분한 권리자도 과거 보유 이력만으로 표를 행사할 수 있다. 그래서 기준점의 지분과 보유 이력을 함께 요구하는 편이 낫다. 계산은 delegate가 아니라 실질 권리자별로 먼저 해야 한다.

snapshotBalance(owner)
= beneficialOwnerBalance(owner, V)

historicalBalance(owner)
= TWAB(beneficialOwnerBalance(owner), V-L, V)

ownerVotingUnits(owner)
= (1 - lambda) * snapshotBalance(owner)
+ lambda * min(snapshotBalance(owner), historicalBalance(owner))

delegateVotingUnits(delegate)
= sum(ownerVotingUnits(owner) where delegateAt(owner, V) = delegate)

lambda가 0이면 일반 snapshot과 같고, 1이면 기준점 잔액을 상한으로 둔 기간가중 방식이다. 위 예제에서 lambda = 0.5라면 A는 100, B는 55가 된다. 관찰기간과 lambda는 신규 참여자의 발언권이 얼마나 빨리 커지는지를 결정하는 명시적인 정책 변수다. 기준점 뒤에 지분을 처분한 사람의 투표까지 막으려면 토큰 잠금 또는 투표 시점의 추가 자격 확인과 이중투표 방지 규칙이 필요하다.

권리자별 계산을 먼저 하는 순서는 중요하다. 장기 보유자와 신규 매수자가 같은 delegate에게 위임했다는 이유로 신규 지분이 장기 보유 이력을 물려받아서는 안 된다. 위임을 얼마나 오래 유지했는지도 반영하려면 보유기간과 별도로 위임 이력을 체크포인트하고 cooldown을 둬야 한다.

정족수의 분모도 다시 정의해야 한다.

eligibleVotingSupply
= sum(ownerVotingUnits(owner))

기간가중 후의 전체 유효 표는 일반적인 과거 총발행량보다 작을 수 있다. 기존 총발행량 비율을 그대로 정족수로 쓰면 정상적인 제안도 통과하지 못할 수 있으므로, 유효 표 합계에 대한 비율 또는 고정 절대값 중 어느 것을 사용할지 정해야 한다. 전자는 권리자 전체를 합산하는 비용과 검증 문제가 있고, 후자는 유통량 변화에 둔감하다는 대가가 있다.

상한, 정족수와 거부권도 사안별 정책으로 분리해야 한다. 주소별 상한이나 sqrt(잔액)을 그대로 적용하면 한 사람이 지갑을 여러 개로 나누어 우회할 수 있다. 자산 처분처럼 중대한 결정에는 더 높은 정족수와 별도의 거부권이 필요할 수도 있다. 하나의 수식이 모든 의사결정에 맞는다고 가정하지 않는다.

시간을 다르게 쓰는 거버넌스 모델

시간을 사용하는 거버넌스라고 모두 같은 모델도 아니다.

모델시간을 쓰는 방식기간가중 보유 모델과의 차이
snapshot / ERC20Votes한 과거 시점의 위임잔액지속기간을 계산하지 않는다
기간가중 표결제안 전 관찰기간의 원장상 보유량과거 보유를 기준점의 지분으로 제한한다
vote-escrow앞으로 토큰을 잠글 기간과거 보유가 아니라 미래의 잠금 약속이다
conviction voting특정 제안을 계속 지지한 기간보유 이력보다 의제 지지의 누적을 측정한다

ERC-5805는 과거 시점의 위임잔액을 조회하는 snapshot 모델을 표준화하자고 제안한 문서이며 현재 상태는 Stagnant다. Curve의 VotingEscrow 구현과 BlockScience의 conviction voting 자료는 각각 시간에 다른 의미를 부여한다. 이 글의 제안은 이들을 하나로 부르는 대신, 제안 전 실제 보유 이력이라는 입력을 따로 다룬다.

주소가 아니라 실질 권리자

토큰증권처럼 권리자가 식별되는 상품에서는 주소보다 검증된 실질 권리자가 계산의 단위가 돼야 한다. 한 사람이 관리하는 지갑끼리 토큰을 옮겼다고 보유기간이 처음부터 다시 시작돼서는 안 되고, 여러 지갑으로 나눠 상한을 우회해서도 안 된다. 수탁사의 omnibus 지갑에 여러 고객의 토큰이 모여 있다면 수탁사의 하위원장부가 고객별 보유기간과 위임을 감사 가능하게 증명해야 한다. 원장의 주소 이력만으로 법적 권리자를 항상 알 수 있는 것은 아니다.

실질 권리자를 식별해도 원장이 증명하는 것은 원장상 보유의 지속성까지다. 증권대차로 빌린 지분인지, 파생상품이나 반대 포지션으로 가격위험을 제거했는지는 잔액 이력만으로 알 수 없다. 따라서 기간가중 보유를 충성도나 실제 경제적 위험부담의 완전한 증명이라고 부르면 안 된다.

또한 이 모델은 법정 주주총회의 의결권을 스마트 컨트랙트가 임의로 바꿀 수 있다는 뜻이 아니다. 해당 권리가 증권의 내용에 포함된다면 발행조건, 공시와 적용 법률이 먼저다. 이 글의 표결 사례는 그러한 조건이 허용하는 범위의 자산 운영정책이나 프로토콜 정책을 중심으로 한다.

예를 들면 다음과 같다.

  • 임대 자산의 유지보수 예산과 수익 유보율
  • 자산 관리사 또는 데이터 검증자 교체
  • 로열티 라이선스 정책
  • 프로토콜 수수료와 treasury 사용
  • 긴급중단, 업그레이드와 위험 한도

기여도는 왜 별도의 장부여야 하는가

자본을 오래 보유한 것과 공동체에 기여한 것은 서로 다른 사실이다.

장기 보유자는 원장상 지분을 오래 유지해 왔다는 점에서 정책 결정에 반영할 하나의 신호를 제공한다. 그러나 자산을 분석한 사람, 코드를 작성한 사람, 운영 위험을 감시한 사람과 현장 데이터를 검증한 사람의 기여는 토큰 잔액에서 나오지 않는다.

이 둘을 다음처럼 단순히 더하면 문제가 생긴다.

최종 표결권 = 보유 점수 + 기여 점수

보유량의 단위가 크면 자본이 모든 기여를 압도한다. 반대로 기여 점수의 발급자가 강하면 토큰 소유자의 경제적 권리를 우회할 수 있다. 서로 다른 단위를 하나의 숫자로 합치면서 어떤 가치 판단을 했는지도 불투명해진다.

더 나은 출발점은 권한을 분리하는 것이다.

경제적 지분 의결: 기간가중 보유자 채널
운영·기술 판단: 검증된 기여자 채널

중대한 정책의 통과
= 보유자 채널 승인 AND 기여자 채널 승인

모든 사안을 양원제로 처리할 필요는 없다. 수익 지급은 경제적 지분 규칙만 따르면 되고, 순수 기술 파라미터는 위임받은 전문 기여자 채널이 담당할 수 있다. 자산 매각이나 관리사 교체처럼 양쪽의 이해가 필요한 사안만 동시 승인을 요구할 수 있다.

기여도 장부 역시 저절로 신뢰할 수 있는 것은 아니다. 무엇을 증빙으로 인정하는지, 누가 증명서를 발급하는지, 시간이 지나면 점수가 줄어드는지, 잘못된 기여를 어떻게 취소하고 이의를 제기하는지 정해야 한다. 기여도를 양도할 수 없게 만드는 것만으로 sybil, 담합과 평가자 장악이 사라지지는 않는다.

토큰을 예치하거나 래핑하면 권리는 어디에 있는가

2023년 모델은 토큰이 AMM에 예치됐을 때의 문제도 다뤘다. 원장에 보이는 증권토큰의 직접 소유자는 토큰 페어 컨트랙트지만, 경제적 이해관계는 LP token을 가진 유동성 공급자에게 남아 있을 수 있다.

당시 아이디어는 풀의 증권토큰 잔액과 LP token의 잔액·총발행량을 함께 체크포인트해 간접 지분을 재구성하는 것이었다.

간접 증권토큰 지분
= pool의 증권토큰 잔액
* 사용자의 LP token 잔액 / LP token 총발행량

이 방식은 AMM의 한 사례를 설명하는 데 유용하지만 모든 위임 모델의 표준 해법은 아니다. LP token 자체가 이전될 수 있고, receipt token이 다시 다른 프로토콜에 예치될 수도 있다. underlying과 wrapper에 동시에 수익 또는 표결권을 주면 같은 경제적 지분을 두 번 계산한다. 법적으로 누가 수익권자이고 누가 의결권자인지도 토큰의 기술적 보유자만으로 정해지지 않는다.

따라서 실제 시스템에는 어떤 wrapper가 원자산의 권리를 대신하는지 명시하는 adapter registry와 이중계산 방지 규칙이 필요하다.

기록이 있다고 계산이 저렴한 것은 아니다

“블록체인에 기록돼 있으니 과거 상태를 읽으면 된다”는 설명은 스마트 컨트랙트 구현에서는 충분하지 않다.

EVM 컨트랙트는 과거 블록의 임의 storage를 직접 읽지 못한다. 일반적인 mapping은 key 목록을 열거할 수도 없다. 따라서 주소별로 정렬된 체크포인트 배열을 저장하고 이진 탐색을 하거나, 누적 balance-blocks를 미리 계산하거나, 오프체인 인덱서가 결과를 계산해 Merkle root를 등록하는 구조가 필요하다.

각 방식의 신뢰와 비용도 다르다.

방식장점주요 비용과 위험
claim 시 체크포인트 순회계산이 직접적이고 이해하기 쉬움이력이 길어지면 가스 상한과 DoS 문제
누적 면적과 이진 탐색고정 구간 조회가 빠름총발행량 변화와 위임 합성 로직이 복잡함
오프체인 계산 + Merkle root대규모 배분 비용을 줄일 수 있음인덱서 재현성, root 이의제기 절차 필요

동일 블록 안에서 여러 전송이 일어났을 때 어느 잔액을 그 블록의 지분으로 볼지도 정해야 한다. 실제 시간에 따른 수익이라면 블록 높이보다 timestamp가 적합할 수 있다. 정수 나눗셈으로 남는 dust, 부분 청구, 겹치는 수익 캠페인과 중복 지급 상태도 모두 프로토콜의 일부다.

표결은 여기에 다른 공격면을 더한다. 과거 평균잔액은 flash loan과 직전 매집을 약화하지만 장기 고래, 차입·헤지된 지분, 위임 집중, 낮은 참여율과 매표를 막지 못한다. 제안 공개 뒤의 매수를 제외하려면 일반적인 Governor 구성처럼 votingDelay 뒤에 기준점을 잡지 않고, 제안 공개 시점 또는 이전 epoch에 표를 먼저 고정해야 한다. 그 위에 timelock, 정족수, 위임 변경 cooldown, late-quorum extension과 비상중단 절차를 검토할 수 있다. 정족수는 저참여 결정을 막는 대신 교착을 만들 수 있고, timelock은 매표를 막기보다 탐지와 대응 시간을 제공한다. Ethereum.org의 스마트 컨트랙트 보안 문서도 flash loan으로 일시적인 표결권을 얻는 공격을 온체인 거버넌스의 대표 위험으로 든다. 2022년 Beanstalk 거버넌스 공격 사후 분석은 빌린 표와 즉시 실행이 결합됐을 때 그 위험이 실제 손실로 이어질 수 있음을 보여준다.

특허를 다시 읽는 이유

등록특허 제10-2670671호는 증권토큰의 발행과 이전, 수익 배분 룰 등록, 소유기간 조회, 지급량 계산과 중복 지급 방지를 하나의 시스템과 방법으로 정리한다. 스테이킹과 LP token을 이용한 간접 지분 계산은 상세한 실시예로 들어 있다.

특허 등록 사실은 이 알고리즘의 확장성, 경제적 공정성 또는 실제 시장 적합성이 검증됐다는 뜻이 아니다. 이 글에서 특허를 밝히는 이유는 2023년에 시작한 질문이 어떤 형태로 문서화되고 공개됐는지 이력을 남기기 위해서다. 특허의 권리범위나 실시허락에 관한 판단도 이 글의 역할이 아니다.

이번 재구성은 소유기간 증명을 완성된 정답이 아니라 원장 위의 권리를 다시 생각하게 한 첫 모델로 다룬다.

프로그램 가능한 권리는 프로그램 가능한 권력이다

증권이 분산원장으로 옮겨온다고 모든 문제가 저절로 해결되지는 않는다. 기존의 권리를 더 작은 토큰으로 복제하는 데 그칠 수도 있다. 반대로 원장의 시간성과 프로그래머빌리티를 이용해 이전에는 비표준적이고 비용이 컸던 권리 계산을 상품의 일부로 만들 수도 있다.

기간가중 수익배분은 수익이 발생한 시간과 경제적 지분을 연결한다. 기간가중 표결은 한 시점의 잔액보다 지속된 원장상 보유에 더 큰 무게를 줄 수 있다. 별도의 기여도 장부는 자본으로 환원되지 않는 노동과 책임을 의사결정에 반영할 가능성을 연다.

그러나 계산식은 중립적이지 않다. 어느 기간을 볼지, 어떤 발행량을 분모로 삼을지, 신규 참여자와 장기 보유자 사이에서 어떤 균형을 택할지 모두 정책 결정이다. 수익권, 표결권과 기여도를 하나의 숫자로 섞지 않고 각각의 목적과 공격면을 밝혀야 하는 이유가 여기에 있다.

분산원장은 소유의 역사를 기록한다. 그 역사에 어떤 권리의 무게를 부여할지는 결국 우리가 작성하는 코드와 제도가 결정한다.