地址、私钥与数字签名
捐赠系统首先需要解决资金由谁接收、谁能授权支出的问题。比特币开发者指南通过交易示例说明：接收方提供地址，支出方以数字签名满足相应的支出条件。私钥承担授权作用，地址则用于表达接收目标。
在捐赠场景中，控制某个地址与拥有某种公益身份是不同的判断。签名能支持验证支出授权，却不能单独证明地址属于某家机构，或证明收款人符合救助条件。
交易记录与UTXO
比特币采用未花费交易输出，即UTXO模型：交易输入引用此前的输出，新输出等待后续使用。交易标识符与输出序号可以定位具体输出。这一机制适用于理解比特币捐赠的收款和后续支出，不能直接套用为所有区块链的记账方式。
追踪捐赠时，需要区分资金发生链上移动与实际用途得到核实。看到一笔支出，只能据此分析相应链上流转；认定其用于采购物资或发放救助，还需要对应的业务凭证。
智能合约与执行费用
以太坊开发文档将智能合约解释为部署在链上地址中的代码和状态。用户通过交易调用功能，部署及执行涉及Gas费用；合约也可调用其他合约。在采用这类机制的捐赠系统中，接收资金、限制支出权限等规则可以由程序表达。
适用前提是规则能够转化为明确的程序条件。所谓自动执行，是按照既定代码处理输入；若拨款依赖外部审核结果，仍须有机制提交审核信息。费用也应与捐赠金额分别核算，以便解释资金记录。
预言机与多重签名
智能合约不能自行读取链外事实，预言机用于将外部数据引入链上。多重签名则要求达到约定数量的有效签名才允许执行，可用于分配资金管理责任。
两者解决的问题不同：预言机涉及外部信息如何进入系统，多重签名涉及谁有权批准操作。前者仍需关注信息来源是否可靠，后者仍需明确签署者的职责。它们都不能独立证明公益活动的实际效果。
常见问题：上链是否等于可信
公开记录有助于核对资金路径，但项目可信度还涉及身份、凭证及线下履约。评估技术说明时，应分别辨认哪些内容由交易记录支持，哪些由代码约束，哪些仍依赖机构或人员核实。上述概念属于通用机制，不能据此认定某个具体捐赠项目已经采用或实现了这些功能。