智能合约、状态与交易
以太坊开发者文档将智能合约描述为部署在特定地址上的代码与数据。函数规定可执行的操作，状态保存程序当前的数据；用户通过交易调用函数，部署也属于交易并需要支付计算费用。智能合约依照代码执行规则。
放到合同管理语境中，可以把“审批是否完成”理解为需要记录的状态，把“提交审批”理解为一种操作。这是概念示例，实际系统是否支持这些环节，取决于程序是否定义了相应规则。不能仅凭“智能合约”这个名称，就认为合同全文及所有履约环节都已自动化。
预言机与链外信息
以太坊开发者文档说明，智能合约本身不能直接获取现实世界的数据，预言机用于把链外信息提供给合约。合约之间还可以相互调用，这种能力称为可组合性。
如果流程需要根据交付结果继续执行，就必须先解决交付信息如何进入链上的问题。程序能够检查输入是否满足既定条件，但输入被记录下来，并不等于其对应的现实事件已被程序独立核实。适用条件包括可明确表达的规则，以及能够提供所需信息的机制。
所有权、角色与最小权限
OpenZeppelin访问控制文档区分了所有权管理与基于角色的访问控制。Ownable由指定所有者执行受限管理操作；AccessControl允许不同角色承担不同操作，角色的授予和撤销由对应管理员控制。最小权限原则强调只开放完成职责所需的权限。
用于理解合同流程时，可将提交、审核和权限管理视为不同职责。某个账户能够审核，不代表它也能任命其他审核者。“所有者”在这里指程序中的管理权限，不能直接据此推定其拥有业务合同中的全部权利。
多签与权限交接的常见问题
多签要求达到预设数量的有效签名后才执行操作；两步所有权转移则要求接收方明确接受管理权。OpenZeppelin文档还指出，放弃所有权会使受所有者限制的操作无法再被调用。
多签与角色管理能否互相替代？它们处理的问题不同：角色决定谁有资格执行某类操作，多签决定一次操作需要多少授权共同成立，两者可以结合使用。权限交接是否等于修改业务条款？两者也应分别理解：前者改变管理主体，后者是否能够发生以及如何生效，仍取决于程序规则。