Ownership as control

An ERC-721 decides who may act as an ERC-6551 account. That single sentence is the whole mechanism, and everything else in the protocol is built on top of it.

The binding

The registry deploys each account as a minimal proxy with its chain id, Broker contract and token id appended to the proxy's own runtime code. The account reads that footer back out of itself to learn which NFT controls it. The binding is therefore part of the deployed code, not a storage slot, and cannot be rewritten after the fact.

function token() public view returns (uint256 chainId, address tokenContract, uint256 tokenId);

Where authority comes from

There is no owner variable, no admin, no separate key and no upgrade path. Every call into the account resolves authority live:

function owner() public view returns (address) {
    (uint256 chainId, address tokenContract, uint256 tokenId) = token();
    if (chainId != block.chainid) return address(0);
    return IERC721(tokenContract).ownerOf(tokenId);
}

Because the answer is read at call time, control follows the token instantly. The block that transfers the Broker is the block the old owner loses execute and the new owner gains it. Nothing has to be migrated, re-approved or re-titled.

The account also implements ERC-1271, so it can present signatures off-chain: a signature is valid when the Broker's current owner produced it.

Deterministic addresses

Account addresses are computed with CREATE2 from the implementation, salt, chain id, Broker contract and token id. Two consequences matter in practice. An interface can show a Broker's account address, and anyone can send assets to it, before the account has been deployed. And deployment is idempotent, so a duplicate createAccount costs a little gas and changes nothing.

What the account cannot do

• No delegatecall. Only operation 0 is accepted, so no external code runs in the account's own context.
• No cross-chain control. If the recorded chain id is not the current chain, owner() returns the zero address and nothing can be executed.
• No hidden operator. Approvals on the Broker let someone move the token, which transfers control by transferring the asset. There is no path that drives the account without holding the Broker.
• No upgrade. The implementation an account was deployed against is the implementation it keeps.

Approving a marketplace or the credit desk for your Broker is approving custody of the account behind it. Treat a Broker approval the way you would treat approving the portfolio itself, because that is what it is.

hStocks

An hStock is an 18 decimal ERC-20 issued by the StockDesk against a listed ticker. It is a claim on the desk that issued it and nothing more: the desk is the only address that can mint or burn units, quotes the price, and settles redemptions out of its own cash. It is not a share in the underlying company and carries no shareholder rights.

Accounts hold hStocks the same way a wallet would. What changes is that the position is inside the Broker, so it prices into the Broker when the Broker trades and it is pledged with the Broker when the Broker is used as collateral.